Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-07-05
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 opendevmeet The meeting name has been set to 'nova'
16:00:01 opendevmeet Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
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 bauzas #startmeeting nova
16:00:10 bauzas sean-k-mooney: sorry had to start the meeting
16:00:18 bauzas hello 'veryone
16:00:21 gibi o/
16:01:17 elodilles o/
16:01:43 bauzas as I said to gibi, I'll need to leave in 40 mins
16:01:52 bauzas so, I'll leave the chair to gibi
16:01:54 opendevmeet Current chairs: bauzas gibi
16:01:54 bauzas #chair gibi
16:02:21 bauzas maybe we should start
16:02:47 bauzas #topic Bugs (stuck/critical)
16:02:57 bauzas #info One Critical bug
16:03:02 bauzas #link https://bugs.launchpad.net/nova/+bug/1979047 Centos 9 Stream bug failure
16:03:19 bauzas that being said, the root cause seems to be fixed on C9S
16:03:38 bauzas now, we have a revert from gibi
16:03:41 bauzas #link https://review.opendev.org/c/openstack/nova/+/848352 revert of the n-v job patch
16:03:56 bauzas for making the C9S job voting again
16:04:19 bauzas that being said, I have a concern I'd like to discuss with the team
16:04:59 bauzas https://bugzilla.redhat.com/show_bug.cgi?id=2092856 is the C9S BZ
16:05:15 bauzas if you look at it, it took about 3 weeks in order to be fixed
16:05:45 bauzas and released
16:05:53 bauzas now, my concern is about the job
16:06:17 bauzas given now Centos9 is a stream, that means that we can't just merge a fix without verifying it
16:06:23 bauzas we = RHEL team
16:07:16 bauzas so, here my concern : instead of voting again, should this job be a periodic-weekly one ?
16:07:36 sean-k-mooney well technially the centos core team could but rhel team will want it to go though qe first
16:07:49 sean-k-mooney im +1 on moving to periodic-weekly
16:08:02 sean-k-mooney i orginally did not want it to be voting this cycle
16:08:07 bauzas if we agree on it, I propose to look at the job by every week during our meeting, like we do for both placement and nova-emulation
16:08:08 gibi if we promise to look at it as part of our weekly agenda then I'm OK to move it to periodic
16:08:19 sean-k-mooney when i raised the topic at the ptg it was for ti to be nonvoting until at least m2
16:08:41 bauzas ok, any other thoughts ?
16:08:47 gibi this way we can detect breaking changes, but probably we wont detect race coditions, as there wont be enough runs for it
16:09:06 bauzas gibi: yeah
16:09:14 sean-k-mooney we can also put it in experimental
16:09:19 sean-k-mooney so we can trigger if we need too
16:09:31 sean-k-mooney but that runs more then we would like
16:09:32 bauzas gibi: what I'd also like is to find some C9S folks we could be pinging if we find an issue
16:09:38 elodilles sounds OK to be a periodic-weekly, we even free up some resource with that, right?
16:09:43 sean-k-mooney its too bad we can trigger periodics via a comment
16:09:57 sean-k-mooney elodilles: yes since it wont be per patch
16:10:04 sean-k-mooney but we can still review it regurally
16:10:05 elodilles ++
16:10:30 bauzas sean-k-mooney: yeah we could also have a experimental job if we want

Earlier   Later