| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-07-04 | |||
| 13:25:34 | opendevreview | Vladislav Belogrudov proposed openstack/nova master: Nova instance snapshot should wait for volumes https://review.opendev.org/c/openstack/nova/+/848638 | |
| 13:31:26 | opendevreview | sean mooney proposed openstack/nova master: enable blocked VDPA move operations https://review.opendev.org/c/openstack/nova/+/832330 | |
| 15:42:57 | gibi | bauzas: I re-used https://bugs.launchpad.net/nova/+bug/1960346 to tack the qemu detach fix as a gate-failure bug for nova | |
| 16:16:31 | bauzas | gibi: cool thanks | |
| 16:32:29 | sean-k-mooney | bauzas: gibi by the way this would be nice to merge sooner rather then later https://review.opendev.org/c/openstack/nova/+/830829 | |
| 16:32:49 | sean-k-mooney | its the overcommit default change we defered form m3 last cycle | |
| 16:35:37 | sean-k-mooney | i would like to merge that before m2 if we can | |
| 16:55:58 | gibi | sean-k-mooney: provided feedback now | |
| 17:14:19 | sean-k-mooney | gibi: thanks ill looke at it shortly | |
| 18:08:58 | opendevreview | Amit Uniyal proposed openstack/nova master: Adds check, if admin has set compute service down https://review.opendev.org/c/openstack/nova/+/848660 | |
| #openstack-nova - 2022-07-05 | |||
| 07:10:35 | bauzas | happy spec review day everyone | |
| 07:18:19 | opendevreview | Vladislav Belogrudov proposed openstack/nova master: Nova instance snapshot should wait for volumes https://review.opendev.org/c/openstack/nova/+/848638 | |
| 11:39:51 | bauzas | cores, need a second jab on https://review.opendev.org/c/openstack/nova-specs/+/833669 | |
| 11:48:16 | gibi | bauzas: I've started checking the manila spec | |
| 12:02:13 | sean-k-mooney | ill be switching form downstream stuff to spec review shortly | |
| 12:13:22 | gibi | Uggla, bauzas, sean-k-mooney: I'm OK with the manila spec https://review.opendev.org/c/openstack/nova-specs/+/833669 I hold +A for sean-k-mooney to check it. | |
| 12:13:28 | bauzas | ++ | |
| 12:14:32 | gibi | bauzas: did you managed to add some feedback to the ironic spec? | |
| 12:14:40 | bauzas | gibi: not yet | |
| 12:14:46 | Uggla | gibi, \o/ | |
| 12:14:59 | gibi | i've just started reading it, but I have to jump on a call soon so probably finish it after | |
| 12:15:03 | bauzas | I had to leave it given we have a meeting today and I didn't have time to look at the bugs before | |
| 12:15:13 | gibi | ack | |
| 13:00:43 | opendevreview | Vladislav Belogrudov proposed openstack/nova master: Nova instance snapshot should wait for volumes https://review.opendev.org/c/openstack/nova/+/848638 | |
| 13:20:20 | ozzzo_home_ | We accidentally created a flavor without swap, and we need to add it. What will happen to VMs using that flavor if we delete and re-create the flavor with swap added? Will they still be able to restart, migrate, etc.? | |
| 13:20:36 | ozzzo_home_ | Is changing it in the database a viable alternative? | |
| 13:26:18 | sean-k-mooney | ozzzo_home_: yes they will however they will not have swap | |
| 13:26:36 | sean-k-mooney | the correct thing to do woudl be to create a new flavor | |
| 13:26:42 | sean-k-mooney | resize the existing isntnaces to that | |
| 13:26:46 | sean-k-mooney | and then delete the old flaovr | |
| 13:27:14 | sean-k-mooney | ozzzo_home_: when you boot a vm we copy the current flavor and embed that in the instnace_extra table | |
| 13:27:24 | sean-k-mooney | so that we preserve the state as it was when the vm was booted | |
| 13:27:52 | sean-k-mooney | that is imporant to make sure that chagnes such as adding swap or other changes that affect resouce usage do not propagate to the vm | |
| 13:28:30 | sean-k-mooney | as that woudl potentially violate the current secheduling desicion and woudl invalidate the placment resouce allcoations | |
| 13:31:57 | ozzzo_home_ | in the doc where it says " Nova has historically intentionally not included an API to update a flavor because that would be confusing for instances already created with that flavor. " - confusing means that the placement database would contain incorrect information about existing VMs using that flavor? | |
| 13:33:25 | ozzzo_home_ | the reason we're considering changing it in the database is because we have standard flavor names, and if the flavor names change it would be a huge upheaval for customers who have that name hardcoded into their automation | |
| 13:35:06 | ozzzo_home_ | the client won't let me create a flavor with the same name, so it seems like the alternatives are delete first and then re-create, or else change in the DB | |
| 13:41:45 | bauzas | gibi: I'll need to leave earlier the meeting after 40 mins, could you then please chair it for the last 20 mins ? | |
| 13:42:15 | gibi | sure | |
| 13:42:29 | gibi | but we need you for the centos 9 stream topic | |
| 13:43:41 | sean-k-mooney | ozzzo_home_: placement would have the correct information based on the flaovr that was used at boot | |
| 13:44:02 | sean-k-mooney | ozzzo_home_: if you just update the flavor in the nova db you will make the nova db inconsitnet with the placment db | |
| 13:44:26 | bauzas | gibi: yeah we'll discuss it first | |
| 13:44:47 | gibi | ack | |
| 13:44:50 | sean-k-mooney | ozzzo_home_: nova has no supported mechanium for changing flaovr they are read only | |
| 13:45:05 | sean-k-mooney | ozzzo_home_: so any modifcation you do will be outside the supprot of nova | |
| 13:45:18 | ozzzo_home_ | sean-k-mooney: How can I explain to my co-workers why changing it in the DB is a bad idea? What would be the customer-facing consequences of DB inconsistency? | |
| 13:45:47 | sean-k-mooney | well if you update just the flavor the existing vms would not user any swap | |
| 13:45:51 | sean-k-mooney | but new vms would | |
| 13:46:27 | sean-k-mooney | if you also updated the existing vms embeded flavor copy you woudl break the resouce usage view tracked in palcment | |
| 13:46:43 | sean-k-mooney | which means you could have scheuling issues in the future as you might run out of disk space | |
| 13:46:53 | sean-k-mooney | since the vms will be using more disk for swap | |
| 13:47:19 | sean-k-mooney | if you also fix the placment allcoations then it would work but you have then doen two highly error prone operations on two differnt dbs | |
| 13:47:31 | ozzzo_home_ | What if we delete the flavor first and then create a new one with the same name. Will that cause the same problem? | |
| 13:47:47 | sean-k-mooney | it will have no affect on exsitng vms | |
| 13:48:03 | sean-k-mooney | but new vms will use the new resouces specified in teh flavor | |
| 13:48:06 | sean-k-mooney | if any of your custoemr were using the falvor uuid | |
| 13:48:11 | sean-k-mooney | it will break | |
| 13:48:19 | sean-k-mooney | if they just use the name it would use the new flavor | |
| 13:49:20 | sean-k-mooney | ozzzo_home_: if you updated the flavor in the db and updated the embded flavor in the instnace_extra table and upded the embeded flavor in the request spec then a cold migrate would fix the plamcent allcoaitons | |
| 13:49:37 | sean-k-mooney | and result in the vms beign allcoted swap on the destination host | |
| 13:49:47 | sean-k-mooney | but that is not tested or supported upstream | |
| 13:50:31 | sean-k-mooney | if you understand what you are doing it can be done but its error prone | |
| 13:50:46 | sean-k-mooney | which is why we would advise a resize to a new flavor | |
| 13:53:18 | sean-k-mooney | gibi: bauzas i see ye are both +2 on the manila share spec with comments. ill review that shortly and +w if everything looks ok | |
| 13:53:25 | bauzas | ++ | |
| 13:53:36 | sean-k-mooney | am ill see in a second but am i right to assume those comments can be adressed in a followup | |
| 13:58:59 | gibi | sean-k-mooney: ack | |
| 14:09:37 | ozzzo_home_ | thank you sean-k-mooney | |
| 14:33:28 | gibi | I left comment in the ironic rebalance spec. I don't feel we will have consensus today around it | |
| 14:39:48 | gibi | I have to step out for an hour I will be back for the nova meeting | |
| 15:31:53 | bauzas | reminder: nova meeting in 29 mins | |
| 15:46:30 | Uggla | bauzas, like last time I could not probably join right at the beginning, but I will join ASAP. | |
| 15:46:40 | bauzas | oki doki | |
| 15:52:36 | sean-k-mooney | Uggla: bauzas gibi i have one point that i think shoudl be fixed | |
| 15:52:50 | bauzas | ? | |
| 15:52:53 | sean-k-mooney | but its minor | |
| 15:53:10 | sean-k-mooney | let me push my review one sec | |
| 15:53:44 | sean-k-mooney | basically in the api request for share we shoudl reserver "tag" for device role tagging and use mount_tag for the mount_tag for the share | |
| 15:54:56 | sean-k-mooney | also i tought we had aggreed to include implemnting the device role tagging supprot in this api but i did not see that in the spec | |
| 15:55:50 | sean-k-mooney | we do cover updating the metdata to make the mount_tag and share id discoverable | |
| 15:56:05 | sean-k-mooney | but we are overloading teh same field for both | |
| 15:56:54 | gibi | when would it make sense to set the tag and mount_tag to different values? | |
| 15:56:56 | sean-k-mooney | im not sure we want to overload tag for both the mount tag and the metadata deivce_role tag | |
| 15:57:39 | sean-k-mooney | gibi: well concpetully the server very differnt functions | |
| 15:57:48 | sean-k-mooney | so i would not generally assume they shoudl be the same | |
| 15:58:38 | sean-k-mooney | the tag in device role taging terms is ment to map to a high level concpet | |
| 15:58:45 | gibi | I though device tag is there so that the guest can match the device it sees and the device it requested from openstack | |
| 15:58:46 | sean-k-mooney | like database or backup | |
| 15:59:12 | sean-k-mooney | where as the mount_tag is a low level detail fo the virtio-fs protocol | |
| 15:59:32 | sean-k-mooney | if we supported soemthign other then virtio-fs for manilla shares that detail might change | |
| 15:59:34 | bauzas | warning : nova meeting starting soon | |
| 15:59:52 | gibi | sean-k-mooney: table this to the end of the meeting | |
| 15:59:56 | sean-k-mooney | ack | |
| 16:00:01 | bauzas | #startmeeting nova | |
| 16:00:01 | opendevmeet | Meeting started Tue Jul 5 16:00:01 2022 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | |
| 16:00:01 | opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | |
| 16:00:01 | opendevmeet | The meeting name has been set to 'nova' | |
| 16:00:10 | bauzas | sean-k-mooney: sorry had to start the meeting | |
| 16:00:18 | bauzas | hello 'veryone | |