Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-08-08
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".
17:05:29 dansmith pretty sure dynamic vendor data is way after rax
17:06:06 sean-k-mooney dansmith: i think it was done by michael still
17:06:12 dansmith it was, but in 2017
17:06:28 sean-k-mooney oh i didn mean as part of the inital code dump
17:06:41 sean-k-mooney i ment it was implemed by them for the requirement they had
17:06:59 dansmith I know :)
17:07:44 sean-k-mooney johnsom: so right now we also dont provide the flavor extra specs adn addign those would be problematic unless we passed them in the post body
17:08:02 sean-k-mooney so im not really sure how you imagine this being encoded in the flavor
17:08:41 sean-k-mooney or where you hoping that could be done via custom integrations fo some kind by the opertor using custom extra specs
17:10:59 johnsom I just knew cloud-init had the module and wondered if it could be used via nova. I didn't have a design in mind. Just making sure I wasn't missing some way to do it.
17:11:34 sean-k-mooney other then what we have discussed the only othe way would be perhaps with a custom network template
17:11:59 sean-k-mooney https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.injected_network_template
17:12:22 elinux anyone online yet ?
17:12:29 sean-k-mooney which is https://github.com/openstack/nova/blob/master/nova/virt/interfaces.template
17:13:03 sean-k-mooney johnsom: if you can do it via /etc/network/interfaces you can do it as an admin via that
17:13:03 elinux sean-k-mooney: i need a small help regarding scheduler. can you help me please
17:13:21 sean-k-mooney elinux: perhaps
17:13:40 sean-k-mooney elinux: what problem are you having
17:19:41 elinux sean-k-mooney: I am writing a custom filter for scheduler, so in the process have to access the req object's metadata value, which is not passed in the code by default to the scheduler filter test of host_passes. so I have passed it from build_request object at the function 'def schedule_and_build_instances' in conductor/manage.py file. I did this by simply doing 'request_specs[0].metadata=build_requests[0].instance.metadata'
17:20:27 elinux sean-k-mooney: but when it reached the scheduler manager.py thru the rabbitmq, the spec_obj is loosing the metadata object
17:20:57 elinux sean-k-mooney: so how to pass this value to spec_obj that it retains for checking it in the filter host_pass ?
17:21:29 sean-k-mooney you dont
17:21:39 sean-k-mooney while custom out of tree filters can be written
17:21:57 sean-k-mooney they can only use the contet of the host_state object adn request spec
17:22:23 elinux sean-k-mooney: why cant we pass it like I suggested ?
17:22:48 sean-k-mooney you can in your fork but its not somehting that woudl be supproted by any disto or upstream
17:22:55 elinux sean-k-mooney: what is stripping it when it reaches the scheduler ?
17:23:27 elinux sean-k-mooney: not concerned with the support now. I want it to just make it work for our requirement
17:23:47 elinux sean-k-mooney: any ideas ?
17:24:28 elinux sean-k-mooney: how to make object assigments to a class object persistent across functions ?
17:24:34 sean-k-mooney yes but im not sure i should share them. your asking upstream to help you do somethign we dont supprot :)

Earlier   Later