| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-03-10 | |||
| 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: | |
| 17:06:36 | Uggla | Problem: package ceph-2:16.2.11-0.el8.x86_64 requires ceph-mgr = 2:16.2.11-0.el8, but none of the providers can be installed | |
| 17:06:39 | Uggla | - cannot install the best candidate for the job | |
| 17:06:41 | Uggla | - nothing provides libpython3.6m.so.1.0()(64bit) needed by ceph-mgr-2:16.2.11-0.el8.x86_64 | |
| 17:06:43 | Uggla | (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) | |
| 17:11:53 | gouthamr | ah; ty - that's frustrating - let me look at this, most likely devstack-plugin-ceph needs some updates; we're still testing with focal on the CI because packages for Jammy haven't showed up on download.ceph.com | |
| 17:12:37 | gouthamr | i haven't tried CS9-stream, i will and raise an issue with the ceph community | |
| 17:18:54 | Uggla | gouthamr, it seams i'm progressing pre installing ceph from https://buildlogs.centos.org/centos/9-stream/storage/x86_64/ceph-pacific/ | |