| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-12-08 | |||
| 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 | |
| 09:58:14 | sean-k-mooney | you dont have to do that for show | |
| 09:58:25 | sean-k-mooney | as far asim aware jsut the list endpoint | |
| 09:59:02 | sean-k-mooney | anyway its fine do we still need a spec if we are not changing the api now | |
| 09:59:49 | sean-k-mooney | we will start soft deleting them in the db but we will change the api to ignore the deleted column | |
| 10:00:21 | sean-k-mooney | so the behavior is the same. | |
| 10:00:33 | gibi | do we need to add a data migration to fill the deleted column of existing actions? | |
| 10:00:53 | gibi | maybe based on the the fact if the instance is deleted or not yet | |
| 10:03:27 | sean-k-mooney | i dont think we do | |
| 10:03:37 | sean-k-mooney | we can just remvoe the deleted column form the query | |
| 10:03:57 | gibi | OK, then I think we don't need a spec, but I let bauzas to decide with his PTL hat | |
| 10:03:58 | sean-k-mooney | we can have an optional nova-manage command to fill it in | |
| 10:04:13 | sean-k-mooney | but i dont think it should be required | |
| 10:05:04 | bauzas | gibi: my first comment was to say : OK for a specless BP *but* not for the last phrase | |
| 10:06:03 | bauzas | https://meetings.opendev.org/meetings/nova/2021/nova.2021-12-07-16.00.log.html#l-203 | |
| 10:07:17 | gibi | <bauzas> "We should also implement the possibility to retrieve deleted instance actions as we do for instances." seems like an API change, right? | |
| 10:07:27 | gibi | but there our answer is to keep the API as is | |
| 10:07:43 | gibi | that fullfills this requirement without any API behavior change | |
| 10:07:59 | gibi | as the API always returns both deleted and not delete actions :) | |
| 10:08:25 | gibi | if the requirement is to retrive deleted instance actions _only_ | |
| 10:08:29 | gibi | then there is an API change | |
| 10:10:40 | sean-k-mooney | gibi: ya i dont think there really is a usecase fo deleted _only_ | |
| 10:11:04 | sean-k-mooney | so i think we are ok to not change the db | |
| 10:11:07 | sean-k-mooney | *api | |
| 10:11:27 | gibi | yepp, I'm on that side yesa | |
| 10:11:43 | sean-k-mooney | so the cahnge is really to two things | |
| 10:12:03 | sean-k-mooney | the server delete sql query/funciton will need to soft delete the instance actions | |
| 10:12:23 | sean-k-mooney | and the instance actions quies will need to ignore the deleted field | |
| 10:12:29 | sean-k-mooney | and that shoudl be sufficnet | |