Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-03-10
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.
16:04:39 bauzas sean-k-mooney: well, maybe but it looks like some operators use a pip version for nova
16:05:07 bauzas so that may also help them to test this pip package version
16:05:18 bauzas anyway, this is simple to do, so let's do it
16:19:59 dansmith my experience is that most deployers want to build from a release tarball
16:29:25 elodilles i know it's mostly end-of-day already (end-of-week, even), but any idea about this weird issue: when bumping oslo.log u-c from 5.0.0 to 5.1.0 cross-nova-py310 seems to be failing: https://review.opendev.org/c/openstack/requirements/+/873390/
16:31:08 elodilles it seems that oslo.log 5.0.1 and 5.0.2 weren't even bumped, but that could be due to different issues. though what I see is there are eventlet related patches in oslo.log ( https://github.com/openstack/oslo.log/compare/5.0.0...5.1.0 ). could that somehow interfere with those 2 failing unit tests?
16:58:07 gibi Uggla: I left some feedback in the Manial series. I planned to do more review on it today and even built a devstack with manila support to try things out. But run out of time before I can dig deep. I see some issues around ShareMapping.detach() and the instance delete with active shares code paths. So I left comments there
16:58:43 Uggla gibi, ok cool, I'll have a look
16:58:47 Uggla gibi, thx !
16:58:54 gibi I have the intention to look more and try this series out, but you can already check these two issues to see if it make sense what I found
16:59:57 Uggla gibi, I'm currently try to setup devstack with ceph.... it is a nighmare...
17:00:17 gibi I only run the default setup with manial so no ceph there
17:02:18 Uggla yep the one with NFS provided on Manila site is ok.
17:04:28 gouthamr Uggla: o/ is something failing with devstack and manila/ceph?
17:05:31 Uggla gouthamr, yep it is not working with jammy, package issue and same with centos stream 9
17:06:32 Uggla gouthamr, example on centos9 : ++functions-common:sudo_with_proxies:2391 sudo http_proxy= https_proxy= no_proxy= dnf install -y ceph nfs-ganesha nfs-ganesha-ceph nfs-ganesha-rados-urls nfs-ganesha-vfs
17:06:32 Uggla Ceph packages for x86_64 68 kB/s | 76 kB 00:01
17:06:32 Uggla Ceph noarch packages 17 kB/s | 15 kB 00:00
17:06:32 Uggla NFS Ganesha packages for x86_64 14 kB/s | 13 kB 00:00
17:06:32 Uggla NFS Ganesha noarch packages 1.1 kB/s | 1.0 kB 00:00
17:06:34 Uggla Error:

Earlier   Later