| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2024-08-08 | |||
| 03:14:59 | opendevreview | melanie witt proposed openstack/nova master: DNM testing https://review.opendev.org/c/openstack/nova/+/925635 | |
| 03:17:12 | opendevreview | melanie witt proposed openstack/nova master: DNM testing https://review.opendev.org/c/openstack/nova/+/925635 | |
| 05:12:57 | opendevreview | melanie witt proposed openstack/nova master: DNM testing cont'd https://review.opendev.org/c/openstack/nova/+/925838 | |
| 07:41:23 | opendevreview | Jens Harbott proposed openstack/nova stable/2023.1: Drop Fedora support https://review.opendev.org/c/openstack/nova/+/925940 | |
| 10:48:58 | opendevreview | sean mooney proposed openstack/nova master: update nova-next to use ubuntu 24.04 https://review.opendev.org/c/openstack/nova/+/922492 | |
| 11:10:46 | 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:12:38 | opendevreview | sean mooney proposed openstack/nova master: enable numa live migration in the ceph job https://review.opendev.org/c/openstack/nova/+/913842 | |
| 11:33:35 | 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:42:40 | sean-k-mooney | frickler: +2 on ^ | |
| 11:44:24 | frickler | ty | |
| 11:52:43 | elodilles | frickler: +2+W'd | |
| 12:00:51 | 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:06:31 | sean-k-mooney | elodilles: i was wondering if we had merged that on master when i saw them too | |
| 12:06:37 | sean-k-mooney | but sure lets get that fixed | |
| 12:15:11 | 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:16:16 | sean-k-mooney | no i think thats fine. i considered single core approving anyway since the patch is proposed by another stable core | |
| 12:17:24 | 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:18:20 | 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:25:48 | elodilles | sean-k-mooney frickler : thanks o:) | |
| 12:26:42 | elodilles | frickler: yepp, it's pure zuul config change so your review is welcome \o/ | |
| 12:29:33 | 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:30:10 | elodilles | thanks in advance o/ | |
| 13:57:16 | frickler | meh, gate is being nasty again today :( | |
| 14:03:19 | elodilles | yepp :/ | |
| 14:17:19 | opendevreview | Dan Smith proposed openstack/nova master: Use format_inspector from oslo https://review.opendev.org/c/openstack/nova/+/925025 | |
| 14:17:20 | opendevreview | Dan Smith proposed openstack/nova master: DNM: Test against oslo.utils https://review.opendev.org/c/openstack/nova/+/925026 | |
| 14:56:57 | opendevreview | Artom Lifshitz proposed openstack/nova master: POC/DNM: Remove vTPM live migration block https://review.opendev.org/c/openstack/nova/+/925771 | |
| 14:58:25 | opendevreview | Artom Lifshitz proposed openstack/nova master: POC/DNM: Remove vTPM live migration block https://review.opendev.org/c/openstack/nova/+/925771 | |
| 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 | |