| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-30 | |||
| 15:27:55 | jaypipes | dansmith: yes, I would like to see those be NOT NULL, but there was stiff resistance from both cdent and edleafe | |
| 15:28:00 | dansmith | jaypipes: user/project is required in later microversions right? | |
| 15:28:39 | dansmith | if clients use older microversions just to get themselves an allocation without user/project, things are going to fall apart pretty quick | |
| 15:29:05 | jaypipes | dansmith: 1.8 added them. 1.12 made them required for allocations. | |
| 15:29:21 | jaypipes | dansmith: yes, I've argued this with both cdent and edleafe. | |
| 15:30:38 | dansmith | jaypipes: yeah, so not enforcing them in schema because people could be using older microversions is valid, but expecting people to use 1.5 going forward just because the want to create non-multitenant allocations is crazypants | |
| 15:33:25 | jaypipes | dansmith: I agree with you. | |
| 15:34:44 | openstackgerrit | Vladyslav Drok proposed openstack/nova master: ironic: Report resources as reserved when needed https://review.openstack.org/517921 | |
| 15:35:31 | fishbone_ | hello all, I receive an error in the instance log when loading windows instances: pywintypes.com_error: (-2147352567, 'Exception occurred.', (0, 'Session', 'Access is denied. ', None, 0, -2147024891), None) | |
| 15:36:15 | fishbone_ | My first assumption is updating the cloudbase-init package on the images but would anyone know another possible cause? | |
| 15:37:38 | melwitt | dansmith: looks like any update of allocations will delete the already existing allocations, so because user/project is required >= 1.8, compute updates should result in ensuring user/project exist for allocations https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/objects/resource_provider.py#L2065 | |
| 15:38:01 | dansmith | melwitt: right, but computes don't just update allocations all the time | |
| 15:38:36 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Remove support for Intel CMT `perf` events https://review.openstack.org/565242 | |
| 15:38:54 | melwitt | okay, I had thought there was a periodic update, but that was temporary right? I think that was happening back when microversion 1.8 was added | |
| 15:39:59 | dansmith | melwitt: we don't heal active instances since ocata | |
| 15:41:12 | melwitt | dansmith: okay, I think 1.8 was added in pike. so it sounds like we are missing a migration of already existing instances | |
| 15:41:39 | dansmith | melwitt: well, it doesn't matter if we're not going to do the needful on the placement side | |
| 15:41:45 | dansmith | I mean, doesn't matter for my question above | |
| 15:41:55 | dansmith | matters for us using that data for quotas later, but not what I was asking about | |
| 15:42:07 | dansmith | hmm, I have op for some reason.. do we need a topic update before I drop it? | |
| 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 | |