| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-12-08 | |||
| 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 | |
| 10:12:46 | pslestang | bauzas: I can change the BP to remove the possibility to retrieve deleted instance action as the solution proposed does not need such feature | |
| 10:12:57 | sean-k-mooney | oh and server restore shoudl also restore the instance_actions | |
| 10:13:05 | bauzas | pslestang: okay then | |
| 10:14:45 | pslestang | bauzas: done | |
| 10:15:43 | bauzas | gibi: sean-k-mooney: would we need to modify the DB if we accept to soft-delete the instance actions ? | |
| 10:16:05 | bauzas | pslestang: maybe that's here we would need to discuss about upgrades | |
| 10:16:15 | gibi | bauzas: we need to modify the DB yes, and need to modify the DB query the API does to ignore the new column | |
| 10:16:37 | bauzas | that's my question | |
| 10:16:47 | gibi | so if you are strict then there is an upgrade impact, as the db schema changes | |
| 10:16:47 | bauzas | for upgrades | |
| 10:17:10 | bauzas | I mean | |
| 10:17:18 | bauzas | for upgrading there are two directioins | |
| 10:17:34 | bauzas | 1/ we want to modify the DB for already existed instance actions | |
| 10:17:51 | bauzas | 2/ we don't do it and we only soft-delete the new instance actions | |
| 10:18:08 | bauzas | 1/ would mean that we would need to have a nova-manage command | |
| 10:18:27 | bauzas | 2/ wouldn't | |
| 10:18:53 | bauzas | for both, we need to discuss how the API query would do | |
| 10:19:01 | bauzas | remember that we have cells v2 | |
| 10:19:22 | bauzas | so we would need to know whether the cell DB is upgraded or not | |
| 10:19:33 | bauzas | before calling the instance actions table | |
| 10:19:41 | bauzas | (from the API I mean) | |
| 10:20:04 | bauzas | anyway, I need to get my kid from school in a few mins | |
| 10:20:27 | bauzas | but I guess we probably need to want to discuss about the upgrade questions in some... spec ? | |
| 10:20:45 | gibi | bauzas: that is your call :) I'm happy to discuss this in a spec | |
| 10:21:01 | bauzas | I don't wanna use my baton | |
| 10:21:08 | bauzas | it's more a core question | |