| *** bauzas_ is now known as bauzas | 00:04 | |
| samcat116 | So /server?all_tenants=True vs /servers/detail?all_tenants=True was 1.3s vs 26s | 00:04 |
|---|---|---|
| samcat116 | s/server/servers/, s/all_tenants/all\_tenants/, s/all_tenants/all\_tenants/ | 00:04 |
| sean-k-mooney | we woudl expect there to be a delta but not over an order of magnitde. | 00:18 |
| *** __ministry is now known as Guest3028 | 01:41 | |
| *** ralonsoh_ is now known as ralonsoh | 05:48 | |
| bauzas | because we don't call the cells DB for the first call :) | 07:04 |
| opendevreview | Tobias Urdin proposed openstack/nova master: api-ref: Add new lines not allowed for server description https://review.opendev.org/c/openstack/nova/+/928758 | 07:08 |
| *** bauzas_ is now known as bauzas | 08:03 | |
| bauzas | well, looking at the relnotes, the cycle highlights will be quite simple to write... | 09:06 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [ovo]Add igb value to hw_vif_model image property https://review.opendev.org/c/openstack/nova/+/928456 | 09:26 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [libvirt]Support hw_vif_model = igb https://review.opendev.org/c/openstack/nova/+/928584 | 09:26 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [libvirt]Support hw_vif_model = igb https://review.opendev.org/c/openstack/nova/+/928584 | 09:33 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Refactor obj_make_compatible to reduce complexity https://review.opendev.org/c/openstack/nova/+/928590 | 09:39 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [ovo]Add igb value to hw_vif_model image property https://review.opendev.org/c/openstack/nova/+/928456 | 09:39 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [libvirt]Support hw_vif_model = igb https://review.opendev.org/c/openstack/nova/+/928584 | 09:39 |
| opendevreview | Balazs Gibizer proposed openstack/os-traits master: Add support for hw_vif_model igb image property https://review.opendev.org/c/openstack/os-traits/+/928582 | 09:46 |
| *** bauzas_ is now known as bauzas | 11:08 | |
| *** bauzas_ is now known as bauzas | 11:25 | |
| sean-k-mooney | gibi: for the igb support can you allso add a patch to glance to update https://github.com/openstack/glance/blob/master/etc/metadefs/compute-libvirt-image.json#L112-L127 | 11:59 |
| sean-k-mooney | that used to autogenerate the ui in glance/heat ectra | 11:59 |
| sean-k-mooney | i was going to set that via horizon and rememberd that its defiend as a enum so you cant do that without the metadef update | 12:01 |
| sean-k-mooney | gibi: setting it via the command line works prefectly fine | 12:03 |
| sean-k-mooney | one slight problem is that igb is not included in the cirros image i belive | 12:04 |
| sean-k-mooney | ya ok its not | 12:06 |
| sean-k-mooney | that wont be a problem for us when trying to enable this in ci for the host | 12:07 |
| sean-k-mooney | but we may want ot patch cirros to include the module going forward | 12:07 |
| sean-k-mooney | frickler: ^ that would be nice to have in cirros 7 | 12:07 |
| frickler | sean-k-mooney: what's the advantage of igb? I think I'm lacking some context | 12:14 |
| sean-k-mooney | frickler: it support sriov in the guest i.e. you can create 7 vfs | 12:14 |
| sean-k-mooney | we want to enable it in nova so we can eventually use it for the host vms to do sriov testing in the first party ci | 12:15 |
| sean-k-mooney | qemu virtualises the sriov supprot for igb so there is no hardware dep provided your qemu/libvirt is new enough of course to supprot igb | 12:15 |
| sean-k-mooney | ubuntu 24.04 ships new enough versions fo qemu for this | 12:16 |
| gibi | sean-k-mooney: yeah cirros does not have the igb kernel module available ubuntu has it by default | 12:17 |
| gibi | sean-k-mooney: sure I will look at the glance update | 12:17 |
| sean-k-mooney | its one line so pretty simple. ya im uploading a ubuntu image now | 12:18 |
| sean-k-mooney | lol ok i forgot ther .img images are qcow and it failed the format check | 12:18 |
| frickler | yes, cirros reduces the number of modules available to some useful ones, most you don't need within a vm. including all that ubuntu offers would almost double the cirros image size | 12:18 |
| sean-k-mooney | ya so we have e1000 aviabel just not igb | 12:19 |
| sean-k-mooney | igb is the intel 1g nich that replaced e1000 | 12:19 |
| sean-k-mooney | but its still 10 years old at this point if not more | 12:20 |
| sean-k-mooney | igb was the first generation to support sriov on the intel side | 12:20 |
| gibi | sean-k-mooney: done https://review.opendev.org/c/openstack/glance/+/928788 | 12:23 |
| gibi | frickler: yeah I don't ask to include all the modules, just igb :) | 12:24 |
| gibi | and igbvf | 12:24 |
| sean-k-mooney | oh right the vf driver for using a vf in the guest | 12:25 |
| sean-k-mooney | yep that would be needed too | 12:25 |
| sean-k-mooney | you know its alwasy the little things.. like uploading a keypair before booting a ubuntu vm... | 12:34 |
| sean-k-mooney | i can see its probing proeprly in the guest however form the console logs | 12:36 |
| sean-k-mooney | [ 110.003524] igb 0000:00:03.0 ens3: renamed from eth0 | 12:36 |
| sean-k-mooney | and its set properly in the xml | 12:36 |
| sean-k-mooney | gibi: so at first glance this all looks like tis workign properly | 12:36 |
| sean-k-mooney | gibi: ill review this properly once we have approved the bluepint and do some more testing at that point | 12:37 |
| sean-k-mooney | but it is functional form what i can tell as is. | 12:40 |
| sean-k-mooney | i dont have the patched os-traits in use here so the trait was not set in placement | 12:40 |
| sean-k-mooney | but that at least confirms it works as intended in that regard | 12:41 |
| sean-k-mooney | gibi: i did have one tought however. we may want a compute service bump and gate teh inclution of this in the image metadata pre filter based on a min compute service version check | 12:41 |
| sean-k-mooney | im not entirly sure if that is required but was debating if we needed to do somethign along thos lines for upgrade reasons | 12:42 |
| sean-k-mooney | we proably dont since this will only affect new vms | 12:42 |
| sean-k-mooney | and they can only be schduled to upgraded nodes but im thinking about the placement upgrade interaction | 12:43 |
| sean-k-mooney | we say you should upgrade placement before nova | 12:43 |
| sean-k-mooney | but i dont know if that is always followed | 12:43 |
| fungi | sean-k-mooney: did you see the comment on https://bugs.launchpad.net/nova/+bug/1927677 a couple of hours ago? seems like it's saying python 3.10 stdlib regressed the last fix for ossa-2021-002? | 12:52 |
| sean-k-mooney | no but that already been fix again i belive | 12:52 |
| sean-k-mooney | at least we had to do that downstream if i recall | 12:52 |
| fungi | i wonder if the commenter is on an old version of nova without an additional fix for later python or something | 12:53 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/853379 | 12:53 |
| sean-k-mooney | we have that backported to train upstream | 12:53 |
| sean-k-mooney | and it was merged in master when master was zed | 12:54 |
| sean-k-mooney | so it should not be an issue form train -> master | 12:54 |
| fungi | yeah, so contemporary with when it changed in stdlib | 12:54 |
| sean-k-mooney | yep it was "fixed" in in python 3.10.6 | 12:54 |
| sean-k-mooney | that fix on the redhat side was backported to python 3.9 | 12:55 |
| sean-k-mooney | which broke centos as well but we have the upstream fix so it should be in rdo | 12:55 |
| fungi | thanks, i've linked bug 1986545 in response | 12:55 |
| sean-k-mooney | by the way i think the python fix just broke the unit test i dont htink it regressed the actual security issue | 12:56 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/853379 is a test only change | 12:56 |
| sean-k-mooney | to make the test work with or without the patched python version | 12:56 |
| sean-k-mooney | so its not something the reportor should be worried about | 12:57 |
| sean-k-mooney | i.e. there deployment is still safe | 12:57 |
| sean-k-mooney | well at least form CVE-2021-28861 | 12:57 |
| fungi | makes sense, thanks again | 12:57 |
| gibi | sean-k-mooney: if the metadata prefilter is not enabled then the boot will fail on the compute if the libvirt/qemu does not support the model. If the pre-filter is enabled then that will stop the scheduling if the host is old. If the pre-filter is enabled but the os-traits are not new enough in placement then the pre-filter will not include the trait to the placement query as it checks the traits | 13:00 |
| gibi | validity. | 13:00 |
| sean-k-mooney | gibi: yep that all checks out | 13:01 |
| gibi | so I don't feel the need for a service version check in the pre-filter | 13:01 |
| sean-k-mooney | no your right it shold not be required | 13:01 |
| gibi | anyhow thanks for the quick look, I will put this on the meeting agenda for approval after RC1 is out. | 13:03 |
| bauzas | gibi: I created an etherpad for RC tracking et al., I'll tell about it today on our nova meeting | 13:09 |
| bauzas | gibi: so you could add your patch in there | 13:09 |
| gibi | bauzas: this is for epoxy so not for the RC etherpad :) | 13:10 |
| bauzas | gibi: there is a post-RC section :) | 13:11 |
| bauzas | but there is also another epoxy etherpad that I created :) | 13:11 |
| bauzas | again, I'll tell about it today :) | 13:11 |
| bauzas | https://etherpad.opendev.org/p/nova-2025.1-status in case | 13:12 |
| gibi | ohh OK I can add to that :) | 13:16 |
| * sean-k-mooney forgot how slow nested virt is without nested kvm... | 13:17 | |
| gibi | bauzas: ahh bummer I cannot add to it as it is a bp that needs approval :) | 13:18 |
| bauzas | gibi: add then the launchpad blueprint somewhere in the etherpad by adding a new section which will be "needs approval" | 13:18 |
| bauzas | I'm trying to make the easiest path for people wanting to contribute on nova and that etherpad seems to be a starting point | 13:19 |
| gibi | ok | 13:19 |
| gibi | done | 13:21 |
| bauzas | saw it | 13:22 |
| bauzas | cool | 13:22 |
| bauzas | I'll request for a round of reviews about many RC1 patches | 13:22 |
| bauzas | I need cores | 13:22 |
| gibi | bauzas: sure feel free to point me to patches | 13:22 |
| bauzas | enjoy : https://etherpad.opendev.org/p/nova-dalmatian-rc-potential#L12 | 13:23 |
| bauzas | those are the usual bureaucratic patches we deliver before RC1 | 13:23 |
| bauzas | but they are useful for pinning versions and like, ensuring upgrades work :) | 13:23 |
| gibi | bauzas: so for the openapi blueprint we closed the current one for Dalmatian and there will be a different bp for Epoxy to finish the remaining work? | 13:38 |
| gibi | I just noticed it as the openapi spec is about to be moved to implemented. | 13:39 |
| bauzas | you're correct, I asked stephen last week | 13:39 |
| bauzas | we agreed on creating a part-2 given we already merged some meat | 13:39 |
| gibi | do we have a note in the spec stating what was done in D and what remains for E? | 13:39 |
| bauzas | fwiw, physical meetups are way simplier for finding a consensus | 13:39 |
| bauzas | gibi: no, but you make a good point, let's ask stephenfin | 13:40 |
| stephenfin | gibi: Yeah, there was probably too much there to be done in one cycle. However, we are at a clear boundary in so far as we have everything else *except* the response body schemas in place now | 13:41 |
| stephenfin | How do we approach that normally, where we have something tangible done in one cycle but more to be done the next cycle? | 13:41 |
| bauzas | and I hope to do reviews of part-2 myself :) | 13:42 |
| gibi | stephenfin: I think having a part-2 bp is OK | 13:42 |
| bauzas | stephenfin: exactly like what we agreed : provide a part-2 and explain what's missing | 13:42 |
| gibi | but I would like to see a note in the D spec stating what was done in D from the original scope | 13:42 |
| bauzas | sounds fine to me | 13:42 |
| gibi | I would like to end up with a history in the specs like this https://specs.openstack.org/openstack/nova-specs/specs/2023.1/implemented/pci-device-tracking-in-placement.html#history | 13:44 |
| gibi | also an example note from the zed spec https://specs.openstack.org/openstack/nova-specs/specs/zed/approved/pci-device-tracking-in-placement.html#scheduling | 13:44 |
| opendevreview | Merged openstack/nova-specs master: Create specs directory for 2025.1 Epoxy https://review.opendev.org/c/openstack/nova-specs/+/924227 | 13:45 |
| stephenfin | gibi: So I note the zed spec is still in approved rather than implemented? I assume we'll do that same for my spec in dalmation? | 13:54 |
| bauzas | stephenfin: I said it was implemented | 13:55 |
| bauzas | you'll just recreate a part-2 blueprint | 13:55 |
| stephenfin | ack | 13:55 |
| bauzas | and another spec file | 13:56 |
| bauzas | stephenfin: tbh, our numbers aren't good, I'm quite on the side to basically see the half-full glass now than half-empty :) | 13:56 |
| bauzas | https://blueprints.launchpad.net/nova/2024.2 is terrible to see | 13:57 |
| sean-k-mooney | thats hardly surprising if your paying attention to how thing were progressing | 14:01 |
| sean-k-mooney | 3 of the 6 that were implemented would not have been if i didnt explictly go looking for reveiews on behalf of the contibutor | 14:03 |
| zigo | sean-k-mooney: What's the status of the virtio driver for Manila, do you know? Is it done in Dalmatian?!? | 14:04 |
| opendevreview | Stephen Finucane proposed openstack/nova-specs master: Re-propose OpenAPI spec for Epoxy https://review.opendev.org/c/openstack/nova-specs/+/928800 | 14:04 |
| stephenfin | gibi: bauzas: ^ | 14:04 |
| sean-k-mooney | zigo: no, unfortuetly, we think all of the blocker are now resloved for it to be in 2025.1 | 14:04 |
| zigo | Ok, thanks. | 14:05 |
| sean-k-mooney | but there were some issues with the sdk and how we were doing auth | 14:05 |
| sean-k-mooney | and with locking on the manila side | 14:05 |
| zigo | So, wont be in Debian Trixie ... :/ | 14:05 |
| sean-k-mooney | those were found late and combined with PTO season we didnt have bandwith to adress them in time | 14:05 |
| sean-k-mooney | zigo: not until epoxy at any rate assumign that will eventually get packaged there | 14:06 |
| zigo | I will package Epoxy, of course, but Dalmatian will be in official Debian 13, not Epoxy. | 14:06 |
| bauzas | that series is one of the largest to review, and that's why it takes a matter of patience | 14:09 |
| bauzas | that said, I agree, the PTO season didn't help too | 14:09 |
| bauzas | I'm more sad on *other* series that got not merged | 14:09 |
| bauzas | anyway, if people care about our project, they can also understand things don't merge magically | 14:10 |
| bauzas | we need hands on, but we struggle finding new contributors | 14:11 |
| opendevreview | zhou zhong proposed openstack/nova master: nova-manage: modify image properties in request_spec https://review.opendev.org/c/openstack/nova/+/924319 | 14:11 |
| bauzas | if that virtiofs series is a matter of interest for any company, I'd surely appreciate if they could dedicate some time to help with reviewing that series (or testing it at least) | 14:11 |
| sean-k-mooney | zigo: ok the issue with that is dalmatian is obviously not a slurp release | 14:12 |
| sean-k-mooney | so it will support upgrade form caracal but not bobcat | 14:13 |
| sean-k-mooney | althogh they should be able to go from caracal to epoxy when that is released | 14:13 |
| opendevreview | Takashi Kajinami proposed openstack/nova-specs master: Re-propose "libvirt: AMD SEV-ES support" for 2025.1 https://review.opendev.org/c/openstack/nova-specs/+/928817 | 14:16 |
| gibi | stephenfin: thanks! | 14:37 |
| zigo | sean-k-mooney: From the Debian perspective, the SLURP releases aren't alligned ... :/ | 14:48 |
| sean-k-mooney | they are for ubuntu and rhel is tbd to be honest but 18 is based on antelope at least | 14:51 |
| opendevreview | Merged openstack/python-novaclient stable/2024.2: Update .gitreview for stable/2024.2 https://review.opendev.org/c/openstack/python-novaclient/+/928363 | 15:45 |
| opendevreview | Merged openstack/python-novaclient stable/2024.2: Update TOX_CONSTRAINTS_FILE for stable/2024.2 https://review.opendev.org/c/openstack/python-novaclient/+/928364 | 15:54 |
| opendevreview | Merged openstack/nova-specs master: Re-propose OpenAPI spec for Epoxy https://review.opendev.org/c/openstack/nova-specs/+/928800 | 15:55 |
| opendevreview | Merged openstack/nova-specs master: Move Dalmatian implemented specs https://review.opendev.org/c/openstack/nova-specs/+/928666 | 15:55 |
| opendevreview | Merged openstack/nova master: doc: mark the maximum microversion for 2024.2 Dalmatian https://review.opendev.org/c/openstack/nova/+/928660 | 15:55 |
| bauzas | reminder: nova meeting in 2 mins here | 15:58 |
| bauzas | and gosh, I need to update the agenda | 15:58 |
| sean-k-mooney | dont just empty it | 15:58 |
| sean-k-mooney | some of the items have been prefiled form last week for opendiscusion i think | 15:58 |
| sean-k-mooney | the one i was thinking of has not been added | 15:59 |
| sean-k-mooney | https://blueprints.launchpad.net/nova/+spec/shared-security-groups | 15:59 |
| sean-k-mooney | the people working on that would like to have it reappvoed for epoxy | 16:00 |
| sean-k-mooney | so lets add that to open discuss | 16:00 |
| bauzas | sean-k-mooney: sure | 16:01 |
| bauzas | #startmeeting nova | 16:01 |
| opendevmeet | Meeting started Tue Sep 10 16:01:40 2024 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:01 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:01 |
| opendevmeet | The meeting name has been set to 'nova' | 16:01 |
| fwiesel | o/ | 16:01 |
| elodilles | o/ | 16:02 |
| dansmith | o/ | 16:02 |
| sean-k-mooney | o/ | 16:02 |
| gmann | o/ | 16:02 |
| bauzas | hey everyone | 16:02 |
| bauzas | nice to see you | 16:02 |
| sean-k-mooney | welcome back | 16:02 |
| bauzas | sorry, was away last week for the OIF Summit Asia | 16:02 |
| tkajinam | o/ | 16:02 |
| auniyal | o/ | 16:03 |
| bauzas | #topic Bugs (stuck/critical) | 16:03 |
| bauzas | #info No Critical bug | 16:03 |
| bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:03 |
| bauzas | any bug report people would want to discuss ? | 16:04 |
| dansmith | maybe one | 16:04 |
| dansmith | I filed the bug against oslo and nova, | 16:04 |
| bauzas | shoot | 16:05 |
| dansmith | but sean-k-mooney, are you still working on excluding the safety check for the ephemeral disks? | 16:05 |
| sean-k-mooney | https://bugs.launchpad.net/nova/+bug/2079850 | 16:05 |
| sean-k-mooney | i have a draft of that locally the unit test are failing so im tryign to fix that | 16:05 |
| dansmith | the oslo fix is +2 but it'll take a release and u-c bump before we get it | 16:05 |
| dansmith | sean-k-mooney: okay cool | 16:05 |
| bauzas | ergh | 16:06 |
| bauzas | yet another reason to work on the image backend refactoring if you want MHO | 16:06 |
| dansmith | bauzas: basically, if you have nova format your ephemerals as vfat for you, you'll hit this fail | 16:06 |
| dansmith | yes, it's really stupid that we're even doing this, and it's at least partially because of the design of the imagebackend | 16:07 |
| opendevreview | sean mooney proposed openstack/nova master: [WIP] Add functional repoducer for ephemeral disks https://review.opendev.org/c/openstack/nova/+/928310 | 16:07 |
| opendevreview | sean mooney proposed openstack/nova master: [WIP] adapt to vfat support in oslo.utils https://review.opendev.org/c/openstack/nova/+/928462 | 16:07 |
| opendevreview | sean mooney proposed openstack/nova master: only saftey check bootable files created form glance https://review.opendev.org/c/openstack/nova/+/928829 | 16:07 |
| sean-k-mooney | thats what im working on ^ | 16:07 |
| dansmith | sean-k-mooney: cool thanks | 16:07 |
| bauzas | formatting ephemerals to vfat is like "I don't care about my fs, dude" | 16:07 |
| sean-k-mooney | still failing unit test but i should get those passing today | 16:07 |
| dansmith | bauzas: right, it's pointless for us to even do that anyway, because nobody would actually use them as fat anyway | 16:07 |
| dansmith | bauzas: double pointless behavior :) | 16:08 |
| bauzas | I assume this would be for additional disks ? | 16:08 |
| dansmith | ephemerals | 16:08 |
| sean-k-mooney | i propoaded not formatign ephemeral disk by default before | 16:08 |
| sean-k-mooney | we have a blueprint for that that i think we shoudl do in epoxy | 16:08 |
| dansmith | yeah, sean-k-mooney I'm on board with that too | 16:08 |
| bauzas | ring me a bell, I know what ephemeral disks are in nova, but I wonder *why* people would want vfat | 16:09 |
| sean-k-mooney | but for right now just skipign the safty check if the disk is not bootable and thats only set when we chreat ephermal/swap disks in my patch above | 16:09 |
| sean-k-mooney | bauzas: its our default when you dont set a config option or image property | 16:09 |
| bauzas | probably because they think "ephemeral" means the disks are not persisted (which is not the case) | 16:09 |
| sean-k-mooney | we choose it as the only format that would work for every os | 16:09 |
| sean-k-mooney | not it was just because we needed something that works on linux and windows | 16:10 |
| dansmith | vfat would only be for windows guests so they see something on the disk instead of blank | 16:10 |
| sean-k-mooney | if you set os_type in teh image we use ntfs or ext4 | 16:10 |
| dansmith | but makes no actual sense | 16:10 |
| dansmith | sean-k-mooney: we actually support ntfs? | 16:10 |
| sean-k-mooney | or if you set the config option we use what you set as the fallback | 16:10 |
| sean-k-mooney | yep | 16:11 |
| dansmith | either way, we're not partitioning the disk properly anyway.. I guess I'm surprised windows is happy with a whole-disk ntfs | 16:11 |
| sean-k-mooney | im not saying you should use it | 16:11 |
| sean-k-mooney | but the code is there | 16:11 |
| sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.default_ephemeral_format | 16:11 |
| dansmith | yeah, I would never use linux-created ntfs for production if I was a windows user | 16:11 |
| sean-k-mooney | well cloud model. as a end user you should not know if its hyperv or libvirt/qemu | 16:12 |
| bauzas | but you know the image you use | 16:12 |
| sean-k-mooney | its in the default section because this applies to other drivers | 16:12 |
| dansmith | I mean as the operator I would never configure that, | 16:12 |
| dansmith | but you're right, users may not realize they are getting ntfs created by linux that they shouldn't trust :) | 16:13 |
| bauzas | agreed on not configure it if I was admin, I'd just assume nova would create me ephemerals that my instance can read | 16:13 |
| sean-k-mooney | anyway we can carry this discussion forward to the reveiws | 16:13 |
| dansmith | yeah | 16:13 |
| sean-k-mooney | but next cycle we can add unformated and set that as the default | 16:13 |
| sean-k-mooney | https://blueprints.launchpad.net/nova/+spec/default-ephemeral-format-unformated | 16:13 |
| dansmith | with docs and renos suggesting to leave it that way | 16:14 |
| sean-k-mooney | we can flag the option with advnaced if we like | 16:14 |
| sean-k-mooney | https://docs.openstack.org/oslo.config/latest/reference/defining.html#advanced-option | 16:14 |
| sean-k-mooney | anyway we can likely move on | 16:15 |
| dansmith | yup | 16:15 |
| bauzas | okay | 16:15 |
| bauzas | action items are on reviewing the oslo.utils patch, right? | 16:15 |
| dansmith | no, | 16:16 |
| dansmith | that's on the oslo people and tkajinam has already +2d and asked the other cores to hit it | 16:16 |
| dansmith | but again, it won't solve our problem until release/bump | 16:16 |
| dansmith | the action item on us should be getting sean's actual fix working,reviewed,merged | 16:16 |
| dansmith | (IMHO) | 16:16 |
| sean-k-mooney | i have a patch at the end for compatiblity with the oslo change too | 16:17 |
| bauzas | are we talking of https://review.opendev.org/q/topic:%22ephmeral-and-swap-backing-files%22 ? | 16:17 |
| sean-k-mooney | the first 2 patches yes but ill change the topic of that to the bug topic later | 16:17 |
| bauzas | cool | 16:17 |
| bauzas | I guess then we can move on | 16:18 |
| tkajinam | I can push the oslo.utils to gate if it doesn't get attention from the other cores and hard blocks nova release but note that we may need a few more steps (backport to 2024.1, new release in 2024.1 and req bump) | 16:18 |
| bauzas | but do we feel this as a regression bug ? | 16:18 |
| tkajinam | which might mean that RC1 release of nova might be delayed because of it | 16:18 |
| bauzas | heh, jinxed by tkajinam | 16:18 |
| tkajinam | s/2024.1/2024.2/g | 16:18 |
| tkajinam | :-) | 16:19 |
| sean-k-mooney | tkajinam: its not a hard block really but it is a regression that might require an rc2 | 16:19 |
| tkajinam | ok | 16:19 |
| dansmith | it's not an oslo regression | 16:19 |
| bauzas | it's a nova regression | 16:19 |
| sean-k-mooney | yep | 16:19 |
| dansmith | it is a nova one, but again, it feels like we need to fix our own code anyway | 16:19 |
| bauzas | so we need to merge sean's patches before RC1 | 16:19 |
| sean-k-mooney | ideally but i need to get it passing first | 16:19 |
| tkajinam | ok | 16:19 |
| bauzas | or deliver RC1 and adress them in RC2 | 16:19 |
| dansmith | so we could aim to get sean's stuff in to fix, | 16:20 |
| bauzas | sean-k-mooney: fwiw, I'm just adding to that bug report the dalmatian-rc-potential taag | 16:20 |
| dansmith | but if we can't for some reason, just getting nova to use the updated oslo will paper over the problem | 16:20 |
| tkajinam | makes sense | 16:20 |
| bauzas | and I'm flagging that bug in the rc etherpad I'm just gonna speak about in a few | 16:20 |
| sean-k-mooney | cool. im going to monitor the meetign but im goign to go back to working on this in parallel | 16:20 |
| bauzas | sean-k-mooney: don't freak out, we didn't had RC2s for a while, but I feel brave enough to ship one this time :) | 16:21 |
| dansmith | let's move on for real now | 16:22 |
| bauzas | okay, did the paperwork | 16:23 |
| bauzas | (sorry, took more time than estimate) | 16:23 |
| bauzas | #topic Gate status | 16:24 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:24 |
| bauzas | #link https://etherpad.opendev.org/p/nova-ci-failures-minimal | 16:24 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status | 16:24 |
| bauzas | nothing to relate except nova-emulation zed again | 16:24 |
| bauzas | my bad, nova-emulation on antelope | 16:24 |
| bauzas | but since master job run worked like a charm, let's not look at it | 16:25 |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:25 |
| bauzas | #info Please try to provide meaningful comment when you recheck | 16:25 |
| bauzas | anything else about gate stability ? | 16:25 |
| bauzas | looks not | 16:26 |
| bauzas | #topic Release Planning | 16:26 |
| bauzas | #link https://releases.openstack.org/dalmatian/schedule.html | 16:26 |
| opendevreview | Merged openstack/os-vif stable/2024.2: Update .gitreview for stable/2024.2 https://review.opendev.org/c/openstack/os-vif/+/928353 | 16:26 |
| bauzas | #info Dalmatian RC1 planned this week | 16:26 |
| bauzas | so, again, I'd appreciate if people chime in if they find regressions | 16:27 |
| elodilles | ( there is the generated patch: https://review.opendev.org/c/openstack/releases/+/928551 ) | 16:27 |
| elodilles | ( rc1 patch for nova) | 16:27 |
| bauzas | we now have an etherpad for RC tracking | 16:27 |
| bauzas | #link https://etherpad.opendev.org/p/nova-dalmatian-rc-potential | 16:27 |
| bauzas | elodilles: thanks, just adding your nova rc1 patch to the etherpad :) | 16:28 |
| elodilles | ++ | 16:28 |
| bauzas | also, | 16:29 |
| bauzas | maybe people forgot here that as soon as we branch master with RC1, then master becomes Epoxy :) | 16:29 |
| bauzas | accordingly | 16:29 |
| bauzas | #info Epoxy development phase will start as soon as we branch RC1 | 16:30 |
| bauzas | #link https://releases.openstack.org/epoxy/schedule.html | 16:30 |
| bauzas | and accordingly, we'll use another etherpad for tracking all the work we'll be doing for Epoxy : | 16:30 |
| bauzas | #link https://etherpad.opendev.org/p/nova-2025.1-status | 16:30 |
| bauzas | feel free to add any blueprints you would want us to look at or any bug report you'd want to fix by Epoxy timeframe | 16:31 |
| bauzas | based on my discussions at the OIF Summit Asia, I was also convinced to update our docs to mention our tracking system | 16:32 |
| bauzas | #action bauzas to update the contributor docs to mention the etherpad and how to reach the nova community | 16:32 |
| bauzas | that's it for me for release planning | 16:33 |
| bauzas | anything else to add ? | 16:33 |
| bauzas | oh | 16:33 |
| bauzas | I forgot | 16:33 |
| bauzas | in the rc tracking etherpad, I have a couple of patches I'd beg cores to review | 16:33 |
| gibi | I went through that list so we need one more cores | 16:34 |
| bauzas | particularly the highlights | 16:34 |
| gibi | s/cores/core/ | 16:34 |
| bauzas | gibi: thanks ! | 16:34 |
| gmann | I +w few of them | 16:34 |
| bauzas | gmann: thanks too | 16:35 |
| bauzas | okay, I'll chase the patches and bug people eventually | 16:35 |
| bauzas | moving on then | 16:35 |
| bauzas | #topic Review priorities | 16:35 |
| bauzas | this is currently punted to once we branch RC1 | 16:35 |
| bauzas | the current priorities are now clearly bugfixes, particularly if they are regression ones :) | 16:36 |
| bauzas | #topic Stable Branches | 16:36 |
| bauzas | elodilles: take the baton | 16:36 |
| elodilles | o7 | 16:36 |
| elodilles | #info stable/202*.* gates seem to be OK | 16:37 |
| elodilles | #info stable/2024.2 branch were cut for libraries | 16:37 |
| elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | 16:37 |
| elodilles | please add gate errors in the pad if anyone finds one ^^^ | 16:38 |
| elodilles | and that's all about stable branches from me | 16:38 |
| bauzas | all good | 16:39 |
| bauzas | #topic vmwareapi 3rd-party CI efforts Highlights | 16:39 |
| fwiesel | #info No updates. | 16:39 |
| bauzas | fwiesel: your time | 16:39 |
| bauzas | cool with me | 16:39 |
| bauzas | #topic Open discussion | 16:39 |
| bauzas | we have one time that was carried over from last week, I'd say | 16:40 |
| bauzas | (whoami-rajat) Add multipath_id to the BDM in case of iSCSI | 16:40 |
| bauzas | whoami-rajat: are you available now ? | 16:40 |
| sean-k-mooney | gibi and i have looked at the patch | 16:41 |
| sean-k-mooney | effectivly they want to do this to make debuging with db dubps simplere | 16:41 |
| sean-k-mooney | apprently only nova and the network backend has the multipath_id | 16:41 |
| bauzas | orly? | 16:42 |
| sean-k-mooney | and this is useful for them to be able to corralate the instance and the volume on the storage backend | 16:42 |
| sean-k-mooney | im a little reluctant to add the multipath id just for debuging but not 100% agisnt it | 16:42 |
| sean-k-mooney | i left a comment to that effect on the patch | 16:43 |
| bauzas | and I guess the BDM is a blob ? | 16:43 |
| bauzas | no database update needs ? | 16:43 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/889257 | 16:44 |
| sean-k-mooney | its a json blob i belive yes | 16:44 |
| bauzas | I don't get why we need to persist it | 16:44 |
| bauzas | couldn't we show it in the logs ? | 16:44 |
| gibi | It feels wrong that nova perists a data that nova never uses and never passes along | 16:45 |
| sean-k-mooney | hum https://github.com/openstack/nova/blob/master/nova/db/main/models.py#L684-L754 | 16:45 |
| bauzas | agreed with gibi | 16:45 |
| sean-k-mooney | i guess this would be in connection_info | 16:45 |
| bauzas | yeah | 16:45 |
| bauzas | that's where they're stuffing it into | 16:46 |
| bauzas | and that's a text filed | 16:46 |
| bauzas | field | 16:46 |
| sean-k-mooney | ya so im not a fan of that either | 16:46 |
| bauzas | but I don't like persisting it | 16:46 |
| sean-k-mooney | this is also in teh vm xml | 16:46 |
| bauzas | for multiple reasons, the first one being that this info couldn't be reliable | 16:46 |
| sean-k-mooney | the storage folk apparently use db dumps for debugging more then we do | 16:46 |
| sean-k-mooney | i value having it in the logs and xml more | 16:46 |
| gibi | hm, if this is in the xml then a proper sos report has enough info to correlate multipath_id with volume and instance | 16:47 |
| sean-k-mooney | becuase we normally dont have db dumps | 16:47 |
| bauzas | even with all we know about orphaned BDMs ? | 16:47 |
| gibi | or they need historical data about delete VMs? | 16:47 |
| bauzas | logs will tell you tho | 16:47 |
| gibi | yeah we dump the xml to debug | 16:47 |
| sean-k-mooney | bauzas: to move this forward can i suggest reaching out to rajat | 16:48 |
| gibi | yeah we need rajat for this | 16:48 |
| bauzas | also | 16:48 |
| sean-k-mooney | or putting it on the ptg topic list | 16:48 |
| bauzas | this would require a blueprint at least, maybe a spec if we consider the DB change | 16:48 |
| bauzas | the fact that nothing in nova reads that value makes me very reluctant at least | 16:48 |
| sean-k-mooney | ya i was -1 on thi initally when i spoke to them on slack and asked them ot bring it upstream | 16:49 |
| bauzas | I don't want us to create a precedent with any text field just being a brown bag for DB bumps | 16:49 |
| bauzas | dumps* | 16:49 |
| sean-k-mooney | i agree this is not a bug but a minor feature | 16:49 |
| sean-k-mooney | to me this is out os scope but i think we should let them present there case | 16:49 |
| bauzas | then we can write an AI | 16:50 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [doc]Developer doc about PCI and SRIOV testing https://review.opendev.org/c/openstack/nova/+/928834 | 16:50 |
| bauzas | #agreed this case sounds a feature request and requires a blueprint, which would describe the reason for that change and the solution | 16:51 |
| dansmith | a db change for a thing we don't actually need would require a lot of justification for me to get behind :) | 16:51 |
| bauzas | #agreed this blueprint would have to be discussed in a later nova meeting to see whether it would be specless or requiring a spec | 16:51 |
| bauzas | dansmith: I think the meeting logs are clear :) | 16:51 |
| bauzas | tbc, if nothing reads that BDM value, this is tech debt | 16:52 |
| dansmith | yep, just chiming in | 16:52 |
| bauzas | cool | 16:52 |
| bauzas | I hope whoami-rajat will read the logs | 16:52 |
| bauzas | and again, I'm open to chat | 16:52 |
| bauzas | I think we're settled | 16:53 |
| bauzas | any carried over item from last week or any new meat to digest ? | 16:53 |
| bauzas | or can I call it a wrap and take a beer ? | 16:53 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: [doc]Developer doc about PCI and SRIOV testing https://review.opendev.org/c/openstack/nova/+/928834 | 16:54 |
| sean-k-mooney | we had one other item | 16:54 |
| sean-k-mooney | can we reappove the shared security group specless blueprint | 16:54 |
| sean-k-mooney | for expoy | 16:54 |
| sean-k-mooney | https://blueprints.launchpad.net/nova/+spec/shared-security-groups | 16:54 |
| bauzas | thanks | 16:55 |
| bauzas | I haven't seen it in the agenda | 16:55 |
| bauzas | I have no objection for the reapproval | 16:55 |
| sean-k-mooney | i think the current state of the patch is mergable, this is the one i pinged about at the start of the meeting | 16:55 |
| sean-k-mooney | so it would be a easy win after rc1 | 16:55 |
| bauzas | sounds a quickwin as soon as RC1 branches | 16:55 |
| bauzas | yeah | 16:56 |
| bauzas | okay, don't hear any disagreement, so... | 16:56 |
| bauzas | #agreed https://blueprints.launchpad.net/nova/+spec/shared-security-groups is accepted again as specless bp for Epoxy | 16:57 |
| bauzas | that's it for me | 16:57 |
| bauzas | and we're at time | 16:57 |
| bauzas | thanks all | 16:57 |
| bauzas | #endmeeting | 16:57 |
| opendevmeet | Meeting ended Tue Sep 10 16:57:27 2024 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:57 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2024/nova.2024-09-10-16.01.html | 16:57 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2024/nova.2024-09-10-16.01.txt | 16:57 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2024/nova.2024-09-10-16.01.log.html | 16:57 |
| sean-k-mooney | o/ ok ill brb | 16:57 |
| gibi | bauzas: thanks | 16:57 |
| elodilles | thanks o/ | 16:58 |
| * bauzas needs to do the launchpad laundry for creating 2025.1 release | 16:58 | |
| opendevreview | Merged openstack/os-vif stable/2024.2: Update TOX_CONSTRAINTS_FILE for stable/2024.2 https://review.opendev.org/c/openstack/os-vif/+/928355 | 17:05 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/nova master: Respect supplied arguments in novncproxy_base_url https://review.opendev.org/c/openstack/nova/+/928839 | 17:08 |
| noonedeadpunk | sean-k-mooney: this is what we were discussing yesterday ^ | 17:08 |
| sean-k-mooney | ya so either parsing it like that or a sperate config option just for the extra query args | 17:10 |
| sean-k-mooney | that does not look unreasonabel to me at a glance | 17:10 |
| sean-k-mooney | although im not a fan of puting each arg on its own line like this https://review.opendev.org/c/openstack/nova/+/928839/1/nova/tests/unit/objects/test_console_auth_token.py#103 | 17:11 |
| sean-k-mooney | that proably a trivial specless bluepirnt | 17:11 |
| sean-k-mooney | so we will need to put it on the adgenda for next week | 17:11 |
| sean-k-mooney | bauzas: ^ | 17:11 |
| sean-k-mooney | anyway for a 30 second review i think its ok over all but ill need to loop back to that properly later | 17:12 |
| sean-k-mooney | noonedeadpunk: would you mind filing a specless bluepint and updating the commit message with implements: blueprint <name> | 17:14 |
| sean-k-mooney | and queing that up for next week adjenda | 17:15 |
| noonedeadpunk | regarding tests - I was pretty much following the pattern from `_test_authorize` | 17:19 |
| sean-k-mooney | ya we are kind of inconsitentent | 17:19 |
| noonedeadpunk | ah, sorry | 17:19 |
| noonedeadpunk | I thought about different line | 17:20 |
| noonedeadpunk | all args in one line were exceeding the 80l | 17:20 |
| sean-k-mooney | yep so we normally put them all on the next line | 17:20 |
| sean-k-mooney | that allow you to reclaim all the indent space | 17:20 |
| noonedeadpunk | ++ | 17:21 |
| sean-k-mooney | so like this https://peps.python.org/pep-0008/#indentation | 17:21 |
| sean-k-mooney | so "Add 4 spaces (an extra level of indentation) to distinguish arguments from the rest." | 17:22 |
| noonedeadpunk | yeah, I got it :) | 17:23 |
| sean-k-mooney | to be fair i want to just automate this | 17:23 |
| sean-k-mooney | but we have never got agreement on how | 17:23 |
| sean-k-mooney | but im very tempeted to review my black serise with line lenght 79 | 17:23 |
| sean-k-mooney | i dont like black but i disliek discussion formatign with humans more :) | 17:24 |
| sean-k-mooney | let the bots/tools fight that out instead | 17:24 |
| whoami-rajat | sorry everyone, i wasn't around for the meeting, but would like to address a few of the concerns | 17:25 |
| whoami-rajat | bauzas, it's a challenge to figure out where we want to log it, customer deployments don't enable DEBUG by default and there are multiple failure scenarios where we would need to log this in case of an exception | 17:25 |
| whoami-rajat | bauzas, also I'm not sure why it is not reliable? the multipath_id or WWID is the ID assigned to the volume (LUN) so it is persistent throughout the life of the volume across multiple attach/detach cycles | 17:25 |
| whoami-rajat | dansmith, So for fibre channel connections, we already store the multipath_id in the connection_info field, my patch is just adding it for iSCSI connections, not sure if it still counts as a DB change, more of filling a missing value for one type of attachments (iSCSI) | 17:25 |
| whoami-rajat | Also I've found this value being used in the LUKS encryptor, https://github.com/openstack/os-brick/blob/master/os_brick/encryptors/luks.py#L89-L98 | 17:25 |
| sean-k-mooney | whoami-rajat: they do not for 18 but historically yoru correct | 17:25 |
| sean-k-mooney | *the do now | 17:25 |
| noonedeadpunk | sean-k-mooney: about specless blueprint - so it's just a record on launchpad with description? | 17:26 |
| sean-k-mooney | noonedeadpunk: yep exactly | 17:26 |
| dansmith | whoami-rajat: another field in a json blob is not what I mean by "a db change" | 17:26 |
| * noonedeadpunk was reading https://docs.openstack.org/nova/latest/contributor/blueprints.html but decided to double check | 17:26 | |
| sean-k-mooney | noonedeadpunk: like this https://blueprints.launchpad.net/nova/+spec/default-ephemeral-format-unformated | 17:26 |
| whoami-rajat | sean-k-mooney, yep, but you know how long it will take for all the customers to move from 16.2 and 17.1 to 18 when there are customers still using 13 :D | 17:26 |
| noonedeadpunk | ++ | 17:26 |
| sean-k-mooney | whoami-rajat: right but we are not going to backport this so is that relevent :) | 17:27 |
| sean-k-mooney | whoami-rajat: i was not aware this was already there for fiber channel | 17:28 |
| sean-k-mooney | but there its presumable also used for nova in the xml generation or similar | 17:28 |
| dansmith | also discussion of any default configurations of OSP versions has no bearing on what we're going to do upstream :) | 17:28 |
| whoami-rajat | +1, that's why i found it's usage in the os-brick encryptors where the field is relevant irrespective of the debugging use case | 17:29 |
| whoami-rajat | sean-k-mooney, if it's not supposed to be backported then i am less motivated to pursue this | 17:30 |
| sean-k-mooney | upstream it would not qualify i dont think and im not sure it woudl dowstream but for diffent reasons | 17:31 |
| sean-k-mooney | its not addressing a bug so unless this is an operator painpoint today it would be out of scope fo stable backports | 17:31 |
| sean-k-mooney | whoami-rajat: i dont think anyone really object ot adding a debug or maybe even info level log for this | 17:33 |
| sean-k-mooney | woudl that be useful for you | 17:34 |
| sean-k-mooney | there is nothign actionalable here so warning and error woudl not be approate but info woudl likely be ok | 17:34 |
| whoami-rajat | sean-k-mooney, yeah, given the current discussion, i feel that would be a better path to pursue, thanks | 17:36 |
| whoami-rajat | honestly i thought it would be a trivial change to get in and backported since currently the BDMs for FC and iSCSI are just inconsistent | 17:36 |
| whoami-rajat | but looks like the efforts will outweigh the usefulness of the change | 17:36 |
| whoami-rajat | so I'm good with a DEBUG or INFO level logging message | 17:37 |
| sean-k-mooney | the normalisation level argument can be made, im just not sure if that is commpeling enough but its worth considering at least | 17:37 |
| sean-k-mooney | s/level// | 17:38 |
| sean-k-mooney | dansmith: gibi ^ is that more appealign to ye? just a new info level log? | 17:39 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/nova master: Respect supplied arguments in novncproxy_base_url https://review.opendev.org/c/openstack/nova/+/928839 | 17:39 |
| * gibi needs to read back | 17:39 | |
| whoami-rajat | gibi, basically sean-k-mooney is proposing to add a INFO level log message to print the multipath_id and volume_id for the correlation, if that's OK for the nova team | 17:40 |
| noonedeadpunk | do you have some specific topic during the meeting for blueprint discussion? or just open discussion? | 17:41 |
| sean-k-mooney | noonedeadpunk: just open discussion | 17:41 |
| gibi | whoami-rajat, sean-k-mooney: yeah adding info level logs sounds good to me | 17:42 |
| noonedeadpunk | awesome, thanks! | 17:43 |
| whoami-rajat | thanks gibi and sean-k-mooney , i will pursue that path then | 17:46 |
| opendevreview | Merged openstack/nova master: Update compute rpc alias for dalmatian https://review.opendev.org/c/openstack/nova/+/928661 | 18:27 |
| opendevreview | sean mooney proposed openstack/nova master: Add functional repoducer for ephemeral disks https://review.opendev.org/c/openstack/nova/+/928310 | 18:36 |
| opendevreview | sean mooney proposed openstack/nova master: only saftey check bootable files created form glance https://review.opendev.org/c/openstack/nova/+/928829 | 18:36 |
| opendevreview | sean mooney proposed openstack/nova master: adapt to vfat support in oslo.utils https://review.opendev.org/c/openstack/nova/+/928462 | 18:36 |
| sean-k-mooney | bauzas: dansmith i think https://review.opendev.org/q/topic:%22bug/2079850%22 should work. its passing unit/functional tests at least | 18:38 |
| sean-k-mooney | but i have not had time to test it in devstack so we will see what the ci thinks | 18:38 |
| opendevreview | sean mooney proposed openstack/nova master: Add functional repoducer for ephemeral disks https://review.opendev.org/c/openstack/nova/+/928310 | 19:04 |
| sean-k-mooney | ill respin thoes in the morning if anything fails. im debating if i should add a release note to the second patch but since we have not released yet i dont htink its needed | 19:06 |
| sean-k-mooney | if other disagree i can add it tomorrow | 19:06 |
| opendevreview | Merged openstack/placement master: Update 2024.2 reqs to support os-traits 3.1.0 as min version https://review.opendev.org/c/openstack/placement/+/928663 | 19:14 |
| *** bauzas_ is now known as bauzas | 19:58 | |
| *** bauzas_ is now known as bauzas | 23:08 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!