| opendevreview | melanie witt proposed openstack/nova master: DNM testing https://review.opendev.org/c/openstack/nova/+/925635 | 03:14 |
|---|---|---|
| opendevreview | melanie witt proposed openstack/nova master: DNM testing https://review.opendev.org/c/openstack/nova/+/925635 | 03:17 |
| opendevreview | melanie witt proposed openstack/nova master: DNM testing cont'd https://review.opendev.org/c/openstack/nova/+/925838 | 05:12 |
| *** bauzas_ is now known as bauzas | 05:15 | |
| *** bauzas_ is now known as bauzas | 05:37 | |
| *** bauzas_ is now known as bauzas | 07:33 | |
| opendevreview | Jens Harbott proposed openstack/nova stable/2023.1: Drop Fedora support https://review.opendev.org/c/openstack/nova/+/925940 | 07:41 |
| *** bauzas- is now known as bauzas | 09:30 | |
| *** bauzas_ is now known as bauzas | 09:41 | |
| opendevreview | sean mooney proposed openstack/nova master: update nova-next to use ubuntu 24.04 https://review.opendev.org/c/openstack/nova/+/922492 | 10:48 |
| *** dmitriis is now known as Guest2496 | 10:50 | |
| opendevreview | sean mooney proposed openstack/nova master: Test live migration between hosts with differnet cpu_shared_sets https://review.opendev.org/c/openstack/nova/+/913744 | 11:10 |
| opendevreview | sean mooney proposed openstack/nova master: enable numa live migration in the ceph job https://review.opendev.org/c/openstack/nova/+/913842 | 11:12 |
| frickler | sean-k-mooney: gibi: if you have a moment for fedora cleanup on 2023.1 please check https://review.opendev.org/c/openstack/nova/+/925940 | 11:33 |
| sean-k-mooney | frickler: +2 on ^ | 11:42 |
| frickler | ty | 11:44 |
| elodilles | frickler: +2+W'd | 11:52 |
| elodilles | (though it was a bit hard to see the change because of the tons of zuul warnings :S i'd appreciate if stable cores would review this patch that eliminates these distracting warnings: https://review.opendev.org/c/openstack/nova/+/925522 & the stable/2023.* versions o:)) | 12:00 |
| sean-k-mooney | elodilles: i was wondering if we had merged that on master when i saw them too | 12:06 |
| sean-k-mooney | but sure lets get that fixed | 12:06 |
| frickler | since this is a pure zuul config change, I've taken my stable-release hat to approve. please complain if you feel that that is inappropriate | 12:15 |
| sean-k-mooney | no i think thats fine. i considered single core approving anyway since the patch is proposed by another stable core | 12:16 |
| sean-k-mooney | we do technially allow that it just does not come up often, if elodilles: pinged again next week and no one else had reviewed i proably would have elevated to +w | 12:17 |
| sean-k-mooney | we dont techinally have a required delay i just prefer to wait 7-30 days before using the single core approval excptions unless its urgent | 12:18 |
| elodilles | sean-k-mooney frickler : thanks o:) | 12:25 |
| elodilles | frickler: yepp, it's pure zuul config change so your review is welcome \o/ | 12:26 |
| sean-k-mooney | once that merged ill try and swing back to the older backprots but it would be nice to make progress on that | 12:29 |
| elodilles | thanks in advance o/ | 12:30 |
| *** bauzas- is now known as bauzas | 12:56 | |
| frickler | meh, gate is being nasty again today :( | 13:57 |
| elodilles | yepp :/ | 14:03 |
| opendevreview | Dan Smith proposed openstack/nova master: Use format_inspector from oslo https://review.opendev.org/c/openstack/nova/+/925025 | 14:17 |
| opendevreview | Dan Smith proposed openstack/nova master: DNM: Test against oslo.utils https://review.opendev.org/c/openstack/nova/+/925026 | 14:17 |
| opendevreview | Artom Lifshitz proposed openstack/nova master: POC/DNM: Remove vTPM live migration block https://review.opendev.org/c/openstack/nova/+/925771 | 14:56 |
| opendevreview | Artom Lifshitz proposed openstack/nova master: POC/DNM: Remove vTPM live migration block https://review.opendev.org/c/openstack/nova/+/925771 | 14:58 |
| frickler | next gate fail, same job, same test afaict https://zuul.opendev.org/t/openstack/build/f1b55b06740345848421fe00a57e72c8 | 15:28 |
| 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 |
| johnsom | [1] https://cloudinit.readthedocs.io/en/latest/reference/modules.html#ntp | 16:37 |
| *** bauzas_ is now known as bauzas | 16:39 | |
| 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:40 |
| sean-k-mooney | you might be able to set it on the neutron network | 16:41 |
| sean-k-mooney | via dhcp options? | 16:41 |
| 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 |
| sean-k-mooney | for an operator | 16:42 |
| dansmith | oh or I guess you can put the cloud config in userdata too? | 16:42 |
| sean-k-mooney | you might be able to do that with vendor data | 16:42 |
| johnsom | I don't think so, cloud-init usually takes precedence over DHCP options. Via DHCP is usually disabled by default. | 16:42 |
| sean-k-mooney | johnsom: right but i woudl not expect cloud-init to configure this by defualt | 16:42 |
| sean-k-mooney | so if its set in dhcp options on the neutron network | 16:43 |
| sean-k-mooney | then that shoudl take precidence of the defualt behavior of cloud-init which should be do nothign | 16:43 |
| dansmith | sean-k-mooney: the example he's asking about is _how_ to set it with cloud-init | 16:43 |
| johnsom | I can look in RHEL, but I'm pretty sure it defaults to no using the DHCP options unless you enable it | 16:43 |
| 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 |
| dansmith | he linked the module above | 16:44 |
| dansmith | that's what he's asking about | 16:44 |
| sean-k-mooney | yep in to personas | 16:44 |
| sean-k-mooney | as a user you use user-data | 16:44 |
| johnsom | Yeah, there is a module. I'm just not sure how to configure nova for it. Ideally on a flavor basis | 16:44 |
| sean-k-mooney | as a operator you might be able to use static vendro data or dynamic vendor data ot do it | 16:45 |
| sean-k-mooney | dansmith: the cloud init docs document something we do not support | 16:45 |
| sean-k-mooney | https://cloudinit.readthedocs.io/en/latest/reference/datasources/openstack.html#vendor-data | 16:45 |
| sean-k-mooney | there was a whole discussion about that a few mounts back | 16:45 |
| dansmith | johnsom: no way to do it per-flavor that I know of | 16:45 |
| sean-k-mooney | i provide a way to hack that | 16:46 |
| sean-k-mooney | to make it work | 16:46 |
| sean-k-mooney | but we do not offically supprot passing cloud init cloud config vai vendor data today | 16:46 |
| johnsom | Bummer, flavor would have been perfect in this case | 16:46 |
| sean-k-mooney | https://github.com/canonical/cloud-init/issues/5221 | 16:46 |
| sean-k-mooney | johnsom: nova should not do networking | 16:46 |
| sean-k-mooney | or software configuration in guests | 16:46 |
| sean-k-mooney | which is why you cant do this in the falvor | 16:47 |
| johnsom | Agree, but I think it should be able to configure cloud-init metadata | 16:47 |
| sean-k-mooney | that woudl be a new feature and im not sure users woudl agree | 16:47 |
| 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:47 |
| johnsom | Agree, it sounds like it would be a new feature. Bummer | 16:48 |
| 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 |
| sean-k-mooney | dansmith: the require a key at the top level of the resonce to be "cloud-init" | 16:48 |
| sean-k-mooney | the top level key we requried is the vendor data provider | 16:49 |
| sean-k-mooney | dansmith: i explain it here https://github.com/canonical/cloud-init/issues/5221 | 16:49 |
| dansmith | cool, I'll check it out | 16:50 |
| dansmith | should be fine to use via userdata though, AFAIK | 16:50 |
| sean-k-mooney | yep usere data will work for a user just no offical way to make it work at the operator level | 16:50 |
| 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 |
| sean-k-mooney | however when i was explinging this they had already started https://review.opendev.org/c/openstack/nova-specs/+/917109 | 16:51 |
| sean-k-mooney | johnsom: so the neutron subnet allwos you to configure dns server via dhcp options | 16:51 |
| sean-k-mooney | i dont see why it could not supprot ntp | 16:51 |
| dansmith | because dns is widely accepted and sort of necessary :) | 16:52 |
| sean-k-mooney | well they aslo supprot static routes | 16:52 |
| dansmith | yeah, not everyone accepts those via dhcp either | 16:52 |
| 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 |
| sean-k-mooney | sure just providing another way to do the same usecase | 16:52 |
| 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 |
| dansmith | this seems well in scope for a cloud-init thing to me | 16:53 |
| sean-k-mooney | i was thinkign of the pxe boot usecase peopel had in the past | 16:53 |
| sean-k-mooney | https://docs.openstack.org/api-ref/network/v2/index.html#id315 | 16:53 |
| johnsom | Yeah, the problem with the DHCP options isn't necessarily neutron, but the distributions not enabling them | 16:53 |
| sean-k-mooney | johnsom: the problem with the flavor is the image might not have cloud-init | 16:54 |
| johnsom | hw_vif_model question is around using the igb driver for SR-IOV testing in nodepool | 16:54 |
| sean-k-mooney | so it was on my list of things to enable and i just have not got ot it | 16:55 |
| sean-k-mooney | but i too want ot add that | 16:55 |
| johnsom | Well, in our world they have cloud-init | 16:55 |
| sean-k-mooney | our being? its not alwasy there for openstack workloads in general | 16:55 |
| sean-k-mooney | think workload like core os or talos linux | 16:56 |
| sean-k-mooney | or windows if they dont have the cloud base init fork | 16:56 |
| johnsom | our being Octavia amphora images. | 16:56 |
| sean-k-mooney | ah | 16:56 |
| sean-k-mooney | well for octavia since your creating the instnaces you can simply pass user-data with your cloud config settings | 16:56 |
| 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:57 |
| sean-k-mooney | i feel like i put that on the ptg adjenda for the last one | 16:58 |
| sean-k-mooney | but i dont recall if we had time to disucss it | 16:58 |
| 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 |
| johnsom | But, yes, looking at the spirit of dynamic vendor data, it could be a solution (assuming it works at some point). | 16:59 |
| johnsom | I think the current answer is, cannot be done. | 17:00 |
| sean-k-mooney | it can by abusing the json standard | 17:00 |
| johnsom | lol | 17:00 |
| 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 |
| johnsom | +1 | 17:00 |
| 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:00 |
| 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:01 |
| 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 |
| johnsom | Though, it would be nice if the flavor ID was passed to the dynamic vendor data service too. | 17:02 |
| sean-k-mooney | we pass some infor to the vender data like the instance uuid | 17:02 |
| sean-k-mooney | im not sure what we pass exactly | 17:03 |
| johnsom | https://docs.openstack.org/nova/latest/admin/vendordata.html#dynamicjson | 17:03 |
| sean-k-mooney | but we pass the instance uuid so you can make desions per instance if you want too | 17:03 |
| dansmith | image but not flavor | 17:03 |
| dansmith | flavor should be in there too I would think | 17:03 |
| sean-k-mooney | ah yes its in the docs | 17:03 |
| johnsom | I guess that service can just make another GET call | 17:03 |
| sean-k-mooney | so this is all old code form rackspace era | 17:03 |
| sean-k-mooney | that has kind of bitrotted | 17:04 |
| johnsom | Sigh | 17:04 |
| sean-k-mooney | so it supprots what they needed at the time | 17:04 |
| sean-k-mooney | but again if peropel want to enhance this we could | 17:04 |
| sean-k-mooney | just need a spec to desicbe it and people to do the work | 17:04 |
| 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 |
| dansmith | pretty sure dynamic vendor data is way after rax | 17:05 |
| sean-k-mooney | dansmith: i think it was done by michael still | 17:06 |
| dansmith | it was, but in 2017 | 17:06 |
| sean-k-mooney | oh i didn mean as part of the inital code dump | 17:06 |
| sean-k-mooney | i ment it was implemed by them for the requirement they had | 17:06 |
| dansmith | I know :) | 17:06 |
| 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:07 |
| sean-k-mooney | so im not really sure how you imagine this being encoded in the flavor | 17:08 |
| 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:08 |
| 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:10 |
| sean-k-mooney | other then what we have discussed the only othe way would be perhaps with a custom network template | 17:11 |
| sean-k-mooney | https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.injected_network_template | 17:11 |
| elinux | anyone online yet ? | 17:12 |
| sean-k-mooney | which is https://github.com/openstack/nova/blob/master/nova/virt/interfaces.template | 17:12 |
| elinux | sean-k-mooney: i need a small help regarding scheduler. can you help me please | 17:13 |
| sean-k-mooney | johnsom: if you can do it via /etc/network/interfaces you can do it as an admin via that | 17:13 |
| sean-k-mooney | elinux: perhaps | 17:13 |
| sean-k-mooney | elinux: what problem are you having | 17:13 |
| 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:19 |
| 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 |
| 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:20 |
| sean-k-mooney | you dont | 17:21 |
| sean-k-mooney | while custom out of tree filters can be written | 17:21 |
| sean-k-mooney | they can only use the contet of the host_state object adn request spec | 17:21 |
| elinux | sean-k-mooney: why cant we pass it like I suggested ? | 17:22 |
| sean-k-mooney | you can in your fork but its not somehting that woudl be supproted by any disto or upstream | 17:22 |
| elinux | sean-k-mooney: what is stripping it when it reaches the scheduler ? | 17:22 |
| elinux | sean-k-mooney: not concerned with the support now. I want it to just make it work for our requirement | 17:23 |
| elinux | sean-k-mooney: any ideas ? | 17:23 |
| elinux | sean-k-mooney: how to make object assigments to a class object persistent across functions ? | 17:24 |
| 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 |
| sean-k-mooney | so this is the request spec object https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L46 | 17:24 |
| 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 |
| sean-k-mooney | but not instance metadata | 17:25 |
| sean-k-mooney | so normlaly i woudl ways your filter should use a scheduler hint, flavor extra spec or image property insted | 17:25 |
| sean-k-mooney | if it must be the server metadata | 17:26 |
| sean-k-mooney | the only way to do it form a filter today woudl to abuse pythons dynmic types | 17:28 |
| elinux | sean-k-mooney: so how about specifying image extra specs and comapring them in the filter ? is that feasible ? | 17:28 |
| 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:28 |
| sean-k-mooney | elinux: yep the request spec has a fully copy of the flavor and image | 17:29 |
| sean-k-mooney | including the extra specs | 17:29 |
| sean-k-mooney | so you can look at either today | 17:29 |
| sean-k-mooney | we just dont provided instance metadata because per instance schduling filter are ment to use scheuler hints | 17:30 |
| sean-k-mooney | so that they will be read only once created | 17:30 |
| 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 |
| 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:30 |
| 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 |
| elinux | *but I still need | 17:34 |
| sean-k-mooney | https://paste.opendev.org/show/825009/ | 17:37 |
| 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:38 |
| sean-k-mooney | for everyone else watching done ever do that in a out of tree filters that just asking for pain | 17:40 |
| sean-k-mooney | s/done/don't/ | 17:41 |
| opendevreview | Merged openstack/nova stable/2023.1: Drop Fedora support https://review.opendev.org/c/openstack/nova/+/925940 | 18:20 |
| *** ministry is now known as __ministry | 18:27 | |
| opendevreview | Merged openstack/nova master: libvirt: Remove node device XML validate flags https://review.opendev.org/c/openstack/nova/+/925826 | 18:32 |
| *** bauzas_ is now known as bauzas | 19:32 | |
| opendevreview | Merged openstack/nova stable/2024.1: [CI] Replace deprecated regex https://review.opendev.org/c/openstack/nova/+/925522 | 20:38 |
| opendevreview | Goutham Pacha Ravi proposed openstack/nova master: DNM: test dependency on devstack-plugin-ceph changes https://review.opendev.org/c/openstack/nova/+/918957 | 23:45 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!