Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2024-08-08
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 :)
17:24:50 sean-k-mooney so this is the request spec object https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L46
17:25:21 sean-k-mooney we provide access to the schduler hint and the instance uuid https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L100-L101
17:25:30 sean-k-mooney but not instance metadata
17:25:57 sean-k-mooney so normlaly i woudl ways your filter should use a scheduler hint, flavor extra spec or image property insted
17:26:18 sean-k-mooney if it must be the server metadata
17:28:07 sean-k-mooney the only way to do it form a filter today woudl to abuse pythons dynmic types
17:28:49 elinux sean-k-mooney: so how about specifying image extra specs and comapring them in the filter ? is that feasible ?
17:28:50 sean-k-mooney basilly implemnt the singelton patther adn do a db lookup in the filter once and asign the metadta into a dynimcaly created filed in the request spec object
17:29:13 sean-k-mooney elinux: yep the request spec has a fully copy of the flavor and image
17:29:18 sean-k-mooney including the extra specs
17:29:25 sean-k-mooney so you can look at either today
17:30:05 sean-k-mooney we just dont provided instance metadata because per instance schduling filter are ment to use scheuler hints
17:30:12 sean-k-mooney so that they will be read only once created
17:30:39 sean-k-mooney elinux: https://docs.openstack.org/nova/latest/reference/scheduler-hints-vs-flavor-extra-specs.html might be useful to read over
17:30:49 elinux sean-k-mooney: can you explain this a bit further "basilly implemnt the singelton patther adn do a db lookup in the filter once and asign the metadta into a dynimcaly created filed in the request spec object" ?
17:34:13 elinux sean-k-mooney: but I still the request's metadata information for testing it in the filter, so that I can take a decision based on its value
17:34:25 elinux *but I still need
17:37:31 sean-k-mooney https://paste.opendev.org/show/825009/
17:38:58 sean-k-mooney thats a horbile hack but on the first execution of the filter for a given request spec object you can abuse the fact that python will allow you to assign to filed that dont exist at any time to do the lookup form the buildRequest onece and then pass the same data to all other hosts

Earlier   Later