| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-08-07 | |||
| 11:54:53 | elodilles | sean-k-mooney: there is a semi-official channel: #openstack-unmaintained o:) | |
| 11:57:49 | sean-k-mooney | ack provided the unmaintained pings are not excessive i dont entirly object to havign them here too but we were very clear in teh resolution that core teams would not review patches too or genericallly maintiane the unmainted branches as part fo the resolution | |
| 11:58:07 | elodilles | yepp | |
| 11:58:56 | sean-k-mooney | so unless an unmainted branch maitiner wants input on a patch they are unsure about i woudl prefer to avoid the day to day work of maintainign them here | |
| 11:59:34 | sean-k-mooney | elodilles: if you are unsure about somethign imporant liek a cve back port we will proably be fine with a quick skim over a patch you have prepared | |
| 12:00:07 | sean-k-mooney | or if your trying to resolve a merge conflcit and we are not too busy but in general for can we review x i would prefer to keep that in #openstack-unmaintained | |
| 12:13:47 | elodilles | sean-k-mooney: ACK, thanks in advance! o:) | |
| 12:23:59 | gibi | (not that I want it) | |
| 12:24:48 | sean-k-mooney | same i considerd puting my name forward but i have too much on my plate currently to really consier it | |
| 12:25:34 | sean-k-mooney | i know many are in that both but im jsut relecting reality that i cant spend time on the unmainited branches at present | |
| 12:35:48 | gibi | we set them unmaintaned as we don't want to / cannot maintain them. So it is fair to say that we dont care :) | |
| 15:34:23 | stephenfin | elodilles: Speaking of unmaintained, we have a variety of git-review proposal patches open against cliff, python-openstackclient and openstacksdk. Can you or someone abandon those since it's very unlikely anyone will use those branches for client tooling | |
| 16:34:19 | opendevreview | melanie witt proposed openstack/nova master: libvirt: Remove node device XML validate flags https://review.opendev.org/c/openstack/nova/+/925826 | |
| 16:39:34 | JayF | sean-k-mooney: & other cores; https://review.opendev.org/q/topic:ironic-guest-metadata is tested working in devstack, I wanted some review feedback before moving beyond this point into migration/tempest. I've asked Ironic cores to look at them as well. | |
| 16:40:14 | sean-k-mooney | i was ment to loop back to those after the cve | |
| 16:40:50 | JayF | I figured :). No real rush just sometime in the next few days would be nice | |
| 16:41:10 | JayF | I'm pretty crushed right now too and wouldn't be able to do anything immediately with the feedback, but I know the queue is long so wanted to take my number ;) | |
| 16:42:40 | sean-k-mooney | JayF: does the ironic patch depend on the nova one and is that tested in ci | |
| 16:42:48 | sean-k-mooney | i.e. can we use that to demonstrate thsi end to end | |
| 16:43:08 | sean-k-mooney | we do have results form https://zuul.opendev.org/t/openstack/build/0c7147a1aea541eb88ae387cb5487fe0 also | |
| 16:43:35 | sean-k-mooney | which i guess we can reference im just not sure if the metadta will be visable in the ironic logs but i woudl hope we can see it properly there | |
| 16:43:46 | JayF | sean-k-mooney: I tested it manually in devstack. automatic_lessee defaults to false in Ironic so it won't show up in CI until we explicitly test it; and I'm not going to add to the chain until I get some directional feedback (i.e. this is good if tested) | |
| 16:44:17 | JayF | sean-k-mooney: mainly just trying to avoid a thing where I write 5 patches across 5 repos and get feedback to change a single word that takes an hour because of the stacking :P | |
| 16:45:02 | JayF | I knew I shoulda done a quick+dirty demo video; CID did that for his recent Ironic API change and it was WONDERFUL as a reviewer to see | |
| 16:45:37 | sean-k-mooney | ack we can likely turn it on in that job in a follwo up testing patch | |
| 16:45:40 | sean-k-mooney | by the way | |
| 16:45:42 | sean-k-mooney | Jul 25 20:34:42.508653 np0038062841 nova-compute[106292]: ERROR nova.network.neutron [req-a7169636-31a7-4d11-9017-a6865cd16b59 req-102a3eac-094a-42f8-a114-8ac7a841a33c service nova] [instance: 929bb573-a06a-4fa7-a77a-c643bd9655ce] The vnic_type of the bound port 88d554aa-8c7a-46ac-b54b-efeac135c643 has been changed in neutron from "normal" to "baremetal". Changing vnic_type of | |
| 16:45:44 | sean-k-mooney | a bound port is not supported by Nova. To avoid breaking the connectivity of the instance please change the port vnic_type back to "normal". | |
| 16:46:28 | sean-k-mooney | that is a sideffect of ironic doing somethign that is not allowed that related to a cve previously | |
| 16:47:02 | JayF | Can you document that in a bug somewhere please? | |
| 16:47:04 | sean-k-mooney | in this speicic case its not problematic form a secuirty point of view but is a side effect of the exisitng tech debt | |
| 16:47:52 | sean-k-mooney | sure my guess is the job is not configure properly to set the tempest config option for the vnic_type to baremental | |
| 16:48:38 | sean-k-mooney | speicicaly https://github.com/openstack/tempest/blob/master/tempest/config.py#L784-L791 | |
| 16:52:42 | sean-k-mooney | if you need a prot type other the normal nova only supprot that by passing a precreated port as part of the server create request | |
| 16:53:03 | sean-k-mooney | so ironic just like sriov ports required tempest to be configued to use the relevent vnic type in the job | |
| 17:08:16 | sean-k-mooney | JayF: https://bugs.launchpad.net/ironic/+bug/2076265 os for the issue in the job config althoguh i think the larger issue of nova/ironic/neutron interaction is really a seprate problem | |
| 17:09:15 | JayF | sean-k-mooney: I'd suggest sending an email to the mailing list proposing a joint PTG session then. It's not a topic I can address well in the moment as networking is far from my area of expertise in Ironic and I'd need to get more context | |
| 17:10:35 | elodilles | stephenfin: i guess those are mainly the .gitreview patches. i'll rather check if we could merge them now. (i also don't think that we will get (many) backports to these projects, but at least the .gitreview file should be correct) | |
| #openstack-nova - 2024-08-08 | |||
| 03:14:59 | opendevreview | melanie witt proposed openstack/nova master: DNM testing https://review.opendev.org/c/openstack/nova/+/925635 | |
| 03:17:12 | opendevreview | melanie witt proposed openstack/nova master: DNM testing https://review.opendev.org/c/openstack/nova/+/925635 | |
| 05:12:57 | opendevreview | melanie witt proposed openstack/nova master: DNM testing cont'd https://review.opendev.org/c/openstack/nova/+/925838 | |
| 07:41:23 | opendevreview | Jens Harbott proposed openstack/nova stable/2023.1: Drop Fedora support https://review.opendev.org/c/openstack/nova/+/925940 | |
| 10:48:58 | opendevreview | sean mooney proposed openstack/nova master: update nova-next to use ubuntu 24.04 https://review.opendev.org/c/openstack/nova/+/922492 | |
| 11:10:46 | opendevreview | sean mooney proposed openstack/nova master: Test live migration between hosts with differnet cpu_shared_sets https://review.opendev.org/c/openstack/nova/+/913744 | |
| 11:12:38 | opendevreview | sean mooney proposed openstack/nova master: enable numa live migration in the ceph job https://review.opendev.org/c/openstack/nova/+/913842 | |
| 11:33:35 | frickler | sean-k-mooney: gibi: if you have a moment for fedora cleanup on 2023.1 please check https://review.opendev.org/c/openstack/nova/+/925940 | |
| 11:42:40 | sean-k-mooney | frickler: +2 on ^ | |
| 11:44:24 | frickler | ty | |
| 11:52:43 | elodilles | frickler: +2+W'd | |
| 12:00:51 | elodilles | (though it was a bit hard to see the change because of the tons of zuul warnings :S i'd appreciate if stable cores would review this patch that eliminates these distracting warnings: https://review.opendev.org/c/openstack/nova/+/925522 & the stable/2023.* versions o:)) | |
| 12:06:31 | sean-k-mooney | elodilles: i was wondering if we had merged that on master when i saw them too | |
| 12:06:37 | sean-k-mooney | but sure lets get that fixed | |
| 12:15:11 | frickler | since this is a pure zuul config change, I've taken my stable-release hat to approve. please complain if you feel that that is inappropriate | |
| 12:16:16 | sean-k-mooney | no i think thats fine. i considered single core approving anyway since the patch is proposed by another stable core | |
| 12:17:24 | sean-k-mooney | we do technially allow that it just does not come up often, if elodilles: pinged again next week and no one else had reviewed i proably would have elevated to +w | |
| 12:18:20 | sean-k-mooney | we dont techinally have a required delay i just prefer to wait 7-30 days before using the single core approval excptions unless its urgent | |
| 12:25:48 | elodilles | sean-k-mooney frickler : thanks o:) | |
| 12:26:42 | elodilles | frickler: yepp, it's pure zuul config change so your review is welcome \o/ | |
| 12:29:33 | sean-k-mooney | once that merged ill try and swing back to the older backprots but it would be nice to make progress on that | |
| 12:30:10 | elodilles | thanks in advance o/ | |
| 13:57:16 | frickler | meh, gate is being nasty again today :( | |
| 14:03:19 | elodilles | yepp :/ | |
| 14:17:19 | opendevreview | Dan Smith proposed openstack/nova master: Use format_inspector from oslo https://review.opendev.org/c/openstack/nova/+/925025 | |
| 14:17:20 | opendevreview | Dan Smith proposed openstack/nova master: DNM: Test against oslo.utils https://review.opendev.org/c/openstack/nova/+/925026 | |
| 14:56:57 | opendevreview | Artom Lifshitz proposed openstack/nova master: POC/DNM: Remove vTPM live migration block https://review.opendev.org/c/openstack/nova/+/925771 | |
| 14:58:25 | opendevreview | Artom Lifshitz proposed openstack/nova master: POC/DNM: Remove vTPM live migration block https://review.opendev.org/c/openstack/nova/+/925771 | |
| 15:28:47 | frickler | next gate fail, same job, same test afaict https://zuul.opendev.org/t/openstack/build/f1b55b06740345848421fe00a57e72c8 | |
| 16:37:13 | johnsom | If a user or operator wanted to set custom NTP servers for an instance using the cloud-init module [1], how would they do that via nova? Is that something that can go in a flavor? | |
| 16:37:21 | johnsom | [1] https://cloudinit.readthedocs.io/en/latest/reference/modules.html#ntp | |
| 16:40:40 | dansmith | johnsom: not sure, but I guess that cloud config yaml goes in vendor data: https://cloudinit.readthedocs.io/en/latest/reference/datasources/openstack.html#vendor-data | |
| 16:41:35 | sean-k-mooney | you might be able to set it on the neutron network | |
| 16:41:42 | sean-k-mooney | via dhcp options? | |
| 16:42:05 | sean-k-mooney | if a user wnated to do ti then ya user-data and cloud init would be the way to do it via nova | |
| 16:42:08 | sean-k-mooney | for an operator | |
| 16:42:14 | dansmith | oh or I guess you can put the cloud config in userdata too? | |
| 16:42:17 | sean-k-mooney | you might be able to do that with vendor data | |
| 16:42:26 | johnsom | I don't think so, cloud-init usually takes precedence over DHCP options. Via DHCP is usually disabled by default. | |
| 16:42:53 | sean-k-mooney | johnsom: right but i woudl not expect cloud-init to configure this by defualt | |
| 16:43:02 | sean-k-mooney | so if its set in dhcp options on the neutron network | |
| 16:43:20 | sean-k-mooney | then that shoudl take precidence of the defualt behavior of cloud-init which should be do nothign | |
| 16:43:27 | dansmith | sean-k-mooney: the example he's asking about is _how_ to set it with cloud-init | |
| 16:43:47 | johnsom | I can look in RHEL, but I'm pretty sure it defaults to no using the DHCP options unless you enable it | |
| 16:44:02 | sean-k-mooney | ok well clodu init can executat arbitary bash via user-data or you woudl ue there module with cloud config if it exits | |
| 16:44:14 | dansmith | he linked the module above | |
| 16:44:18 | dansmith | that's what he's asking about | |
| 16:44:37 | sean-k-mooney | yep in to personas | |
| 16:44:47 | sean-k-mooney | as a user you use user-data | |
| 16:44:52 | johnsom | Yeah, there is a module. I'm just not sure how to configure nova for it. Ideally on a flavor basis | |
| 16:45:10 | sean-k-mooney | as a operator you might be able to use static vendro data or dynamic vendor data ot do it | |
| 16:45:38 | sean-k-mooney | dansmith: the cloud init docs document something we do not support | |
| 16:45:41 | sean-k-mooney | https://cloudinit.readthedocs.io/en/latest/reference/datasources/openstack.html#vendor-data | |
| 16:45:55 | sean-k-mooney | there was a whole discussion about that a few mounts back | |
| 16:45:56 | dansmith | johnsom: no way to do it per-flavor that I know of | |
| 16:46:03 | sean-k-mooney | i provide a way to hack that | |
| 16:46:07 | sean-k-mooney | to make it work | |
| 16:46:22 | sean-k-mooney | but we do not offically supprot passing cloud init cloud config vai vendor data today | |
| 16:46:30 | johnsom | Bummer, flavor would have been perfect in this case | |
| 16:46:40 | sean-k-mooney | https://github.com/canonical/cloud-init/issues/5221 | |
| 16:46:49 | sean-k-mooney | johnsom: nova should not do networking | |
| 16:46:57 | sean-k-mooney | or software configuration in guests | |