Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-04-30
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
20:59:19 mriedem dansmith: i think https://review.openstack.org/#/c/325414/ (bottom patch in the console auth token series) is ready to go, comments up the stack on the other changes though
20:59:46 mriedem dansmith: this is also likely a question for you https://review.openstack.org/#/c/333990/32/nova/console/websocketproxy.py@43
21:03:49 dansmith mriedem: answered that question.. not sure I'll get to much more before EOD
21:05:49 mriedem melwitt: fyi, comments in your console auth token series
21:05:56 mriedem i see the runway slot ends tomorrow
21:05:59 mriedem sorry for being late on those
21:06:12 melwitt mriedem: replies in progress
21:06:16 melwitt no worries
21:06:16 mriedem fwiw i think it's mostly easy stuff
21:06:17 openstackgerrit Mathieu Gagné proposed openstack/nova master: Add user_id to RequestSpec https://review.openstack.org/565340
21:06:50 melwitt thanks for the reviews
21:29:09 melwitt mriedem: do you happen to know what's the process for moving methods into os-vif plugins for plug/unplug? does there have to be a deprecation period or requirement for how the plugin has to be able to be installed? this is a change for moving bigswitch methods to a plugin: https://review.openstack.org/534371
21:30:24 mriedem last time i looked at that patch i asked some questions https://review.openstack.org/#/c/534371/4//COMMIT_MSG@12
21:30:30 openstackgerrit Mathieu Gagné proposed openstack/nova master: Add user_id to RequestSpec https://review.openstack.org/565340
21:31:10 melwitt oh, I'm blind
21:32:12 mriedem as for what the process is, i don't think we really have one, but if we have some vif type impl in tree and then it moves to an out of tree neutron plugin, operators would obviously need to make sure the neutron agent is using that new package to provide that vif type support before they upgrade nova-compute

Earlier   Later