| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-08-08 | |||
| 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 | |
| 17:04:12 | sean-k-mooney | so it supprots what they needed at the time | |
| 17:04:32 | sean-k-mooney | but again if peropel want to enhance this we could | |
| 17:04:52 | sean-k-mooney | just need a spec to desicbe it and people to do the work | |
| 17:05:28 | johnsom | Well, we are pretty far out of "officially supported" at this point, the immediate answer is going to be "create custom images". | |