| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-08-07 | |||
| 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 | |
| 16:47:03 | sean-k-mooney | which is why you cant do this in the falvor | |
| 16:47:12 | johnsom | Agree, but I think it should be able to configure cloud-init metadata | |
| 16:47:44 | sean-k-mooney | that woudl be a new feature and im not sure users woudl agree | |
| 16:47:58 | dansmith | sean-k-mooney: I'm not sure why you say we don't support it via vendordata, but if you've got a link I'd be glad to read it | |
| 16:48:20 | johnsom | Agree, it sounds like it would be a new feature. Bummer | |
| 16:48:38 | sean-k-mooney | dansmith: tldr we require the vendor data to be in a format that is diffent form what cloud in it requries | |
| 16:48:57 | sean-k-mooney | dansmith: the require a key at the top level of the resonce to be "cloud-init" | |
| 16:49:16 | sean-k-mooney | the top level key we requried is the vendor data provider | |
| 16:49:43 | sean-k-mooney | dansmith: i explain it here https://github.com/canonical/cloud-init/issues/5221 | |
| 16:50:05 | dansmith | cool, I'll check it out | |
| 16:50:12 | dansmith | should be fine to use via userdata though, AFAIK | |
| 16:50:53 | sean-k-mooney | yep usere data will work for a user just no offical way to make it work at the operator level | |
| 16:51:03 | johnsom | This seems like a common edge use case, to configure instances via cloud-init for local services like NTP or to point instances to specific endpoints. | |
| 16:51:07 | sean-k-mooney | however when i was explinging this they had already started https://review.opendev.org/c/openstack/nova-specs/+/917109 | |
| 16:51:40 | sean-k-mooney | johnsom: so the neutron subnet allwos you to configure dns server via dhcp options | |
| 16:51:48 | sean-k-mooney | i dont see why it could not supprot ntp | |