| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-09-10 | |||
| 11:59:41 | sean-k-mooney | that used to autogenerate the ui in glance/heat ectra | |
| 12:01:01 | 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:03:21 | sean-k-mooney | gibi: setting it via the command line works prefectly fine | |
| 12:04:51 | sean-k-mooney | one slight problem is that igb is not included in the cirros image i belive | |
| 12:06:55 | sean-k-mooney | ya ok its not | |
| 12:07:29 | sean-k-mooney | that wont be a problem for us when trying to enable this in ci for the host | |
| 12:07:39 | sean-k-mooney | but we may want ot patch cirros to include the module going forward | |
| 12:07:51 | sean-k-mooney | frickler: ^ that would be nice to have in cirros 7 | |
| 12:14:23 | frickler | sean-k-mooney: what's the advantage of igb? I think I'm lacking some context | |
| 12:14:45 | sean-k-mooney | frickler: it support sriov in the guest i.e. you can create 7 vfs | |
| 12:15: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:55 | 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:16:09 | sean-k-mooney | ubuntu 24.04 ships new enough versions fo qemu for this | |
| 12:17:08 | gibi | sean-k-mooney: yeah cirros does not have the igb kernel module available ubuntu has it by default | |
| 12:17:29 | gibi | sean-k-mooney: sure I will look at the glance update | |
| 12:18:06 | sean-k-mooney | its one line so pretty simple. ya im uploading a ubuntu image now | |
| 12:18:23 | sean-k-mooney | lol ok i forgot ther .img images are qcow and it failed the format check | |
| 12:18:50 | 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: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 | |