| opendevreview | Andrew Bonney proposed openstack/openstack-ansible-os_magnum master: DNM: Test mcapi CI https://review.opendev.org/c/openstack/openstack-ansible-os_magnum/+/966564 | 09:02 |
|---|---|---|
| opendevreview | Andrew Bonney proposed openstack/openstack-ansible-ops master: DNM: Test updating mcapi versions to latest https://review.opendev.org/c/openstack/openstack-ansible-ops/+/966563 | 09:03 |
| opendevreview | Andrew Bonney proposed openstack/openstack-ansible-os_magnum master: DNM: Test mcapi CI https://review.opendev.org/c/openstack/openstack-ansible-os_magnum/+/966564 | 09:04 |
| noonedeadpunk | I will try to work on magnum thing during these weekends | 09:06 |
| noonedeadpunk | the only concern I have so far, if current collections/roles do allow to get custom helm charts in | 09:09 |
| noonedeadpunk | but it's bad that we've broken the pattern | 09:13 |
| opendevreview | Merged openstack/openstack-ansible-os_tacker master: Remove functional test environments from tox.ini https://review.opendev.org/c/openstack/openstack-ansible-os_tacker/+/960903 | 09:18 |
| jrosser | noonedeadpunk: if you think we can start to move the cluster api stuff out of the ops repo, then there are more options for fixing the current breakage | 09:29 |
| jrosser | andrew and i were just discussing how to fix templating the k8s conf.d file, and its pretty difficult to do that from a pre playbook that runs on the zuul executor | 09:30 |
| jrosser | it would be a lot easier to move that into the main repo, but that kind of is the starting point to migrate other stuff | 09:30 |
| jrosser | imho the CI setup for this is really opaque how it works for mcapi and it would be better to simplify rather than add more complexity | 09:31 |
| noonedeadpunk | I think we can, but I want to ensure we have both capi drivers supported with that | 09:32 |
| noonedeadpunk | and it's a matter of some kind of switch which one to use | 09:32 |
| noonedeadpunk | (or both) | 09:32 |
| jrosser | yes indeed | 09:33 |
| jrosser | so first problem is really simple of just deciding if we want to create the k8s lxc containers / conf.d entries | 09:33 |
| jrosser | if that were a common thing to vexxhost/azimuth then it can rightly be in the main repo | 09:33 |
| noonedeadpunk | yes, this is a common thing | 09:35 |
| noonedeadpunk | there were some extra steps required for k8s cluster deployment though | 09:38 |
| noonedeadpunk | I think it was smth like 2 extra tasks or smthj | 09:38 |
| noonedeadpunk | I have notes somewhere.... | 09:38 |
| jrosser | yeah, so we need a way of distinguishing the job name | 09:38 |
| jrosser | magnum_<vexxhost> / magnum_<stackhpc> or whatever the most proper terms for these are | 09:39 |
| jrosser | once magnum drops the heat driver it will then be implicit that any job deploying magnum needs at least the control plane k8s cluster | 09:39 |
| jrosser | then some specialisation depending on which driver is wanted | 09:40 |
| noonedeadpunk | I think you can do even both at the same time if you want to | 09:40 |
| noonedeadpunk | they made a workaround to avoid image naming tags conflict | 09:40 |
| noonedeadpunk | and inside of k8s a different namespaces are being used | 09:41 |
| jrosser | ok cool we'll start to simplify the CI setup a bit | 09:45 |
| noonedeadpunk | I think these 2 steps were: 1. helm repo add capi-addons https://azimuth-cloud.github.io/cluster-api-addon-provider 2. kubectl create namespace capi-addons | 09:50 |
| jrosser | ok, so as step zero we will take the part that bootstraps the deployment of the k8s control plane cluster (just the conf.d and AIO scenario handling) and move that to the main repo | 09:51 |
| jrosser | independant of whatever driver, that can still be in the ops repo | 09:52 |
| jrosser | for now | 09:52 |
| noonedeadpunk | here's the full paste https://paste.openstack.org/show/bE9DCpZifNollLjbqXAw/ | 09:57 |
| noonedeadpunk | right, I think the main concern for me so far if vexxhost.kubernetes collection could be used to execute these 2 steps | 09:58 |
| jrosser | yeah, or we have to handle that in our own code | 09:58 |
| opendevreview | Andrew Bonney proposed openstack/openstack-ansible master: DNM: Add minimal AIO files for k8s clusters https://review.opendev.org/c/openstack/openstack-ansible/+/966666 | 10:00 |
| opendevreview | Andrew Bonney proposed openstack/openstack-ansible-ops master: DNM: Test updating mcapi versions to latest https://review.opendev.org/c/openstack/openstack-ansible-ops/+/966563 | 10:01 |
| noonedeadpunk | (or use a forked collection) | 10:06 |
| jrosser | noonedeadpunk: did we ever manage to have it so that depends-on for collections (like the ops repo) works properly? | 11:01 |
| noonedeadpunk[e] | No, I don't think we ever tried for ops repo tbh. It does work for plugins repo though | 11:04 |
| jrosser | hmm ok i wonder how it only works for one of them | 11:26 |
| noonedeadpunk | we probably don't have ops in required-projects? | 11:27 |
| noonedeadpunk | and there's a different naming for collection path, which I have no idea if it's compatible | 11:27 |
| noonedeadpunk | having repo here is required iirc: https://opendev.org/openstack/openstack-ansible/src/branch/master/zuul.d/jobs.yaml#L218 | 11:29 |
| jrosser | its more complicated sadly | 11:33 |
| jrosser | we dont have it in ansible-collection-requirements so it's never a candidate to use the zuul copy rather than upstream | 11:34 |
| noonedeadpunk | right.... | 11:34 |
| jrosser | and then both the integrated repo and the also the many hacks in the ops repo are both wanting to control the contents of user-collection-requirements | 11:34 |
| noonedeadpunk | and we don't mess up with user-collection-requirements | 11:34 |
| jrosser | so thats just horribly and we need to undo that mess | 11:34 |
| opendevreview | Andrew Bonney proposed openstack/openstack-ansible master: DNM: Add minimal AIO files for k8s clusters https://review.opendev.org/c/openstack/openstack-ansible/+/966666 | 11:35 |
| opendevreview | Andrew Bonney proposed openstack/openstack-ansible-ops master: DNM: Test updating mcapi versions to latest https://review.opendev.org/c/openstack/openstack-ansible-ops/+/966563 | 11:36 |
| jrosser | i think that for the long term there might be a missing concept, where an AIO scenario needs extra collections to be installed | 11:36 |
| jrosser | we don't have a way to cleanly define that currently | 11:36 |
| opendevreview | Andrew Bonney proposed openstack/openstack-ansible master: DNM: Add minimal AIO files for k8s clusters https://review.opendev.org/c/openstack/openstack-ansible/+/966666 | 11:48 |
| andrewbonney | mnaser: would it be possible to release that ansible-collection-containers fix? having a tagged version would save me doing a temporary clone from url | 12:49 |
| noonedeadpunk | #startmeeting openstack_ansible_meeting | 15:00 |
| opendevmeet | Meeting started Tue Nov 11 15:00:03 2025 UTC and is due to finish in 60 minutes. The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot. | 15:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 15:00 |
| opendevmeet | The meeting name has been set to 'openstack_ansible_meeting' | 15:00 |
| noonedeadpunk | #topic rollcall | 15:00 |
| damiandabrowski | hi! | 15:00 |
| noonedeadpunk | o/ | 15:00 |
| noonedeadpunk | courtesy ping janno | 15:02 |
| noonedeadpunk | oops | 15:02 |
| noonedeadpunk | jrosser: | 15:02 |
| damiandabrowski | Would be nice to discuss two things regarding https://review.opendev.org/c/openstack/ansible-role-pki/+/948881 | 15:03 |
| damiandabrowski | 1. change default vault path names `pki` -> `pki_root` (for path containing pki root) | 15:03 |
| damiandabrowski | `pki_int` -> `pki` (for path containing intermediate cert and all service certs) | 15:03 |
| damiandabrowski | Originally suggested by noonedeadpunk. I'm fine with this. | 15:03 |
| damiandabrowski | 2. Rename `vault_root_ca_path` to `signed_by` | 15:03 |
| damiandabrowski | we can rename vault_root_ca_path to signed_by | 15:03 |
| damiandabrowski | I didn't do this before because I wanted to avoid a situation where we have the same variable(signed_by) that accepts different values depending on the backend(cert name for standalone, vault path for hashi_vault). | 15:03 |
| damiandabrowski | but maybe you don't see it as a problem | 15:04 |
| damiandabrowski | and its name - vault_root_ca_path was more explicit that this variable is about the vault path | 15:04 |
| damiandabrowski | so that was the reason why I implemented it that way, but I don't have a strong opinion here. | 15:04 |
| damiandabrowski | If you think it's better to rename it to signed_by, I'm okay with this | 15:04 |
| noonedeadpunk | I frankly don't have strong opinion on it either. as we're not passing a cert name via signed_by in this case, but really a vault mount path | 15:05 |
| noonedeadpunk | regarding pki / pki_root - I just find current example being a bit unobvious to read | 15:06 |
| damiandabrowski | yeah, you may be right about that | 15:06 |
| noonedeadpunk | but using `signed_by` would also solve this ambiguity for me | 15:07 |
| noonedeadpunk | so it's matter of just agreeing on some option | 15:07 |
| noonedeadpunk | but I'm not sure if that what jrosser meant when mentioned signed_by | 15:07 |
| damiandabrowski | okay, so maybe lets wait for his opinion until we make some decision about 2. | 15:08 |
| damiandabrowski | and regarding 1. - I'll fix it tomorrow | 15:08 |
| noonedeadpunk | But I think second thing we need to sort out, is actually aboput support for debian 12 | 15:09 |
| damiandabrowski | ah yes... | 15:09 |
| noonedeadpunk | and hcl requirement (or how it's called) | 15:09 |
| damiandabrowski | hvac :D | 15:09 |
| noonedeadpunk | right | 15:09 |
| damiandabrowski | so yes, TLDR; if we want to support debian 12 we need to install hvac with pip using --break-system-packages | 15:10 |
| damiandabrowski | (debian 12 has too old hvac version in its repositories) | 15:10 |
| noonedeadpunk | #link https://review.opendev.org/c/openstack/openstack-ansible/+/948888/10/requirements.txt | 15:10 |
| noonedeadpunk | I don't like this ^ at all | 15:10 |
| damiandabrowski | is there any other place where we can place this requirement? | 15:11 |
| noonedeadpunk | well. we can do multiple things I guess... | 15:12 |
| noonedeadpunk | 1. Add it as extras ie https://opendev.org/openstack/openstack-ansible/src/branch/master/setup.cfg#L29-L32, and then assume somebody doing `pip install .[hvac]` or smth. But it kinda sucks, as not obvious and complex | 15:13 |
| noonedeadpunk | 2. Add documentation/alert/reno that the following module is requiredspecifically for debian 12 | 15:13 |
| noonedeadpunk | 3. Inside of the pki role create a spearate venv, install requirements there, and use different pki_setup_host_python_interpreter for debian 12 | 15:15 |
| noonedeadpunk | for 1. we can ofc modify the bootstrap script or smth.... | 15:17 |
| damiandabrowski | just to clarify: this package is required for all OS | 15:17 |
| damiandabrowski | but for all other OS it can be installed from system repositories. And I'm not sure if we want to do that if there's an option to install it just in /opt/ansible-runtime | 15:18 |
| damiandabrowski | which is enough | 15:18 |
| NeilHanlon | o/ sorry, triple booked today | 15:18 |
| noonedeadpunk | and for 2. we can document adding the module to openstack_deploy/user-ansible-venv-requirements.txt | 15:18 |
| damiandabrowski | but maybe let's start from scratch. Why do you think requirements.txt is a bad place for it? :D | 15:19 |
| damiandabrowski | requirements.txt is used when building /opt/ansible-runtime venv, so it looked like a valid place for it | 15:19 |
| jrosser | o/ sorry i'm late | 15:20 |
| noonedeadpunk | no worries - there's a question to you above I believe | 15:23 |
| noonedeadpunk | while I'm thinking on hvac :) | 15:23 |
| jrosser | for signed_by it seemed that using the name of the root to sign the intermediate is quite "obvious" | 15:23 |
| jrosser | and also for which intermediate signs a cert | 15:23 |
| jrosser | how that maps to internals (i.e the mount point in vault of a particular CA) we can choose however we wish | 15:23 |
| noonedeadpunk | I think the problem there, is that you can't actually select a root or intermediate directly | 15:23 |
| noonedeadpunk | as intermediate should be stored in the same place as certs I assume | 15:24 |
| jrosser | you do it via the mount point? | 15:24 |
| noonedeadpunk | yeah | 15:24 |
| noonedeadpunk | so same mount point for intermediate as the cert, same or different for root | 15:24 |
| jrosser | right, so its like `{{ vault_mount_point_prefix }}/{{ item.signed_by }}` or something | 15:25 |
| damiandabrowski | i tried to explain it in this diagram: https://ibb.co/6R3rGYBC | 15:25 |
| jrosser | i am just wanting to keep the data abstract in the input to the role | 15:25 |
| noonedeadpunk | I have no idea if you can do it like that though | 15:25 |
| damiandabrowski | we don't point to any specific issuer | 15:25 |
| noonedeadpunk | as from what I got, you're limited only to `vault_mount_point_prefix` - what you can actually define | 15:26 |
| damiandabrowski | yeah | 15:26 |
| jrosser | oh right | 15:26 |
| noonedeadpunk | so it's {{ item.signed_by }}/some/other/api/call | 15:26 |
| jrosser | well regardless, if we can keep the input data not being shaped by the implementation in vault, that would be excellent | 15:27 |
| noonedeadpunk | the problem here, is that it feels, that for intermediate you still need to introduce smth | 15:30 |
| noonedeadpunk | for standalone we were using just `name` to identify the path | 15:30 |
| jrosser | indeed | 15:30 |
| damiandabrowski | yeah, I'm afraid that for hashi_vault we just cannot keep the logic from standalone backend, where we explicitly specify issuing certificate | 15:30 |
| noonedeadpunk | I'm not sure this is gonna be applicable for vault | 15:30 |
| damiandabrowski | at least I couldn't find a way to achieve this | 15:31 |
| noonedeadpunk | and then root also needs some "signed_by" which makes limited sense | 15:31 |
| noonedeadpunk | and then certs themselves don't have any choice | 15:31 |
| noonedeadpunk | as they will be signed with whatever available on their mount point | 15:32 |
| noonedeadpunk | But we can call that `signed_by` though | 15:32 |
| noonedeadpunk | it's a matter of relation kinda. | 15:32 |
| noonedeadpunk | sec | 15:33 |
| noonedeadpunk | https://paste.openstack.org/show/bKHPlUr8lddmPwa1b1XF/ | 15:34 |
| noonedeadpunk | smth like that? | 15:34 |
| damiandabrowski | yeah, we can do that | 15:35 |
| noonedeadpunk | damiandabrowski: I have an answer to you why I don;t like requirements.txt - because `pki_setup_host` can be anything. and we're not ensuring that role does necessary things to get itself independent for osa | 15:35 |
| noonedeadpunk | Ie - we can use repo or utility containers even for pki_setup_host and vault | 15:36 |
| noonedeadpunk | and then - connectivity from osa deploy host to vault becomes more of a requirement if we don't have a self-contained mechanism to install hvac | 15:36 |
| noonedeadpunk | so installing a package sounds like a way easier thing to do | 15:37 |
| damiandabrowski | ahh right, makes sense | 15:37 |
| noonedeadpunk | but sure - we can actually spawn a separate venv on the pki_setup_host with hvac | 15:38 |
| jrosser | that might be a good thing to do anyway as then we can be in more control of the version of cryptography or whatever else we might need | 15:39 |
| noonedeadpunk | it's pinned by u-c, but yeah | 15:39 |
| noonedeadpunk | so "control" :) | 15:39 |
| noonedeadpunk | ok, so are we in agreement about the paste above? | 15:39 |
| damiandabrowski | but we want to spawn a separate venv only for debian12, do I get it right? | 15:39 |
| noonedeadpunk | it makes sense to do it universally then? | 15:40 |
| noonedeadpunk | Dunno | 15:40 |
| noonedeadpunk | I actually hate this situation, as we're to add complexity for OS which we should have deprecated if were in time for adding Debian 13 support for Epoxy | 15:40 |
| damiandabrowski | when we will drop support for debian 12? | 15:40 |
| noonedeadpunk | we have to carry it through 2026.1 at this point | 15:41 |
| noonedeadpunk | so early 2026.2 | 15:41 |
| damiandabrowski | because I'm afraid of the situation when support for debian 12 will be dropped but we'll still keep this "dedicated venv" thing for no reason | 15:41 |
| noonedeadpunk | well, reason is "control" of versions | 15:41 |
| damiandabrowski | okay, I'll try implement this | 15:42 |
| noonedeadpunk | it's possible that we get into this versioning situation again in the future | 15:42 |
| noonedeadpunk | when we'd need to implement smth newer, which some os does not support | 15:42 |
| damiandabrowski | yeah...ack | 15:43 |
| noonedeadpunk | so it could be good to have in general, even for standalone backend, as jrosser mentioned | 15:43 |
| noonedeadpunk | damiandabrowski: btw I've also spotted that you don;t use pki_setup_host_python_interpreter anywhere for the vault code | 15:44 |
| noonedeadpunk | * just spotted | 15:44 |
| damiandabrowski | ack, I'll look into that | 15:45 |
| noonedeadpunk | jrosser: about the swift library - seems that https://review.opendev.org/c/openstack/openstack-ansible-openstack_hosts/+/966515 kinda helps a bit with that | 15:46 |
| noonedeadpunk | but Ironic still feeling bad | 15:46 |
| jrosser | oh theres a depends on is there | 15:47 |
| damiandabrowski | sorry guys, I'll drop off :D it's public holiday in Poland, I just joined to discuss PKI stuff | 15:47 |
| noonedeadpunk | ah, sure, take care | 15:47 |
| jrosser | we also still need to remove inspector? | 15:47 |
| noonedeadpunk | It fails on `msg: Source /usr/share/ipxe/ipxe-x86_64.efi not found` for EL10 | 15:48 |
| jrosser | errrr | 15:48 |
| noonedeadpunk | and for ubuntu on tempest tests | 15:48 |
| jrosser | which parch are we looking at | 15:48 |
| jrosser | *patch | 15:48 |
| noonedeadpunk | https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/951003 | 15:48 |
| noonedeadpunk | But it could be we need to break relation chain | 15:49 |
| noonedeadpunk | and rebase https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/950508 on top of master | 15:50 |
| noonedeadpunk | and add depends-in | 15:50 |
| noonedeadpunk | *depends-on | 15:50 |
| noonedeadpunk | right... | 15:50 |
| jrosser | ironic service is down i think | 15:50 |
| opendevreview | Jonathan Rosser proposed openstack/openstack-ansible-os_ironic master: Switch from wsgi script to wsgi module https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/950508 | 15:50 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_ironic master: Switch from wsgi script to wsgi module https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/950508 | 15:51 |
| noonedeadpunk | it won't solve this one though: https://zuul.opendev.org/t/openstack/build/04300573a8434d26935a36fcaccd9bc7/log/job-output.txt#14411-14415 | 15:51 |
| noonedeadpunk | have no idea what provides this one | 15:52 |
| jrosser | hmm https://opendev.org/openstack/ironic/src/branch/master/doc/source/install/configure-pxe.rst#L298 | 15:53 |
| jrosser | oh unhelpful link, but that doesnt help | 15:54 |
| noonedeadpunk | will check if might be just the path is different | 15:54 |
| jrosser | yeah | 15:55 |
| noonedeadpunk | I think almost the last think - what do you think about uv patch here: | 15:55 |
| jrosser | it didnt fail at installing `grub2-efi-x64` | 15:55 |
| jrosser | so the firmware should be somewhere | 15:55 |
| noonedeadpunk | #link https://review.opendev.org/c/openstack/openstack-ansible/+/966409 | 15:55 |
| jrosser | i thought this was good | 15:56 |
| jrosser | but we have to be careful of how we test this, and if we decide to change the default | 15:56 |
| noonedeadpunk | the problem is that uv has no way of building wheels so far | 15:56 |
| noonedeadpunk | and one thing which would be beneficial to do, if uv would be creating venvs as well. as it's doing it quite faster | 15:57 |
| noonedeadpunk | but now what I was doing, is installing uv inside of the existing venv | 15:57 |
| noonedeadpunk | as it's installation process is not really easy outside of venv | 15:57 |
| jrosser | hah if python_venv_build needs its own venv with pip to install uv to then make a venv | 15:58 |
| jrosser | thats quite something | 15:58 |
| jrosser | theres a danger of adding a *lot* of tasks that ensure that is present on * places | 15:59 |
| noonedeadpunk | well, so I made uv to operate inside already created venv by `python3 -m venv` | 15:59 |
| noonedeadpunk | and then instead of upgrading pip in that venv, I'm installing uv there | 16:00 |
| noonedeadpunk | but we're not benefitting from venv creation process | 16:00 |
| noonedeadpunk | so uv usage is really minimal right now.... | 16:00 |
| noonedeadpunk | and about testing - yes, sure, I was thinking to add molecule coverage to the role | 16:01 |
| jrosser | it could also be that the ever-present pip resolver errors happen in different ways | 16:03 |
| jrosser | i think thats my bigger concern that we need to be using that one way, or the other | 16:03 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_ironic master: Switch from wsgi script to wsgi module https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/950508 | 16:03 |
| jrosser | making it switchable gives 2x (currently) the options for people to try and us to debug | 16:04 |
| noonedeadpunk | but if we can save ~5mins on each CI job.... | 16:04 |
| noonedeadpunk | but indeed I get the concern... | 16:05 |
| jrosser | yeah, we need, imho, to be comfortable enough to commit to "now we use uv" rather than make another tunable | 16:05 |
| noonedeadpunk | I was trying to think of more ways for us to leverage uv, but I wasn't able to come up wit hanything decent enough | 16:06 |
| noonedeadpunk | well, we can't for wheels at least | 16:06 |
| noonedeadpunk | as it does not support building things for requirements, like pip does | 16:06 |
| noonedeadpunk | it can build only wheels for "current" project | 16:06 |
| noonedeadpunk | maybe we can skip wheels part with uv as a whole, dunno | 16:07 |
| noonedeadpunk | as it does some efficient local caching... | 16:07 |
| noonedeadpunk | and then drop whole repo part.... | 16:08 |
| noonedeadpunk | but I'm not sure about that | 16:08 |
| noonedeadpunk | #endmeeting | 16:08 |
| opendevmeet | Meeting ended Tue Nov 11 16:08:46 2025 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:08 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/openstack_ansible_meeting/2025/openstack_ansible_meeting.2025-11-11-15.00.html | 16:08 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/openstack_ansible_meeting/2025/openstack_ansible_meeting.2025-11-11-15.00.txt | 16:08 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/openstack_ansible_meeting/2025/openstack_ansible_meeting.2025-11-11-15.00.log.html | 16:08 |
| noonedeadpunk | btw, we a reminder, that we are having a bug fighting day this Thursday | 16:09 |
| noonedeadpunk | I've sent a ML with announcement yesterday | 16:09 |
| noonedeadpunk | and the we agreed on the date on the PTG | 16:09 |
| opendevreview | Merged openstack/openstack-ansible-os_zun master: Switch from wsgi script to wsgi module https://review.opendev.org/c/openstack/openstack-ansible-os_zun/+/950520 | 16:24 |
| opendevreview | Merged openstack/openstack-ansible-os_nova master: Extend apparmor overrides for custom nova folder https://review.opendev.org/c/openstack/openstack-ansible-os_nova/+/966257 | 16:49 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_ironic master: Remove EL9 compatability https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/966721 | 16:59 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_ironic stable/2025.1: Use correct path for ipxe on EL10 https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/966725 | 17:00 |
| opendevreview | Merged openstack/openstack-ansible-os_aodh master: Switch from wsgi script to wsgi module https://review.opendev.org/c/openstack/openstack-ansible-os_aodh/+/950501 | 17:09 |
| opendevreview | Merged openstack/ansible-role-python_venv_build master: Allow to re-create wheels build venv https://review.opendev.org/c/openstack/ansible-role-python_venv_build/+/966162 | 17:35 |
| opendevreview | Merged openstack/openstack-ansible master: Set ANSIBLE_LOCAL_TEMP to /tmp to prevent remote_tmp warnings https://review.opendev.org/c/openstack/openstack-ansible/+/953218 | 17:43 |
| jrosser | we need to switch ironic ipxe to use ipxe-snponly-x86_64.efi | 18:01 |
| jrosser | thats the answer to unblock that | 18:01 |
| noonedeadpunk | I think I already push a patch? | 18:02 |
| jrosser | ah ok | 18:02 |
| noonedeadpunk | but it's somehow not passing fast | 18:03 |
| noonedeadpunk | https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/950508/6..7/vars/redhat.yml | 18:03 |
| jrosser | it looks like perhaps that should be the default now | 18:03 |
| jrosser | but we can make that a seperate patch | 18:03 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_ironic master: Switch from wsgi script to wsgi module https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/950508 | 18:04 |
| noonedeadpunk | yeah, I made it that way for the sake of "backport" https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/966725 | 18:05 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_ironic master: Remove EL9 compatability https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/966721 | 18:05 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_ironic master: Remove EL9 compatability https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/966721 | 18:05 |
| noonedeadpunk | but eventually, it could be that we have issue just with inspecotr as well | 18:06 |
| noonedeadpunk | I wonder why some jobs are failing, but not otheres | 18:06 |
| noonedeadpunk | like debian one passed | 18:07 |
| jrosser | I wonder if we should strip out inspector | 18:38 |
| jrosser | or if that has to wait due to slurp | 18:39 |
| noonedeadpunk | I think it was dropped by Ironic? or was it? | 18:39 |
| noonedeadpunk | I frankly have no idea what it takes to move to ironic integrated inspector thing | 18:40 |
| noonedeadpunk | as in 2025.2 we can drop deprecated things actually | 18:40 |
| jrosser | I think we just delete the old thing | 18:40 |
| noonedeadpunk | given 2025.1 has features and can be used as upgrade release | 18:40 |
| jrosser | the functionality is now in ironic itself | 18:40 |
| jrosser | but difficulty will be testing the config and functionailty | 18:41 |
| jrosser | we do t use inspector here | 18:41 |
| jrosser | so unless I find time to work on that it’ll be difficult | 18:41 |
| noonedeadpunk | I never got to Iroinc tbh | 18:42 |
| noonedeadpunk | I was just assuming some extra config might be needed for integrated into ironic functionality | 18:48 |
| noonedeadpunk | but I have no idea | 18:48 |
| jrosser | mnaser: did Andrew ask for a release of the containers collection? | 20:00 |
| noonedeadpunk | so we can't use sha? | 20:01 |
| noonedeadpunk | or it's internal-related thing? | 20:01 |
| jrosser | I think it’s tricky because it’s a galaxy dependency from ansible-collection-kubernetes | 20:04 |
| jrosser | which is “version at least <blah>” which o my talks about released versions i think, i.e not master | 20:04 |
| jrosser | *only talks | 20:05 |
| noonedeadpunk | doh | 20:05 |
| noonedeadpunk | and this is a new collection or smth? | 20:05 |
| jrosser | no it’s just that there’s now a fix merged but I’m not sure how we can use that in AIO without a release | 20:06 |
| jrosser | good ideas welcome :) | 20:06 |
| noonedeadpunk | I think we were just using ansible-collection-kubernetes directly,. that's why I've asked if it's a new one | 20:06 |
| noonedeadpunk | nah, if it's galaxy dependency, then no idea | 20:07 |
| noonedeadpunk | I wonder though, if it's stated as version >=, then I'd assume mentioning both in ansible-collection-requirements should work | 20:09 |
| noonedeadpunk | but order does matter | 20:09 |
| noonedeadpunk | so dependencies should be mentioned first | 20:09 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_ironic stable/2025.1: Use correct path for ipxe on EL10 https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/966725 | 20:11 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_ironic master: Switch from wsgi script to wsgi module https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/950508 | 20:12 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_ironic stable/2025.1: Use correct path for ipxe on EL10 https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/966725 | 20:12 |
| noonedeadpunk | btw, about ironic thing - it fails quite trivially: https://zuul.opendev.org/t/openstack/build/c40e02b71a4b421d87843a3be339e711/log/logs/host/ironic-inspector-dnsmasq.service.journal-19-36-11.log.txt | 20:13 |
| noonedeadpunk | I think it's an apparmor actually | 20:13 |
| noonedeadpunk | or maybe not.... | 20:15 |
| noonedeadpunk | as upgrade job passed... | 20:15 |
| noonedeadpunk | but it looks trivial :) | 20:16 |
| jrosser | oh I have patch for apparmor don’t I? | 20:17 |
| noonedeadpunk | right... | 20:17 |
| noonedeadpunk | so we need to squash them at this point it seems... | 20:18 |
| jrosser | that does look familiar | 20:18 |
| noonedeadpunk | https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/951003 | 20:18 |
| noonedeadpunk | so wsgi was on top of it... | 20:18 |
| noonedeadpunk | but now it does not work, as there's no wsgi script anymore | 20:18 |
| noonedeadpunk | so we either need to set ironic back, or squash them I guess | 20:18 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_ironic master: Add apparmor rules for ironic inspector https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/951003 | 20:19 |
| noonedeadpunk | let's see if it's solving the thing... | 20:20 |
| noonedeadpunk | and then will combine | 20:20 |
| noonedeadpunk | *squash | 20:20 |
| jrosser | yeah | 20:20 |
| noonedeadpunk | and upgrade works, as your patch is merged in 2025.1 | 20:20 |
| noonedeadpunk | so makes total sense | 20:20 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_zun master: Use loop label for deb822_repository https://review.opendev.org/c/openstack/openstack-ansible-os_zun/+/959031 | 20:23 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_cinder master: Use loop label for deb822_repository https://review.opendev.org/c/openstack/openstack-ansible-os_cinder/+/959030 | 20:23 |
Generated by irclog2html.py 4.0.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!