| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-09-10 | |||
| 12:19:36 | sean-k-mooney | ya so we have e1000 aviabel just not igb | |
| 12:19:54 | sean-k-mooney | igb is the intel 1g nich that replaced e1000 | |
| 12:20:05 | sean-k-mooney | but its still 10 years old at this point if not more | |
| 12:20:22 | sean-k-mooney | igb was the first generation to support sriov on the intel side | |
| 12:23:51 | gibi | sean-k-mooney: done https://review.opendev.org/c/openstack/glance/+/928788 | |
| 12:24:32 | gibi | frickler: yeah I don't ask to include all the modules, just igb :) | |
| 12:24:50 | gibi | and igbvf | |
| 12:25:11 | sean-k-mooney | oh right the vf driver for using a vf in the guest | |
| 12:25:17 | sean-k-mooney | yep that would be needed too | |
| 12:34:36 | sean-k-mooney | you know its alwasy the little things.. like uploading a keypair before booting a ubuntu vm... | |
| 12:36:04 | sean-k-mooney | i can see its probing proeprly in the guest however form the console logs | |
| 12:36:05 | sean-k-mooney | [ 110.003524] igb 0000:00:03.0 ens3: renamed from eth0 | |
| 12:36:40 | sean-k-mooney | and its set properly in the xml | |
| 12:36:55 | sean-k-mooney | gibi: so at first glance this all looks like tis workign properly | |
| 12:37:24 | sean-k-mooney | gibi: ill review this properly once we have approved the bluepint and do some more testing at that point | |
| 12:40:07 | sean-k-mooney | but it is functional form what i can tell as is. | |
| 12:40:26 | sean-k-mooney | i dont have the patched os-traits in use here so the trait was not set in placement | |
| 12:41:00 | sean-k-mooney | but that at least confirms it works as intended in that regard | |
| 12:41:37 | 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:42:23 | 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:49 | sean-k-mooney | we proably dont since this will only affect new vms | |
| 12:43:17 | sean-k-mooney | and they can only be schduled to upgraded nodes but im thinking about the placement upgrade interaction | |
| 12:43:25 | sean-k-mooney | we say you should upgrade placement before nova | |
| 12:43:35 | sean-k-mooney | but i dont know if that is always followed | |
| 12:52:09 | 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:32 | sean-k-mooney | no but that already been fix again i belive | |
| 12:52:42 | sean-k-mooney | at least we had to do that downstream if i recall | |
| 12:53:09 | fungi | i wonder if the commenter is on an old version of nova without an additional fix for later python or something | |
| 12:53:17 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/853379 | |
| 12:53:31 | sean-k-mooney | we have that backported to train upstream | |
| 12:54:06 | sean-k-mooney | and it was merged in master when master was zed | |
| 12:54:16 | sean-k-mooney | so it should not be an issue form train -> master | |
| 12:54:23 | fungi | yeah, so contemporary with when it changed in stdlib | |
| 12:54:45 | sean-k-mooney | yep it was "fixed" in in python 3.10.6 | |
| 12:55:07 | sean-k-mooney | that fix on the redhat side was backported to python 3.9 | |
| 12:55:21 | sean-k-mooney | which broke centos as well but we have the upstream fix so it should be in rdo | |
| 12:55:40 | fungi | thanks, i've linked bug 1986545 in response | |
| 12:56:20 | 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:36 | sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/853379 is a test only change | |
| 12:56:54 | sean-k-mooney | to make the test work with or without the patched python version | |
| 12:57:06 | sean-k-mooney | so its not something the reportor should be worried about | |
| 12:57:15 | sean-k-mooney | i.e. there deployment is still safe | |
| 12:57:32 | sean-k-mooney | well at least form CVE-2021-28861 | |
| 12:57:43 | fungi | makes sense, thanks again | |
| 13:00:38 | 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:44 | gibi | validity. | |
| 13:01:11 | sean-k-mooney | gibi: yep that all checks out | |
| 13:01:34 | gibi | so I don't feel the need for a service version check in the pre-filter | |
| 13:01:59 | sean-k-mooney | no your right it shold not be required | |
| 13:03:21 | gibi | anyhow thanks for the quick look, I will put this on the meeting agenda for approval after RC1 is out. | |
| 13:09:28 | bauzas | gibi: I created an etherpad for RC tracking et al., I'll tell about it today on our nova meeting | |
| 13:09:37 | bauzas | gibi: so you could add your patch in there | |
| 13:10:16 | gibi | bauzas: this is for epoxy so not for the RC etherpad :) | |
| 13:11:31 | bauzas | gibi: there is a post-RC section :) | |
| 13:11:42 | bauzas | but there is also another epoxy etherpad that I created :) | |
| 13:11:52 | bauzas | again, I'll tell about it today :) | |
| 13:12:54 | bauzas | https://etherpad.opendev.org/p/nova-2025.1-status in case | |
| 13:16:38 | gibi | ohh OK I can add to that :) | |
| 13:18:14 | gibi | bauzas: ahh bummer I cannot add to it as it is a bp that needs approval :) | |
| 13:18:56 | bauzas | gibi: add then the launchpad blueprint somewhere in the etherpad by adding a new section which will be "needs approval" | |
| 13:19:32 | 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:46 | gibi | ok | |
| 13:21:44 | gibi | done | |
| 13:22:05 | bauzas | saw it | |
| 13:22:12 | bauzas | cool | |
| 13:22:28 | bauzas | I'll request for a round of reviews about many RC1 patches | |
| 13:22:30 | bauzas | I need cores | |
| 13:22:41 | gibi | bauzas: sure feel free to point me to patches | |
| 13:23:04 | bauzas | enjoy : https://etherpad.opendev.org/p/nova-dalmatian-rc-potential#L12 | |
| 13:23:14 | bauzas | those are the usual bureaucratic patches we deliver before RC1 | |
| 13:23:37 | bauzas | but they are useful for pinning versions and like, ensuring upgrades work :) | |
| 13:38:45 | 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:39:04 | gibi | I just noticed it as the openapi spec is about to be moved to implemented. | |
| 13:39:07 | bauzas | you're correct, I asked stephen last week | |
| 13:39:25 | bauzas | we agreed on creating a part-2 given we already merged some meat | |
| 13:39:43 | gibi | do we have a note in the spec stating what was done in D and what remains for E? | |
| 13:39:59 | bauzas | fwiw, physical meetups are way simplier for finding a consensus | |
| 13:40:19 | bauzas | gibi: no, but you make a good point, let's ask stephenfin | |
| 13:41:30 | 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:55 | 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:42:04 | bauzas | and I hope to do reviews of part-2 myself :) | |
| 13:42:16 | gibi | stephenfin: I think having a part-2 bp is OK | |
| 13:42:30 | bauzas | stephenfin: exactly like what we agreed : provide a part-2 and explain what's missing | |
| 13:42:39 | 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:50 | bauzas | sounds fine to me | |
| 13:44:08 | 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:54 | 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:45:01 | opendevreview | Merged openstack/nova-specs master: Create specs directory for 2025.1 Epoxy https://review.opendev.org/c/openstack/nova-specs/+/924227 | |
| 13:54:16 | 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:55:42 | bauzas | stephenfin: I said it was implemented | |
| 13:55:53 | bauzas | you'll just recreate a part-2 blueprint | |
| 13:55:56 | stephenfin | ack | |
| 13:56:01 | bauzas | and another spec file | |
| 13:56:55 | 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:57:32 | bauzas | https://blueprints.launchpad.net/nova/2024.2 is terrible to see | |
| 14:01:34 | sean-k-mooney | thats hardly surprising if your paying attention to how thing were progressing | |
| 14:03:35 | 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:04:24 | zigo | sean-k-mooney: What's the status of the virtio driver for Manila, do you know? Is it done in Dalmatian?!? | |
| 14:04:31 | 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:39 | stephenfin | gibi: bauzas: ^ | |