Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-02-13
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 :)
16:34:09 fwiesel Yeah, either way. I would suggest to leave the discussion on the details of the bug for after the meeting.
16:34:11 dansmith I'll have to look more at the logs after the meeting, there's not really enough meat in the bug to really see I think
16:34:17 bauzas I don't really know the workflow that's implied by this oslo.vmware call
16:35:07 bauzas oh found it
16:35:09 bauzas http://openstack-ci-logs.global.cloud.sap/openstack/nova/35af4b345d997b63f999a090e236d91b78ea4304/n-cpu-1.service.log
16:35:47 bauzas that's when getting the image from glance
16:36:27 sean-k-mooney right so that should be via http via the glance api
16:36:36 sean-k-mooney even if its on NFS as a stoage backend
16:37:06 bauzas I don't actually indeed see why we need to call oslo.vmware
16:37:34 sean-k-mooney well for the volume creation we would just ask cindeer to create the voluem from the image right
16:38:04 fwiesel That happens for the boot from volume case. And that works. But we also have the boot from "local" disk, and then nova needs to pull the image.

Earlier   Later