| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-30 | |||
| 15:42:24 | melwitt | yeah, need to swap a runway | |
| 15:42:41 | melwitt | one of them has merged as of friday | |
| 15:43:11 | dansmith | it would help if you could make sure the actual blueprint tag is in the runway description somewhere | |
| 15:43:16 | dansmith | so I can just copy that in and not have to look it up | |
| 15:43:25 | melwitt | okay, can do | |
| 15:43:30 | dansmith | s/you/whoever is doing the runway jostling/ | |
| 15:46:57 | melwitt | thanks | |
| 15:47:04 | dansmith | aye | |
| 15:50:07 | melwitt | yikun: fyi, your blueprint add-host-to-instance-action-events has been removed from the review runway as all the related code has merged. please feel free to add feedback about your experience with review runways at L186 https://etherpad.openstack.org/p/nova-runways-rocky | |
| 16:38:37 | openstackgerrit | Aditya Vaja proposed openstack/nova master: remove IVS plug/unplug as they're moved to separate plugin https://review.openstack.org/534371 | |
| 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 | 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:14:44 | mgagne | I opened the bug, I'm currently working on it https://bugs.launchpad.net/nova/+bug/1768107 | |
| 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 | |