Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-08-08
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
16:54:14 sean-k-mooney johnsom: the problem with the flavor is the image might not have cloud-init
16:54:40 johnsom hw_vif_model question is around using the igb driver for SR-IOV testing in nodepool
16:55:02 sean-k-mooney so it was on my list of things to enable and i just have not got ot it
16:55:06 sean-k-mooney but i too want ot add that
16:55:09 johnsom Well, in our world they have cloud-init
16:55:36 sean-k-mooney our being? its not alwasy there for openstack workloads in general
16:56:12 sean-k-mooney think workload like core os or talos linux
16:56:23 sean-k-mooney or windows if they dont have the cloud base init fork
16:56:26 johnsom our being Octavia amphora images.
16:56:31 sean-k-mooney ah
16:56:52 sean-k-mooney well for octavia since your creating the instnaces you can simply pass user-data with your cloud config settings
16:57:31 sean-k-mooney johnsom: if you think nova should supprot this vai vendor data you should read and comment on https://review.opendev.org/c/openstack/nova-specs/+/917109/6/specs/2024.2/approved/dynamicjson-vendordata-cloud-config.rst
16:58:39 sean-k-mooney i feel like i put that on the ptg adjenda for the last one
16:58:47 sean-k-mooney but i dont recall if we had time to disucss it
16:59:01 johnsom That is less than ideal in this customer use case. They as the operator wants to configure it in a way they can point at different endpoints based on the flavor used.
16:59:49 johnsom But, yes, looking at the spirit of dynamic vendor data, it could be a solution (assuming it works at some point).
17:00:09 johnsom I think the current answer is, cannot be done.
17:00:22 sean-k-mooney it can by abusing the json standard
17:00:27 johnsom lol
17:00:41 dansmith yep, seems like the perfect way to handle this, any sort of per-site compute cloud-init stuff being a dynamic vendordata thing that coughs up a blob of config
17:00:56 johnsom +1

Earlier   Later