| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-12-08 | |||
| 12:27:49 | lyarwood | ACK thanks | |
| 12:28:14 | lyarwood | looks like an issue before that as the neutron-metadata-agent on the compute isn't even seeing the requests | |
| 12:28:29 | lyarwood | I guess with plugging but AFAICT from the compute logs that worked | |
| 12:29:53 | sean-k-mooney | the neutorn-metadata-agent is typeiclay not on the compute but on the contler | |
| 12:30:09 | sean-k-mooney | it runs in either the router or dhcp agent network namespaces | |
| 12:30:14 | sean-k-mooney | depening on your config | |
| 12:30:27 | sean-k-mooney | ovn works slightly differntly and i think it does it on each compute | |
| 12:30:43 | sean-k-mooney | but the agent there is jsut calling the nova metadta api | |
| 12:31:06 | sean-k-mooney | the api i belive generates the instnace mentadta directly itself and caches it | |
| 12:32:48 | sean-k-mooney | for libvirt we generate it here by the way as part of creating the config drive https://github.com/openstack/nova/blob/e537d90d6fc0977742f7126c3f8cfef6bf8b2a15/nova/virt/libvirt/driver.py#L4782 | |
| 12:36:10 | sean-k-mooney | lyarwood: are we using memcache downstream | |
| 12:36:25 | sean-k-mooney | we had to enable it upstream to make the ci stable | |
| 12:36:40 | sean-k-mooney | without it differrnt request could go to differnt api workers | |
| 12:36:57 | sean-k-mooney | cloud-init will only retry the first request | |
| 12:37:09 | sean-k-mooney | and after that it assuem the data is avaiable and does not retry them | |
| 12:37:28 | sean-k-mooney | if you hit a different worker and the node is under powered that can lead to timeouts | |
| 12:37:47 | sean-k-mooney | or failure to retive the data as genertatd the metadata is actully quite expensive | |
| 12:56:39 | lyarwood | sorry had to drop quickly for lunch | |
| 12:57:51 | lyarwood | this is part of a queens to train upgrade job downstream and it looks like the neutron metadata services are running on the computes | |
| 12:58:04 | lyarwood | I think this is failing post upgrade to train but it's super confusing | |
| 12:58:08 | lyarwood | jenkins-- | |
| 13:00:45 | lyarwood | ah no it's pre upgrade on queens | |
| 13:09:23 | gryf | asfdsdf | |
| 13:11:57 | kashyap | gryf: Thanks; hope you don't change your password :D | |
| 13:13:57 | gryf | kashyap, not really, just the ssh connection hiccup ;) | |
| 13:14:27 | kashyap | Heh, was just trolling ya | |
| 13:16:05 | gryf | I figured :) | |
| 13:22:18 | pslestang | ccccccdlucfhelkhccngbvunedtddhhlecgrlcdverhc | |
| 13:22:40 | pslestang | ouup's sorry | |
| 13:22:49 | pslestang | hello by the way! | |
| 13:22:52 | kashyap | That's a YubiKey :) | |
| 13:22:58 | pslestang | ;-) | |
| 13:23:10 | gryf | that's looks definitely like a sort of pass ;P | |
| 13:23:25 | kashyap | pslestang: There's a setting to actually make YubiKey to _not_ send the key press automatically | |
| 13:23:45 | kashyap | Lemme post my notes. I have a Nano | |
| 13:25:23 | pslestang | kashyap: I do not have a press button, my yubikey is near the enter key and when I touch the edge of the enter key ccccccdlucfhekeerjhdnrejghllkrdvdnjnjnijknbt | |
| 13:25:44 | pslestang | you see waht I mean | |
| 13:25:58 | gryf | pslestang, just change usb port :) | |
| 13:26:05 | pslestang | already done | |
| 13:26:09 | gryf | :D | |
| 13:27:11 | kashyap | pslestang: What I'm saying is that once you touch it, it automatically sends return keypress. That way you can still touch it while you're active on this channel, and it won't post it here | |
| 13:27:24 | kashyap | See what I mean? | |
| 13:27:30 | kashyap | pslestang: This one - https://kashyapc.fedorapeople.org/YubiKey-Nano-Config-for-Return-Key.html | |
| 13:30:31 | pslestang | kashyap: thx for sharing this, it will definitely be part of my setup | |
| 13:31:09 | kashyap | When I said "That way ..." above, I meant to say _once_ you use the above config. :) | |
| 13:33:49 | pslestang | kashyap: just applied, works great, thx! | |
| 13:34:05 | kashyap | Cool. | |
| 13:40:07 | kashyap | pslestang: (I had broken formatting in the above page; fixed it now. I see that you were able to see through it) | |
| 13:43:49 | pslestang | kashyap: yep I automatically 's/ /</br>/' whith my eyes in the corresponding lines :) | |
| 14:29:59 | gsantos | Hello, folks. I'm the owner of https://review.opendev.org/c/openstack/nova/+/815373 , which was just merged, and I was wondering if a backport of this fix to the previous branches would be feasible. I'm looking at Ussuri, specifically. | |
| 14:31:12 | lyarwood | gsantos: I would think so but it's conditional on the version of libvirt used right? | |
| 14:37:40 | gsantos | Yes, that is a concern. It needs at least libvirt v4.3.0, and the minimum libvirt version for Ussuri seems to be 4.0.0 | |
| 14:40:07 | lyarwood | gsantos: kk that's easy enough to handle in the backport however | |
| 14:46:38 | gsantos | Great! So, in order to do that, do I cherry pick (and resolve conflicts for) this commit to the xena, wallaby, victoria and ussuri branches? | |
| 14:52:30 | lyarwood | gsantos: Correct, https://docs.openstack.org/project-team-guide/stable-branches.html#processes | |
| 14:52:50 | lyarwood | gsantos: and add in the libvirt version check once our MIN_LIBVIRT_VERSION dips below 3.2.0 | |
| 14:52:55 | lyarwood | sorry 4.3.0 | |
| 14:57:32 | opendevreview | Alexey Stupnikov proposed openstack/nova master: Test aborting queued live migration https://review.opendev.org/c/openstack/nova/+/776250 | |
| 15:06:00 | opendevreview | mitya-eremeev-2 proposed openstack/nova master: Delete bogus attachments. https://review.opendev.org/c/openstack/nova/+/820935 | |
| 15:12:47 | opendevreview | mitya-eremeev-2 proposed openstack/nova master: Delete bogus attachments. https://review.opendev.org/c/openstack/nova/+/820935 | |
| 15:15:52 | EugenMayer | when getting `--os-compute-api-version 2.26 or greater is required to support the --not-tag option` while using xena, is that expected? | |
| 15:20:42 | EugenMayer | interestingly, that is only the case for the openstack cli, using nova list --not-tags works without issues | |
| 15:21:17 | opendevreview | Merged openstack/nova-specs master: Allow project admin to list hypervisors https://review.opendev.org/c/openstack/nova-specs/+/793011 | |
| 15:33:47 | gsantos | lyarwood: I will try to make these cherry-picks today. Thank you! | |
| 15:39:40 | sean-k-mooney | lyarwood: if you have time can you look at https://review.opendev.org/c/openstack/nova/+/820531 i think the patch looks ok but it would be good to have your input. its pretty small | |
| 15:59:09 | lyarwood | sean-k-mooney: yeah that doesn't look correct | |
| 15:59:17 | lyarwood | I'll write up some notes after some downstream calls | |
| 16:00:35 | sean-k-mooney | ack | |
| 16:08:26 | opendevreview | Merged openstack/nova master: Reattach mdevs to guest on resume https://review.opendev.org/c/openstack/nova/+/815373 | |
| 16:54:22 | EugenMayer | Trying to us `--not-tags` with the openstack cli - tells me that my API version '--os-compute-api-version 2.26 or greater is required to support the --not-tag option' - is this expected with xena? seems like https://docs.openstack.org/releasenotes/nova/en_GB/xena.html tells me, that xena has v2.90. - any hints? | |
| 16:56:43 | melwitt | EugenMayer: it is expected, you have to pass --os-compute-api-version 2.26 with the command else by default OSC uses the oldest available microversion 2.1. it does not default to latest microversion | |
| 17:03:40 | EugenMayer | ah ! thank you sir! | |
| 19:54:21 | eandersson | Anyone know if the bug with orphaned neutron ports when deleting a VM on a offline compute fixed in newer versions of OpenStack? Also not super sure if it is a Neutron or Nova bug :p | |
| 20:55:18 | opendevreview | Gustavo Santos proposed openstack/nova stable/xena: Reattach mdevs to guest on resume https://review.opendev.org/c/openstack/nova/+/821126 | |
| #openstack-nova - 2021-12-09 | |||
| 08:02:40 | gibi | o/ morning nova | |
| 08:03:08 | gibi | sean-k-mooney, bauzas, gmann: yesterday I forgot to read back on the instance_action proposal from Tuesday. Now I did | |
| 08:03:37 | gibi | my view is that we can and therefore should decouple the API behavior from the DB representation | |
| 08:04:15 | gibi | so if we agree that we change the deletion of instance_action in the DB that should not impact how our API behaves | |
| 08:05:04 | gibi | so assuming we agree to make the instance action DB table rows soft deleted when the instance is soft deleted, we should change our query in the API to read soft deleted instance actions too | |
| 08:05:39 | gibi | and then we are done. OVH gets the DB consistency they need, and nova keeps all the external behavior unchanged | |
| 08:05:42 | gibi | win - win | |
| 08:17:40 | pslestan1 | hello! | |
| 08:19:49 | pslestan1 | gibi: agree with that and seems aligned with what sean-k-mooney suggested | |
| 08:20:17 | gibi | pslestan1: o/ | |
| 08:20:25 | bauzas | gibi: yup, but we discussed about the default for the new microversion | |
| 08:20:39 | gibi | does anybody requested an API change on nova? :) | |
| 08:21:16 | bauzas | gibi: your thought was what I said first | |
| 08:21:25 | gibi | or rephrahsing that, why we want to change API behavior? | |
| 08:21:28 | bauzas | gibi: I don't wanna change the API | |
| 08:21:42 | gibi | cool, then we are on the same page | |
| 08:22:17 | pslestan1 | gibi: about DB consistency I guess that it's more a community oriented choice than OVH only, I mean this is a good thing to get a consistency for everybody not only OVH | |
| 08:23:01 | gibi | pslestan1: sure, sorry for pin it up on OVH, just needed a name for the set of people who need this change | |
| 08:23:25 | pslestan1 | gibi: don't worry | |
| 08:23:28 | gibi | :) | |
| 09:57:00 | sean-k-mooney | gibi: yep i was orginaly suggesting that if we were ever going to change the api behaivor it made sense to cahnge it now but it looks like we dont want to expose this at the api at all | |
| 09:57:24 | sean-k-mooney | gibi: chanig the api behavior would be just to have partity with the servers endpoint | |
| 09:57:25 | gibi | I don't need the API behavior to change | |
| 09:57:46 | gibi | I think it make sense that the history of a VM overlives the VM itself | |
| 09:58:03 | gibi | outlive :D | |
| 09:58:08 | sean-k-mooney | for server list you need to pass --deleted to see the soft deleted ones | |