Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-30
17:00:57 openstackgerrit Jay Pipes proposed openstack/nova-specs master: Standardize CPU resource tracking https://review.openstack.org/555081
17:11:59 jaypipes stephenfin: you there? do you see "(provider network" clipped to "rovider network)" on the graphics in http://logs.openstack.org/90/541290/9/check/build-openstack-sphinx-docs/0278227/html/specs/rocky/approved/numa-aware-vswitches.html?
17:12:18 jaypipes not sure if I'm the only one that sees it because of my browser or something
17:15:14 artom jaypipes, FWIW, I see it too
17:15:43 artom Both FF and Chrome
17:27:07 jaypipes mriedem, dansmith: mgagne mentioned on the ML that the latest Nova no longer includes user_id in the request spec. Is that true? Did we remove user_id from the request spec somehow? I don't see user_id in the request spec object, but I also don't see a major object version bump so I'm unsure if user_id was ever there?
17:27:46 mgagne jaypipes: could be that when RequestSpec was created/used, user_id was dropped without mention
17:28:52 dansmith jaypipes: pretty sure it wasn't dropped
17:29:18 mgagne I think there are no filter using it so maybe people saw no need to still support it
17:30:28 mgagne I know it used to be available in filter_properties['instance_properties']['user_id']
17:30:38 mgagne in fact
17:30:53 mgagne filter_properties['request_spec']['instance_properties']['user_id']
17:31:04 jaypipes hmm..
17:31:19 dansmith oh in filter_properties
17:31:25 dansmith that wouldn't require a bump
17:31:54 dansmith mgagne: this is an internal nova object, what are you concerned about it being missing for?
17:31:58 dansmith because of scheduling?
17:31:59 mgagne dropped -> forgot to reimplement it
17:32:26 mgagne dansmith: for a custom filter http://lists.openstack.org/pipermail/openstack-dev/2018-April/130022.html
17:33:25 dansmith okay so you care that it's not coming to your filter
17:33:36 mgagne yes
17:33:47 dansmith is this where I say it's bad that we say we have a plugin interface we know is not stable because we don't test it and pass internal data structures to it? :)
17:34:16 mgagne ¯\_(ツ)_/¯ don't care much, it fits my need ;)
17:44:34 mgagne If there is a defined object/interface, I will use it. Otherwise I will find a way to make it work. No much I can do to avoid that when the business I work for needs it.
17:44:44 mgagne If I can contribute something back (and don't forget about it), I will. If it's too much work/time, it's gonna go in the backlog and will try to contribute when time is available.
17:47:43 mriedem i don't see anything specific to instance_properties['user_id'], the request spec 'instance_properties' looks like it's getting built from build_request_spec in certain flows, but that's using the instance object, which should have user_id on it
17:48:29 mriedem build_request_spec is also used when a really old instance is moved and doesn't have a request spec
17:48:58 mriedem mgagne: i think i know what you're probably hitting
17:49:04 mriedem mnaser hit it too
17:49:07 mriedem and reported it
17:49:49 mriedem https://review.openstack.org/#/c/529185/
17:49:50 mgagne I already have an internal patch I can contribute: https://gist.github.com/mgagne/ed1fd3251997b2e60564fed43f47d96f
17:50:27 mgagne just need to port it for master, currently against mitaka
17:51:17 mriedem mgagne: my guess is you are hitting a symptom of the same bug that ^ is working around
17:51:31 mriedem in that data migrations for instances that didn't have request specs used an admin context, which doesn't have project_id or user_id set
17:51:46 mgagne project_id is available for me
17:51:57 mgagne but the object just doesn't have the user_id attribute
17:51:59 mriedem because that workaround puts it into the request spec
17:52:17 mriedem are you hitting this on a move operation?
17:52:28 mgagne no, new instances
17:52:43 mriedem and you're going from which release (working) to which release (broken)?
17:52:44 mgagne user_id is not available because it's not in the RequestSpec class
17:53:05 mriedem mgagne: yeah, that's because you should be using reqspec.instance.user_id no?
17:53:12 mgagne kilo -> mitaka. I lost the user_id when moving from filter_properties to spec_obj
17:53:19 mriedem ok mitaka is definitely not "latest" nova
17:53:27 mgagne =)
17:53:37 mriedem why can't you use reqspec.instance.user_id?
17:53:50 mriedem oh nvm
17:53:51 mgagne spec_obj.project_id is available, not spec_obj.user_id
17:54:37 mriedem RequestSpec.from_primitives uses filter_properties to build the RequestSpec from the instance, and doesn't save off the user_id
17:54:41 mgagne I didn't look much into it, I saw that spec_obj.project_id was available and used elsewhere and tried spec_obj.user_id
17:56:09 mriedem so https://review.openstack.org/#/c/197912/ was the regression for you in mitaka
17:57:22 mgagne yes
17:57:49 mgagne I'm just gonna contribute my patch and see where it goes from there
17:59:06 mriedem wfm, should probably report a bug as well
17:59:22 mgagne bug is enough? will open then
17:59:35 mriedem regardless of the custom out of tree scheduler filter dependency, it makes sense to have user_id to know the user that originally requested to create the instance vs another user (in the same project) to move an instance
17:59:53 mriedem especially if we already have project_id in RequestSpec
18:00:15 melwitt fwiw, I agree. we have the same mismatch (project_id but no user_id) in InstanceMapping too
18:00:20 mriedem maybe others feel differently, but this seems ok to me as a regression fix, albeit for out of tree things
18:00:55 mriedem instance mappings are pretty special purpose though,
18:01:04 mriedem and not tied to any pluggable interfaces as far as i know
18:03:32 melwitt no, but it was weird to see part of the owner info there and not the other when I looked at it for counting instances. I don't know what it uses project_id for currently
18:03:46 mriedem allocation claims in placement at least
18:04:07 mriedem AggregateMultiTenancyIsolation also uses it
18:04:09 mgagne https://github.com/openstack/nova/blob/master/nova/scheduler/filters/aggregate_multitenancy_isolation.py#L41
18:04:10 mgagne yes
18:04:30 mgagne that's where I found spec_obj.project_id was available
18:04:37 melwitt I mean I don't know what the InstanceMapping.project_id is used for currently
18:05:01 melwitt i.e. why it needed project_id but not user_id
18:05:31 dansmith melwitt: so you can list instances :)
18:08:32 dansmith melwitt: for this: https://review.openstack.org/#/c/509003/8
18:08:34 melwitt oh okay, so it doesn't just do a scatter-gather query instances by project_id and instead does separate queries per InstanceMapping? I didn't realize that
18:09:01 dansmith well, it was to avoid hitting cells you don't need during list.. I don't remember if we ever implemented that before my list thing,
18:09:10 dansmith but we never merged that bit of my newer thing either
18:09:25 dansmith because of the BR thing I never finished
18:09:56 melwitt oh, I see
18:10:21 melwitt so it could pre-check if there are any cells that do not contain that project_id
18:11:42 dansmith it just got a unique list of cells that you have mappings for
18:11:57 dansmith https://review.openstack.org/#/c/509002/8/nova/objects/cell_mapping.py
18:12:21 dansmith we never implemented that before (I just checked) with the old stuff because we were just using the global cell mapping list
18:12:37 dansmith it's a perf tradeoff
18:12:52 dansmith for two cells and even distribution, it's faster to just use the global list,
18:13:05 dansmith if you're cern, it makes sense to figure out which cells we should even ask during list
18:13:40 dansmith might should have a perf tunable in that last patch
18:14:44 mgagne I opened the bug, I'm currently working on it https://bugs.launchpad.net/nova/+bug/1768107
18:14:44 openstack Launchpad bug 1768107 in OpenStack Compute (nova) "The user_id field is missing from RequestSpec" [Undecided,In progress] - Assigned to Mathieu Gagné (mgagne)
18:15:21 melwitt yeah, understood
18:37:52 openstackgerrit Matt Riedemann proposed openstack/nova master: Implement granular policy rules for placement https://review.openstack.org/524425
18:37:53 openstackgerrit Matt Riedemann proposed openstack/nova master: Cleanup placement policy generator docs https://review.openstack.org/565225
18:55:42 openstackgerrit Eric Fried proposed openstack/nova master: placement: Object changes for granular https://review.openstack.org/564351
18:55:43 openstackgerrit Eric Fried proposed openstack/nova master: WIP: placement: Granular GET /allocation_candidates https://review.openstack.org/517757
18:55:44 openstackgerrit Eric Fried proposed openstack/nova master: Get anchors for sharing providers https://review.openstack.org/565279
19:17:27 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Return resources of entire trees in Placement https://review.openstack.org/559466
19:39:43 openstackgerrit Brianna Poulos proposed openstack/nova stable/pike: conf: Do not inherit image signature props with snapshots https://review.openstack.org/565288
19:42:22 openstackgerrit Brianna Poulos proposed openstack/nova stable/pike: conf: Do not inherit image signature props with snapshots https://review.openstack.org/565288
19:52:39 openstackgerrit Brianna Poulos proposed openstack/nova master: Add notification support for trusted_certs https://review.openstack.org/563269
19:58:04 openstackgerrit Eric Fried proposed openstack/nova master: Get anchors for sharing providers https://review.openstack.org/565279
19:58:05 openstackgerrit Eric Fried proposed openstack/nova master: placement: Object changes for granular https://review.openstack.org/564351
19:58:06 openstackgerrit Eric Fried proposed openstack/nova master: WIP: placement: Granular GET /allocation_candidates https://review.openstack.org/517757

Earlier   Later