| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-03-10 | |||
| 15:00:07 | bauzas | dansmith: if you have a bit of time, could we discuss about https://review.opendev.org/c/openstack/nova/+/875621/2 ? | |
| 15:00:26 | bauzas | dansmith: I'm not really a grenade expert, so I need to make sure I understood it correctly | |
| 15:01:14 | dansmith | bauzas: sure, gmann wants to wait to merge that until devstack and grenade get branched | |
| 15:01:21 | dansmith | which usually happens a bit after the last regular project | |
| 15:01:30 | bauzas | ack ok | |
| 15:01:41 | dansmith | (the dependent patch I mean) | |
| 15:01:46 | bauzas | I'll look at the open grenade changes then | |
| 15:02:16 | bauzas | dansmith: actually, I haven't done https://review.opendev.org/c/openstack/nova/+/875621/2 depending on your skip-level-always zuul patch | |
| 15:02:33 | dansmith | oh, it's merged now, I missed that | |
| 15:02:59 | bauzas | but, it still fails for the same reason : grenade has an original branch which is zed and tries to update to master, which is now Bobcat, hence the grenade job failing | |
| 15:03:24 | bauzas | so we need to update grenade to have an original branch to be antelope | |
| 15:03:45 | dansmith | you mean for regular grenade jobs? | |
| 15:03:57 | bauzas | yep, see my patch : https://review.opendev.org/c/openstack/nova/+/875621/2 | |
| 15:03:58 | dansmith | the skip-always job should be zed->bobcat | |
| 15:04:18 | bauzas | it fails on grenade-multinode https://zuul.opendev.org/t/openstack/build/cd27f6d6a4094fd48b1725e1f63098f1 | |
| 15:04:32 | bauzas | (which is an expected behaviour, if we upgrade from zed to master) | |
| 15:05:06 | dansmith | the grenade job as defined in grenade's zuul config should be moving to antelope | |
| 15:05:26 | bauzas | ok, that's what I understood and wrote in my last comment then | |
| 15:05:34 | bauzas | https://review.opendev.org/c/openstack/nova/+/875621/2#message-cef3c3bb3d8a590cd4d9bf51267a7fe092bd32b2 | |
| 15:05:42 | dansmith | that happens after all the projects are branched | |
| 15:06:03 | bauzas | okay | |
| 15:06:11 | bauzas | that's what I guessed | |
| 15:06:20 | bauzas | the service projects I guess, not the trailing ones | |
| 15:06:31 | dansmith | you're moving your OLDEST_SUPPORTED, but will use the workaround to prevent that from breaking on the skip-always job? | |
| 15:06:45 | dansmith | bauzas: anything that runs a grenade job I think | |
| 15:06:47 | bauzas | in my patch ? | |
| 15:06:52 | dansmith | yes | |
| 15:07:14 | bauzas | well, in my patch, I'm just saying we continue to only support N-1 nodes for a non-SLURP release | |
| 15:07:29 | bauzas | even if skip-always job workarounds it | |
| 15:07:41 | bauzas | hence the service version be Antelope | |
| 15:08:10 | bauzas | once grenade is modified to have a source env to be Antelope, this will work | |
| 15:08:18 | dansmith | that's what I just said yeah | |
| 15:08:27 | bauzas | and this is now unrelated to the skip-always job you're doing | |
| 15:08:41 | bauzas | since the skip-always is using the workaround flag | |
| 15:08:46 | dansmith | right | |
| 15:08:51 | bauzas | coo col | |
| 15:09:11 | bauzas | dansmith: my ping was just for making sure I was understand the job failure correctly | |
| 15:09:18 | bauzas | understanding* | |
| 15:09:32 | bauzas | thanks so | |
| 15:09:36 | bauzas | I'll wait | |
| 15:10:38 | dansmith | yeah, I dunno what gmann's schedule is for that.. we could put up the grenade change for you to depends-on I think | |
| 15:11:02 | dansmith | but i mean, you're bumping the min version, and it's failing on the min version check, because it's still upgrading from zed, so ... pretty straightforward | |
| 15:11:05 | bauzas | yup, I'll track the open grenade changes | |
| 15:11:45 | bauzas | having a depends-on is nice, because next cycle, people who would write this service version bump would remember we need to hold until grenade is updated | |
| 15:11:56 | bauzas | call it a documentation :) | |
| 15:12:02 | bauzas | actually | |
| 15:12:14 | bauzas | we won't bump next cycle, as this will be SLURP | |
| 15:12:32 | dansmith | I mean, it's pretty clear why it's failing no? :) | |
| 15:12:33 | bauzas | so the next patch to update the min will be beginning of D, in one year | |
| 15:12:35 | dansmith | but sure | |
| 15:13:02 | bauzas | dansmith: well, I had to dig into the grenade job to understand what release was used and how | |
| 15:13:21 | bauzas | nothing really difficult, but a Depends-On will make the dependency clearer :) | |
| 15:14:26 | dansmith | bauzas: devstack isn't even branched yet, so a patch can't even really work | |
| 15:14:36 | dansmith | https://github.com/openstack/devstack/branches | |
| 15:15:00 | bauzas | yeah, I guess my patch will gonna need to wait until GA probably :) | |
| 15:15:09 | bauzas | but meh | |
| 15:15:24 | dansmith | consider it a little extra skip-level coverage ;) | |
| 15:15:26 | dansmith | 1.1 releases | |
| 15:15:47 | bauzas | :) | |
| 15:15:58 | bauzas | for people deploying on master, woooo | |
| 15:16:28 | bauzas | dibs* | |
| 15:16:52 | dansmith | very incorrect use of dibs | |
| 15:17:00 | sean-k-mooney | there is nothign wrong with runnng master also that | |
| 15:17:13 | dansmith | dibs implies claim of ownership on, usually on snack foods | |
| 15:17:16 | bauzas | dansmith: pardon my French :p | |
| 15:17:19 | dansmith | haha | |
| 15:17:46 | bauzas | sean-k-mooney: oh I am not saying this is wrong to run against master | |
| 15:18:03 | bauzas | and I'd be proud if operators would do it like they did in the past | |
| 15:18:26 | sean-k-mooney | same | |
| 15:18:29 | bauzas | we respect an healthy gate and we very carefully take care of the master stability | |
| 15:18:46 | bauzas | but, alas, I think those days are gone | |
| 15:19:05 | sean-k-mooney | we are still going to try an keep it working | |
| 15:19:06 | bauzas | despite I'm considering to release a bobcat-1 for deployers needs (like zigo) | |
| 15:19:30 | sean-k-mooney | you mean the irst milestone | |
| 15:19:35 | bauzas | yes | |
| 15:19:41 | bauzas | we did it in the pasyt | |
| 15:19:45 | bauzas | but we stopped | |
| 15:19:50 | sean-k-mooney | we are technially release with intermidarys so we are allowed to realse as often as we like | |
| 15:19:55 | bauzas | I want to provide tarballs back | |
| 15:20:10 | sean-k-mooney | well we are free too its just not done automatically | |
| 15:20:22 | bauzas | I know, and that's something I want to | |
| 15:20:33 | bauzas | and bobcat-3 too | |
| 15:21:03 | sean-k-mooney | i dont really object as long as we state that they are not full releases | |
| 15:21:04 | bauzas | last RC1 was juggling so I want some tarball that people can consume | |
| 15:21:17 | bauzas | before the rc1 one | |
| 15:21:23 | sean-k-mooney | i.e. we wont have bances for them so if they need bugfixes they will have to wiat fo rthe next one | |
| 15:21:37 | bauzas | sean-k-mooney: as a reminder, m-1 or m-3 are considered alphas on a semver | |
| 15:21:38 | zigo | IMO, just having a *subset* of OpenStack doing milestones isn't helpful. At the time, I was packaging all intermediary milestones, and nobody was consuming them ... | |
| 15:21:45 | zigo | (not even myself) | |
| 15:21:54 | bauzas | anyway, I need to leave for taxi reasons | |
| 15:22:03 | sean-k-mooney | o/ | |
| 15:23:27 | sean-k-mooney | honestly i think distros that want to test early are just better having a conitues build of master somewhere | |
| 15:23:43 | sean-k-mooney | like having a nightly build so they see when we raise a min version or something | |
| 15:23:56 | sean-k-mooney | but not really shiping that outside of an experimtal channel | |
| 15:49:02 | bauzas | sean-k-mooney: yeah, that's the reason why I want more tarballs but the rc1 one | |
| 15:49:10 | bauzas | deployers can start to test them | |
| 15:49:23 | bauzas | even if they're not consumed by any user | |
| 15:50:13 | bauzas | also, say we have a rc1 issue like one we had last week, I'm afraid we could only have one tarball 3 weeks before GA if we don't have another one | |
| 15:50:46 | bauzas | hence why I'd like to have at least a m-3 tarball and maybe one for m-1 depending on what we already merged | |
| 15:57:24 | sean-k-mooney | bauzas: honestly im not sure tars help much but either way its just a commit to the release repo. | |