Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-03-10
14:45:51 sean-k-mooney 63 bits is still better then 31
14:46:05 bauzas well, my weenkend is somehow already ruined, the snow isn't there here and the wind is acting like a hairdryer on the very few left snow
14:47:03 sean-k-mooney if we dont want to rely on https://docs.sqlalchemy.org/en/20/dialects/mysql.html#sqlalchemy.dialects.mysql.BIGINT.params.unsigned then im fine with just the generic bigint
14:47:12 sean-k-mooney this is going to be a ptg topic anyway
14:47:34 sean-k-mooney bauzas: we had snow here last night
14:47:44 sean-k-mooney your welcome to come take it back :P
14:56:04 bauzas sean-k-mooney: that depends, how many tracks do you have here ?
14:56:14 bauzas :p
14:57:08 bauzas https://webcams.lecollet.com/imageSC.jpg when I see this, I cry
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/

Earlier   Later