Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2022-03-01
16:36:25 elodilles bauzas: ++
16:36:49 bauzas I don't see any reason to hold a stable release but I could be wrong, I need to look at the open patchs
16:36:54 bauzas patches* even
16:37:26 bauzas but yeah, we need other cores for the stable branches fixes :)
16:37:32 bauzas just sayin'
16:37:51 opendevreview Dan Smith proposed openstack/nova master: Add support for volume backed server rebuild https://review.opendev.org/c/openstack/nova/+/820368
16:37:52 opendevreview Dan Smith proposed openstack/nova master: Add conductor RPC interface for rebuild https://review.opendev.org/c/openstack/nova/+/831219
16:37:52 opendevreview Dan Smith proposed openstack/nova master: Add API support for rebuilding BFV instances https://review.opendev.org/c/openstack/nova/+/830883
16:37:54 dansmith whoami-rajat: ^
16:38:21 elodilles if bug fixes are landing during FF and final RC and we backport some of them then we can do another round of stable release
16:38:36 elodilles i think ^^^
16:38:37 bauzas dansmith: dude, we're in meeting, shhhttttt :p
16:38:49 bauzas gibi: oh, that.
16:38:53 bauzas gibi: could be fixable
16:38:56 gibi ;)
16:39:10 elodilles :)
16:39:14 dansmith bauzas: apologies
16:39:31 bauzas dansmith: heh no worries you're not the first and you won't be the last
16:39:49 bauzas that's the drawback of in-channel meetings per se
16:39:55 bauzas anyway
16:39:59 bauzas nothing on stable, folks ?
16:40:27 bauzas guess not
16:40:32 bauzas #topic Open discussion
16:40:39 bauzas this topic has nothing on the agenda
16:40:50 bauzas any stuff someone wants to raise ?
16:41:00 bauzas or shall I close it ?
16:41:04 sean-k-mooney i have one thing for us to reflect on. os-vif is pretty stable at this point i wonder if it makes sense to move to release independet
16:41:32 bauzas sean-k-mooney: interesting thoughts but I wonder if that would be more suitable at a PTG timing
16:41:43 bauzas I'd be interested in hearing thoughts from the neutron team
16:41:45 sean-k-mooney we dont need to make any decission now ya we can discuss at ptg
16:42:15 bauzas tbc, release-independent doesn't prevent you to release at milestones
16:42:23 sean-k-mooney correct
16:42:25 bauzas it's just, you're free to do as you want
16:42:32 sean-k-mooney it just remove the requiremetn to have at least one release a cycle
16:42:41 bauzas sec
16:42:46 bauzas verifying the requirements
16:43:00 sean-k-mooney we tend to have enough to do 1 release a cycle but typically dont have a need to do more hten one
16:43:10 sean-k-mooney which we can do with the current model too
16:43:12 elodilles https://releases.openstack.org/reference/release_models.html#independent
16:43:20 elodilles the definition ^^^
16:43:27 bauzas damn, burned
16:43:34 elodilles :]
16:43:59 sean-k-mooney we currently use cycle-with-intermediary which works fine
16:44:20 bauzas well, then let's discuss this at the PTG
16:44:24 sean-k-mooney but most of the changes tend to be paper work
16:44:26 sean-k-mooney ack
16:44:39 bauzas enforcing a release per cycle is something a bit loud, but this could be necessary
16:45:04 bauzas releasing the enforcement doesn't sound bad at a first glance, but I wonder the implications
16:45:16 elodilles one significant thing is that os-vif won't have stable branches,
16:45:26 elodilles but i think not so much backports arrives there
16:45:34 sean-k-mooney elodilles: ya but we dont really do backports often
16:45:46 elodilles sean-k-mooney: ++
16:45:53 sean-k-mooney we do bug i can proably count them on two hands for the last 2-3 releases
16:45:55 bauzas but then we loose the possibility of doing them :)
16:46:02 sean-k-mooney yep
16:46:07 sean-k-mooney lets talk about it later
16:46:10 bauzas yup
16:46:13 sean-k-mooney just wanted people to think about it
16:46:16 bauzas thanks
16:46:25 bauzas any other topic ?
16:46:54 bauzas sean-k-mooney: please put it somewhere in your brain until the ptg etherpad is created, I don't want to miss this conversation at the PTG
16:47:28 bauzas that said, if nobody has any items...
16:47:37 bauzas thanks all
16:47:42 bauzas #endmeeting
16:47:42 opendevmeet Meeting ended Tue Mar 1 16:47:42 2022 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:47:42 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2022/nova.2022-03-01-16.00.html
16:47:42 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2022/nova.2022-03-01-16.00.txt
16:47:42 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2022/nova.2022-03-01-16.00.log.html
16:47:47 elodilles thanks bauzas o/
16:47:51 chateaulav \o
16:48:04 gibi \o
16:48:44 chateaulav gibi: thanks as well, i appreciate all the help again!
16:48:59 chateaulav sean-k-mooney: you as well
16:50:21 gibi chateaulav: thanks for the work!
17:11:44 sean-k-mooney chateaulav: no worries.
17:16:19 opendevreview Dan Smith proposed openstack/nova master: Add support for volume backed server rebuild https://review.opendev.org/c/openstack/nova/+/820368
17:16:19 opendevreview Dan Smith proposed openstack/nova master: Add conductor RPC interface for rebuild https://review.opendev.org/c/openstack/nova/+/831219
17:16:20 opendevreview Dan Smith proposed openstack/nova master: Add API support for rebuilding BFV instances https://review.opendev.org/c/openstack/nova/+/830883
18:00:24 dansmith whoami-rajat: looks like there were more unit fails on the base patch.. I had only been going after the one that failed in the top patch
18:00:30 dansmith probably more of the same needed further down
18:04:59 whoami-rajat dansmith, those were the tests i was referring to, they should be fixed with a single line in the test conductor code
18:05:01 whoami-rajat https://review.opendev.org/c/openstack/nova/+/831219/10/nova/tests/unit/conductor/test_conductor.py
18:05:05 whoami-rajat L#389
18:05:23 dansmith whoami-rajat: ah okay so you're on top of it?
18:06:01 whoami-rajat dansmith, i was skeptical about fixing conductor tests in the compute patch initially
18:06:08 whoami-rajat i can do that update if it sounds right
18:06:29 dansmith yeah, conductor calls compute rpc, so if compute rpc client changes, then those tests have to change to match
18:09:53 whoami-rajat dansmith, but we're fixing these tests because we added the conductor parameter (hack) which shouldn't have been there in the first place in the compute patch, also they're easier to fix since all rebuild args are placed at one place but we're fixing 18 tests because of a code change that shouldn't exist in this patch
18:10:00 whoami-rajat that's why i was skeptical about it ^
18:10:29 dansmith I don't see it that way at all :)
18:10:57 dansmith the reason to break these things apart is to make sure each step works, because in reality, not all the services get upgraded at the same time in a real deployment,
18:11:36 dansmith so doing the steps like this help ensure that we're not just shifting the state of the world atomically, which is how we discovered that the behavior of rebuild had changed, when we separated the api patch from the implementation
18:12:13 dansmith it's not a "hack" to add a parameter that is the equivalent of what we have today as we step through those changes, it's just keeping things compatible
18:13:54 whoami-rajat I understand why we are doing it like this but we already have rpc versions to check and maintain that compatibility (although this provides more assurance)
18:14:24 whoami-rajat but again, in a real deployment as well, if the compute is new and conductor is old, we will see the same failure in the logs as these tests
18:14:30 dansmith but we had versions in the initial unified patch, which weren't properly honoring the old behavior :)
18:14:59 dansmith whoami-rajat: just FYI, conductor always has to be upgraded before compute, it's in our upgrade process
18:15:08 dansmith api and conductor together, compute after
18:18:10 whoami-rajat we weren't passing the reimage_boot_volume parameter down to the compute in the initial patch so there weren't the RPC bumps but i get what you're saying, we wouldn't have discovered the issue if it wasn't for the split
18:18:25 whoami-rajat maybe it's just new for me to split the different services code apart

Earlier   Later