Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-08-08
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
17:00:59 sean-k-mooney i help the person that was tryign to get this working make it work by telling them how to do that
17:01:27 sean-k-mooney the reason for the spec was if we wanted to acutly do this we woudl need to commit to officaly supproting tha tuse case, adding tests and not breaking it
17:02:13 sean-k-mooney johnsom: this is how to do it today with nova without code changes https://review.opendev.org/c/openstack/nova-specs/+/917109/6/specs/2024.2/approved/dynamicjson-vendordata-cloud-config.rst
17:02:24 johnsom Though, it would be nice if the flavor ID was passed to the dynamic vendor data service too.
17:02:51 sean-k-mooney we pass some infor to the vender data like the instance uuid
17:03:00 sean-k-mooney im not sure what we pass exactly
17:03:10 johnsom https://docs.openstack.org/nova/latest/admin/vendordata.html#dynamicjson
17:03:17 sean-k-mooney but we pass the instance uuid so you can make desions per instance if you want too
17:03:21 dansmith image but not flavor
17:03:30 dansmith flavor should be in there too I would think
17:03:40 sean-k-mooney ah yes its in the docs
17:03:41 johnsom I guess that service can just make another GET call
17:03:58 sean-k-mooney so this is all old code form rackspace era
17:04:03 sean-k-mooney that has kind of bitrotted
17:04:11 johnsom Sigh

Earlier   Later