| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-23 | |||
| 16:54:28 | sean-k-mooney | speificly is there a usecase you are trying to enable that is a usecase for the end user/tenant not the operator | |
| 16:54:30 | jhartkopf | sean-k-mooney: Cloud-init supports this as well, yes. But why would you want to restrict API functionality and potentially restrict other's workflows? | |
| 16:55:09 | bauzas | sean-k-mooney: indeed, cases about end user | |
| 16:55:16 | sean-k-mooney | the user-data is "owned" by the enduser so if the reason to make it mutable is so operators can chagne it it would not be consitnet with the usage of that api | |
| 16:55:39 | dasp | when rebuilding an instance, you can't redeclare userdata (AFAIK) but you effectively make cloud-init re-run, that's a trap my users run into | |
| 16:56:07 | sean-k-mooney | dasp: for rebuild we do allow new user data to be pass in a later microverion i belive | |
| 16:56:18 | bauzas | yeah that rings me a bell | |
| 16:56:19 | sean-k-mooney | dasp: you are correct that orginally we did not | |
| 16:56:19 | bauzas | sec | |
| 16:56:21 | dasp | oh, sorry my org is running a bit "behind" on versions | |
| 16:57:12 | bauzas | sean-k-mooney: 2.3 | |
| 16:57:18 | bauzas | so... Kilo | |
| 16:57:20 | sean-k-mooney | 2.54 allows the key to be changed on rebuild https://docs.openstack.org/nova/latest/reference/api-microversion-history.html#id50 and 2.57 allows user data to be updated | |
| 16:57:48 | bauzas | oh, that one | |
| 16:57:52 | sean-k-mooney | bauzas: its no 2.3 | |
| 16:57:59 | bauzas | yeah my bad | |
| 16:58:06 | bauzas | this is Queens | |
| 16:58:06 | sean-k-mooney | but ya since queens | |
| 16:58:32 | bauzas | we only have 2 mins left | |
| 16:58:41 | bauzas | (as a timekeeper) | |
| 16:59:07 | sean-k-mooney | jhartkopf: we could proably make it mutable if there is a use facing usecase but we would need to support config dirve and note that the change may not fully be ableable untill after a hard reboot | |
| 16:59:23 | bauzas | I'll have to call it a wrap | |
| 16:59:25 | bauzas | for this week | |
| 16:59:30 | bauzas | we can revisite this in the spec | |
| 17:00:21 | bauzas | #info https://review.opendev.org/c/openstack/nova-specs/+/816542 requires propre description of enduser cases for mutable user data | |
| 17:00:31 | bauzas | that's it, we're over time | |
| 17:00:34 | bauzas | thanks all | |
| 17:00:36 | bauzas | #endmeeting | |
| 17:00:36 | opendevmeet | Meeting ended Tue Nov 23 17:00:36 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | |
| 17:00:36 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-23-16.00.html | |
| 17:00:36 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-23-16.00.txt | |
| 17:00:36 | opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-23-16.00.log.html | |
| 17:01:15 | sean-k-mooney | jhartkopf: so i dont think bauzas or myself are entirly aginst this but the reasons for doing it present sofare in the spec dont fully seam valid | |
| 17:01:27 | bauzas | correct | |
| 17:01:29 | jhartkopf | Well, I understand your concerns. | |
| 17:01:41 | bauzas | copying others isn't enough for me | |
| 17:02:50 | jhartkopf | This was definitely not a copy, as you can see in the implementation. We had a use case internally, which may seem not valid to others. | |
| 17:03:42 | jhartkopf | I don't know if we will put further work into it. | |
| 17:03:50 | sean-k-mooney | jhartkopf: i think you orginally mention NTP servers chanign which i woudl have expected to be pushed out via either vendor data or neutron via dhcp | |
| 17:03:55 | opendevreview | Artom Lifshitz proposed openstack/nova master: DNM: Explode libvirt builds to trigger tempest error code https://review.opendev.org/c/openstack/nova/+/818932 | |
| 17:04:33 | sean-k-mooney | jhartkopf: i do liek the multiple key pairs or updating keypairs usecase | |
| 17:05:15 | sean-k-mooney | so perhaps if we support that it also makes sense to allow updatign the user-datat to allow bootstraping that | |
| 17:05:36 | bauzas | jhartkopf: sorry, didn't wanted to nack, I need to revisite your spec | |
| 17:06:29 | bauzas | jhartkopf: probably understanding which specific instance action you'd like the userdata to be updated, and why, would help | |
| 17:06:57 | sean-k-mooney | bauzas: well without config driver i think its just a server update | |
| 17:06:58 | bauzas | and what would be the benefit for the end user | |
| 17:07:24 | bauzas | sean-k-mooney: that's why I don't want to discuss about the solution yet | |
| 17:07:28 | sean-k-mooney | then its updated in the metadata api so the instance can retirve the new version | |
| 17:07:47 | bauzas | I need to understand the problem that a immutable userdata creaters | |
| 17:07:51 | bauzas | creates* | |
| 17:08:19 | jhartkopf | sean-k-mooney: Maybe, I have to think about that multiple SSH keys use case more. | |
| 17:09:07 | sean-k-mooney | jhartkopf: with your proposal this would also be a replace of the user data right | |
| 17:09:23 | sean-k-mooney | so you would have to get it then update it localy then submit the updated version | |
| 17:09:42 | sean-k-mooney | so its a replace not inplace update/patch | |
| 17:09:47 | jhartkopf | This replaces current user data, yes | |
| 17:10:27 | sean-k-mooney | part of my consern is this is a potenital securrity issue | |
| 17:10:51 | sean-k-mooney | in that an admin could alter the user data, reboot the instnace and then gain access to the instnace | |
| 17:11:02 | sean-k-mooney | i know the admin can get acess other ways | |
| 17:11:23 | sean-k-mooney | but its potentally problematic in some cases | |
| 17:14:43 | jhartkopf | sean-k-mooney: I see, it's something to consider. | |
| 17:15:15 | jhartkopf | Will discuss with my team and decide what to do | |
| 17:15:48 | jhartkopf | Thanks for your time sean-k-mooney and bauzas | |
| 17:16:19 | jhartkopf | have a good day :) | |
| 17:21:34 | bauzas | you too | |
| 17:39:41 | ganso | stephenfin, sean-k-mooney: hi! very quick question: in light of patch https://review.opendev.org/c/openstack/nova/+/792356 then it means this doc is incorrect, right?: https://docs.openstack.org/neutron/wallaby/admin/config-ovs-dpdk.html#using-vhost-user-multiqueue | |
| 17:40:36 | sean-k-mooney | ganso: just looking | |
| 17:40:46 | sean-k-mooney | what specificlly | |
| 17:40:56 | ganso | grepping the code in wallaby branch still doesn't turn anything up related to vif_multiqueue_enabled being used through the flavor | |
| 17:41:05 | ganso | sean-k-mooney: the doc states the property could be used in the flavor | |
| 17:41:12 | ganso | sean-k-mooney: which does not seem to be the case | |
| 17:41:16 | sean-k-mooney | yes so that will need to be udated as part of this change | |
| 17:41:25 | sean-k-mooney | sorry not | |
| 17:41:45 | sean-k-mooney | it has $ openstack flavor set $m1.large --property hw:vif_multiqueue_enabled=true and $ openstack image set --property hw_vif_multiqueue_enabled=true IMAGE_NAME | |
| 17:42:59 | ganso | sean-k-mooney: oh cool so no need to update the doc, thanks! | |
| 17:43:10 | sean-k-mooney | ganso: it looks like the doc was incorreectly updated at some point | |
| 17:43:35 | sean-k-mooney | assuming likely that this chagne had already merged | |
| 17:44:08 | sean-k-mooney | ganso: there is a docs change in this serise anyway https://review.opendev.org/c/openstack/nova/+/792362/8 | |
| 17:44:18 | sean-k-mooney | which can be used to do any more change that are required | |
| 17:48:40 | opendevreview | Rodrigo Barbieri proposed openstack/nova master: Move 'hw:pmu', 'hw_pmu' parsing to nova.virt.hardware https://review.opendev.org/c/openstack/nova/+/792364 | |
| 17:49:09 | ganso | sean-k-mooney: oh thanks I had forgotten about the other patches in the topic | |
| 20:21:21 | artom | Until Neutron starts telling us authoritatively what kind of events to wait for and when, we're pushing the responsibility on the operator to tell us in config options. | |
| 20:47:21 | sean-k-mooney | artom: maybe | |
| 20:48:02 | sean-k-mooney | we have a simialir issue wiht disable ports and evacuatate apparently | |
| 20:48:21 | sean-k-mooney | im not sure we can really just set thse for every operation | |
| 21:01:09 | opendevreview | Dan Smith proposed openstack/nova master: Revert project-specific APIs for servers https://review.opendev.org/c/openstack/nova/+/816206 | |
| 21:43:14 | artom | sean-k-mooney, ugh | |
| 21:47:12 | sean-k-mooney | the disable prot issue is simpel to fix | |
| 21:47:34 | sean-k-mooney | but im not sure if the downstream evacute issue is related to the revirt migrate issue or not | |
| 21:47:59 | sean-k-mooney | artom: the event handeling is all a bit of a mess since neutron is so inconsitent when sending events | |
| 21:48:31 | sean-k-mooney | artom: latest live migration issue https://bugs.launchpad.net/nova/+bug/1951623 | |
| 21:49:11 | sean-k-mooney | i outlined the fix in comment 3 but technically neutron should be seind plug event even for disable interface | |
| 21:49:36 | artom | sean-k-mooney, yeah, so if Neutron's not fixing themselves, and we're not dumping all that complexity on the operator, then... just stop using external events altogether? | |
| 21:49:36 | sean-k-mooney | because we do plug them the agent is just ment to set the port down | |
| 21:49:55 | artom | And too bad if the instance has no network for the first few seconds? | |
| 21:50:10 | sean-k-mooney | no we need to find time to fix it | |
| 21:51:15 | sean-k-mooney | you can just disable treating vif plug failrue as error today | |
| 21:51:32 | sean-k-mooney | its not the right solution long term but you can if you need too | |
| 21:51:58 | sean-k-mooney | and we have a second option specificly for live migration i belte and now gibi has added a new one | |
| 21:52:20 | opendevreview | Artom Lifshitz proposed openstack/nova master: Add nova-next-hybrid-plug job https://review.opendev.org/c/openstack/nova/+/817303 | |
| 21:52:52 | sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.vif_plugging_is_fatal | |