| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-02-13 | |||
| 16:08:25 | bauzas | #info Caracal-3 (and feature freeze) milestone in 2 weeks | |
| 16:08:29 | bauzas | tick-tock | |
| 16:08:38 | bauzas | 2 weeks and a half, tbh | |
| 16:09:21 | bauzas | for me, given I was working on my own series for testing it, I'll eventually review by tomorrow | |
| 16:09:33 | bauzas | review *other* features, I mean | |
| 16:09:57 | bauzas | I was wanting to do this today, but I had another problem that I fixed | |
| 16:10:15 | bauzas | so, please look at your gerrit emails tomorrow :)= | |
| 16:10:21 | bauzas | #topic Review priorities | |
| 16:10:24 | bauzas | #link https://etherpad.opendev.org/p/nova-caracal-status | |
| 16:10:30 | bauzas | again, everything is there | |
| 16:10:46 | bauzas | nothing to say more about it | |
| 16:10:52 | bauzas | #topic Stable Branches | |
| 16:10:59 | bauzas | elodilles: heya | |
| 16:11:02 | elodilles | o/ | |
| 16:11:09 | elodilles | #info stable/ussuri transitioned to End of Life | |
| 16:11:21 | elodilles | this i forgot to mention last week ^^^ | |
| 16:11:34 | bauzas | \o/ | |
| 16:11:35 | elodilles | #info unmaintained/yoga is open for patches | |
| 16:11:56 | elodilles | though gate might be still problematic, but at least generated patch has merged \o/ | |
| 16:12:12 | elodilles | #info stable gates don't seem blocked, though deleted stable/yoga can cause problems (e.g. on grenade jobs) | |
| 16:12:51 | elodilles | this might be important for 2023.1 (skip level grenade) and zed (grenade) for the coming weeks ^^^ | |
| 16:13:14 | elodilles | so probably the best is to follow things here: | |
| 16:13:18 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:13:32 | elodilles | and maybe one more thing to mention: | |
| 16:13:49 | elodilles | now that we have unmaintained/yoga | |
| 16:14:20 | elodilles | so far only openstack-unmaintained-core have rights for nova's unmaintained/ branch | |
| 16:14:31 | elodilles | there are two option here | |
| 16:14:41 | elodilles | 1) add people to this group | |
| 16:14:55 | elodilles | 2) create a nova-unmaintained-core group | |
| 16:15:09 | dansmith | the goal is that most projects go with #1 | |
| 16:15:11 | elodilles | and populate that one with interested people ^^^ | |
| 16:15:26 | bauzas | I have no opinion | |
| 16:15:34 | elodilles | dansmith: yepp, true, though some project already started to create their own group | |
| 16:15:46 | dansmith | meaning "nova doesn't really maintain the unmaintained stuff, but community members that are interested in old versions do" | |
| 16:16:00 | dansmith | elodilles: right, but see the discussion in -tc right now.. that seems to be a misundersanding | |
| 16:16:02 | elodilles | anyway, this is just a heads up to the team to think about this | |
| 16:16:17 | bauzas | but in general, people wanting to "maintain" a project also wants to maintain cinder and neutron | |
| 16:16:18 | gibi | I don't want to maintain ussuri :) | |
| 16:16:20 | elodilles | dansmith: ACK | |
| 16:16:22 | dansmith | we're hoping/expecting most projects to effectively let those dry up and only get maintained if there are people around to care | |
| 16:16:47 | dansmith | bauzas: right, the idea is someone maintaining ussuri need to care about nova and neutron in that release, so let them | |
| 16:16:56 | elodilles | ACK, then we can keep things as it is then :) | |
| 16:17:01 | bauzas | tbh, after thinking a bit, I wouldn't want to have a specific group told 'nova-' something | |
| 16:17:05 | dansmith | that's certainly my preference | |
| 16:17:21 | elodilles | (note, i am member of openstack-unmaintained-core, so either way, i have rights to mess around there) | |
| 16:17:22 | bauzas | so no about 2) if the name is 'nova-unmaintained-group' | |
| 16:17:29 | dansmith | the idea is that the nova project gets to stop worrying about those old releases | |
| 16:17:42 | dansmith | if we create a nova- group, we kinda have to keep caring about it | |
| 16:17:45 | bauzas | yeah, that's why I don't want that group to be named 'nova' | |
| 16:17:52 | bauzas | dansmith: that's my point | |
| 16:17:56 | dansmith | yup | |
| 16:18:08 | elodilles | ACK | |
| 16:18:28 | elodilles | OK, that's it from my side then about stable :X | |
| 16:18:39 | bauzas | anyway, the unmaintained branch is no longer supported by nova | |
| 16:19:07 | bauzas | so, people can create groups like they want | |
| 16:19:29 | bauzas | but again, I'm fine till they don't name those groups like the projects | |
| 16:20:13 | bauzas | unmaintained-compute-specialized-group meh to it | |
| 16:20:39 | elodilles | no need for a group at all, there is openstack-unmaintained-core group already | |
| 16:20:53 | bauzas | then I'm cool | |
| 16:21:01 | dansmith | and that's the preference :) | |
| 16:21:08 | elodilles | +1 | |
| 16:21:23 | dansmith | the per-project group override is for people who don't want the new plan, basically | |
| 16:21:34 | bauzas | anyway, unmaintained projects are actually now forks | |
| 16:21:35 | dansmith | I think this horse is dead | |
| 16:21:51 | bauzas | unmaintained branches | |
| 16:21:53 | bauzas | * | |
| 16:22:24 | bauzas | people can fork as much as they want provided they don't name those branches "nova-something" | |
| 16:23:03 | bauzas | anyway, I'm done | |
| 16:23:07 | bauzas | moving on ? | |
| 16:23:10 | elodilles | +1 | |
| 16:23:22 | bauzas | #topic vmwareapi 3rd-party CI efforts Highlights | |
| 16:23:28 | fwiesel | #info Fixes to CI for various branches. Missing is still versions prior zed (requiring Ubuntu 20.04) | |
| 16:23:29 | bauzas | fwiesel: heya | |
| 16:23:51 | bauzas | yoga is now unmaintained :D | |
| 16:23:56 | fwiesel | So, I only tested before on master, which didn't translate well to other branches. | |
| 16:24:20 | bauzas | so IMHO you shouldn't really care on maintaining 3rd party jobs for Yoga and older branches | |
| 16:24:42 | fwiesel | Problem is xena. It is also Ubuntu 20.04. | |
| 16:24:58 | fwiesel | Ah, x<z ... | |
| 16:25:15 | fwiesel | Great, that was my implicit question. So we are fine just with zed and later? | |
| 16:25:22 | elodilles | (and Zed will move to Unmaintained in ~3 months) | |
| 16:26:02 | bauzas | fwiesel: that actually depends on what you want to test for yourselves | |
| 16:26:32 | bauzas | but if you don't really want to test Xena for your own sake, fwiw, the nova project is fine with not testing vmwareapi on that branch | |
| 16:26:44 | fwiesel | Well, we want to move away from Xena ourselves. My main reason for testing older versions was trying to bisect the bug I was mentioning. | |
| 16:26:54 | fwiesel | #info Debugging local root disk (Raised bug: https://bugs.launchpad.net/nova/+bug/2053027) | |
| 16:27:21 | fwiesel | That took most of my time. It works for us on our heavily patched xena, I hoped to establish a base-line. | |
| 16:28:01 | fwiesel | At least from what I can gather, it is a rather strange one, and probably is too much for the summary in this meeting. | |
| 16:28:52 | fwiesel | I am almost of a mind to rip out the code for image upload for the one used in cinder (incidentally the one in oslo.vmware). Any strong feelings on this one? | |
| 16:28:53 | bauzas | fwiesel: from your report, it sounds to me this is a glance issue | |
| 16:28:59 | fwiesel | Well, cinder works. | |
| 16:29:09 | fwiesel | With the same glance :) | |
| 16:29:11 | bauzas | so that's a client issue | |
| 16:29:36 | fwiesel | It all runs in the same venv, so the code for all the libraries are the same. | |
| 16:31:24 | fwiesel | The debug output for the request for nova and cinder against glance is almost the same. Cinder also passes on the X-Service-Token to glance, while nova doesn't. | |
| 16:31:38 | dansmith | not sure how it's a glance thing | |
| 16:31:52 | fwiesel | Not that I believe that to be the error, just for completness. | |
| 16:32:11 | bauzas | dansmith: right my bad, it's a client thing | |
| 16:32:20 | bauzas | but the OSError sounds a permission issue | |
| 16:32:23 | fwiesel | Either way, probably not something that can be solved in a couple of minutes in this meeting. I presume | |
| 16:32:54 | fwiesel | You get an "OSError" because the client (i.e. nova) closes the connections, so glance cannot write to the socket anymore. | |
| 16:33:32 | dansmith | fwiesel: not sure that makes sense either :) | |