| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-08-08 | |||
| 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 | elinux | sean-k-mooney: i need a small help regarding scheduler. can you help me please | |
| 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: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 | |
| 17:40:59 | sean-k-mooney | for everyone else watching done ever do that in a out of tree filters that just asking for pain | |
| 17:41:19 | sean-k-mooney | s/done/don't/ | |
| 18:20:15 | opendevreview | Merged openstack/nova stable/2023.1: Drop Fedora support https://review.opendev.org/c/openstack/nova/+/925940 | |
| 18:32:09 | opendevreview | Merged openstack/nova master: libvirt: Remove node device XML validate flags https://review.opendev.org/c/openstack/nova/+/925826 | |
| 20:38:21 | opendevreview | Merged openstack/nova stable/2024.1: [CI] Replace deprecated regex https://review.opendev.org/c/openstack/nova/+/925522 | |
| 23:45:39 | opendevreview | Goutham Pacha Ravi proposed openstack/nova master: DNM: test dependency on devstack-plugin-ceph changes https://review.opendev.org/c/openstack/nova/+/918957 | |
| #openstack-nova - 2024-08-09 | |||
| 00:29:01 | opendevreview | Merged openstack/nova stable/2023.2: [CI] Replace deprecated regex https://review.opendev.org/c/openstack/nova/+/925523 | |
| 04:15:49 | opendevreview | Merged openstack/nova stable/2023.1: [CI] Replace deprecated regex https://review.opendev.org/c/openstack/nova/+/925524 | |
| 05:11:35 | opendevreview | Merged openstack/nova master: libvirt: Ensure swtpm_ioctl is available for vTPM support https://review.opendev.org/c/openstack/nova/+/908546 | |
| 05:11:44 | opendevreview | Merged openstack/nova master: libvirt: Detect vtpm support by libvirt https://review.opendev.org/c/openstack/nova/+/908508 | |
| 05:11:52 | opendevreview | Merged openstack/nova master: Fix guard for NVMeOF volumes https://review.opendev.org/c/openstack/nova/+/895192 | |
| 09:29:47 | elodilles | sean-k-mooney: thanks for the +2+W's on stable regex fixing patches o:) | |
| 09:38:17 | sean-k-mooney | i could not sleep so i tought it would be nice to wake up and have those and a few other small patches merged :) | |
| 10:28:00 | opendevreview | Maxime Lubin proposed openstack/nova-specs master: USB over IP https://review.opendev.org/c/openstack/nova-specs/+/920687 | |
| 15:04:48 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Report available TPM models https://review.opendev.org/c/openstack/nova/+/909183 | |
| 15:07:13 | opendevreview | Takashi Kajinami proposed openstack/nova master: libvirt: Report available TPM models https://review.opendev.org/c/openstack/nova/+/909183 | |
| 15:21:11 | opendevreview | Takashi Kajinami proposed openstack/nova master: Migrate MEM_ENCRYPTION_CONTEXT from root provider https://review.opendev.org/c/openstack/nova/+/921814 | |
| 15:21:12 | opendevreview | Takashi Kajinami proposed openstack/nova master: Detect AMD SEV-ES support https://review.opendev.org/c/openstack/nova/+/925685 | |
| 16:14:24 | opendevreview | Piotr Czarnik proposed openstack/nova master: Bump websockify version to 0.10.0 due to methods removal in Python3.9 https://review.opendev.org/c/openstack/nova/+/926077 | |
| 18:00:23 | opendevreview | Artom Lifshitz proposed openstack/nova master: Fix s/addtional/additional/ typo https://review.opendev.org/c/openstack/nova/+/926083 | |
| 18:48:44 | opendevreview | Ghanshyam proposed openstack/placement master: DNM: testing latest oslo.policy https://review.opendev.org/c/openstack/placement/+/926088 | |