Earlier  
Posted Nick Remark
#openstack-nova - 2021-11-23
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
21:52:54 sean-k-mooney and https://docs.openstack.org/nova/latest/configuration/config.html#compute.live_migration_wait_for_vif_plug
21:53:07 artom True, we have the first config option
#openstack-nova - 2021-11-24
00:52:28 artom Well crap, https://review.opendev.org/c/openstack/nova/+/817303 passed now
05:27:58 frickler artom: seems you only define the job now and don't actually run it
06:18:49 opendevreview Lee Yarwood proposed openstack/nova-specs master: libvirt: Allow Manila shares to be directly attached to instances https://review.opendev.org/c/openstack/nova-specs/+/813180
08:50:08 opendevreview Hemanth N proposed openstack/nova master: clear dhcp_server in network_info when dhcp is disabled https://review.opendev.org/c/openstack/nova/+/819069
10:51:56 DK4 im still having problems creating instances in a new deployment. instance is stuck in creating/spawning state, any hints or advices?
11:20:32 opendevreview Lee Yarwood proposed openstack/nova-specs master: libvirt: Allow Manila shares to be directly attached to instances https://review.opendev.org/c/openstack/nova-specs/+/813180
11:23:21 lyarwood DK4: Use `openstack server event list $instance` to find the request-id associated with the creation request and trace that through the system if you have access

Earlier   Later