Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-08-07
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
16:52:03 dansmith because dns is widely accepted and sort of necessary :)
16:52:14 sean-k-mooney well they aslo supprot static routes
16:52:39 dansmith yeah, not everyone accepts those via dhcp either
16:52:44 sean-k-mooney im just saying there are other dhcp options and neutron could have a facility to allow you to specify them for the network
16:52:58 sean-k-mooney sure just providing another way to do the same usecase
16:53:11 johnsom Another quick (?) question, is there a way to set the hw_vif_model setting other than a property on the image? Like at instance creation time?
16:53:12 dansmith this seems well in scope for a cloud-init thing to me
16:53:16 sean-k-mooney i was thinkign of the pxe boot usecase peopel had in the past
16:53:37 sean-k-mooney https://docs.openstack.org/api-ref/network/v2/index.html#id315
16:53:46 johnsom Yeah, the problem with the DHCP options isn't necessarily neutron, but the distributions not enabling them

Earlier   Later