| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-23 | |||
| 17:00:36 | opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-23-16.00.txt | |
| 17:00:36 | opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-11-23-16.00.html | |
| 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 | bauzas | #endmeeting | |
| 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 | sean-k-mooney | because we do plug them the agent is just ment to set the port down | |
| 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: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 | |
| 11:23:55 | lyarwood | DK4: you can also use openstack server event show $instance $request-id to dump any details about the create request and associated events if you don't have access to the env | |
| 11:24:31 | lyarwood | DK4: but tbh either way it's likely a messaging issue in your env between the conductor and computes | |
| 12:06:58 | opendevreview | Dr. Jens Harbott proposed openstack/nova master: Add nova-next-hybrid-plug job https://review.opendev.org/c/openstack/nova/+/817303 | |
| 12:12:20 | DK4 | lyarwood: thank your for help. im testing on proxmox7 it worked there before. i guess one of the kernel updates on proxmox host itself broke something instead. | |
| 12:25:14 | DK4 | lyarwood: the pvekernel 5.13 seems to break my openstack deployments. after switching back to 5.11 it starts to work again. thank you for your input! | |
| 13:04:20 | artom | frickler, *facepalm* yep, thanks for the fix :( | |
| 13:04:22 | artom | Err, :) | |
| 13:42:32 | frickler | artom: np, I've left the more interesting part of actually fixing the job for you ;) but I like the idea of testing that scenario, because that's how some of my deployments still look like | |
| 13:49:18 | ralonsoh | sean-k-mooney, hi! Can I ask you about https://review.opendev.org/c/openstack/neutron/+/818338/3/neutron/agent/linux/interface.py#369 ? | |
| 13:50:03 | ralonsoh | when using DPDK, the interfaces connected to a namespace are type=TAP? | |
| 13:51:02 | ralonsoh | well, not the interfaces but the ports | |
| 13:57:39 | sean-k-mooney | you mean for dhcp agent and l3 agent router instnaces | |
| 13:57:53 | sean-k-mooney | ralonsoh: with ovs-dpdk we do not supprot vnic_type normal | |
| 13:57:59 | sean-k-mooney | only vhost-user offically | |
| 13:58:21 | ralonsoh | sean-k-mooney, yeah but the Interface type=tap?? | |
| 13:58:26 | ralonsoh | in this patch | |
| 13:58:27 | sean-k-mooney | but the dhcp server and l3 agent can create port which should get create on ovs as interface_type=internal | |
| 13:58:29 | ralonsoh | is that correct? | |
| 13:58:34 | sean-k-mooney | no | |