15:00:03 <noonedeadpunk> #startmeeting openstack_ansible_meeting
15:00:03 <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:03 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:03 <opendevmeet> The meeting name has been set to 'openstack_ansible_meeting'
15:00:07 <noonedeadpunk> #topic rollcall
15:00:26 <damiandabrowski> hi!
15:00:33 <noonedeadpunk> o/
15:02:07 <noonedeadpunk> courtesy ping janno
15:02:09 <noonedeadpunk> oops
15:02:11 <noonedeadpunk> jrosser:
15:03:16 <damiandabrowski> Would be nice to discuss two things regarding https://review.opendev.org/c/openstack/ansible-role-pki/+/948881
15:03:27 <damiandabrowski> 1. change default vault path names `pki` -> `pki_root` (for path containing pki root)
15:03:30 <damiandabrowski> `pki_int` -> `pki` (for path containing intermediate cert and all service certs)
15:03:39 <damiandabrowski> Originally suggested by noonedeadpunk. I'm fine with this.
15:03:49 <damiandabrowski> 2. Rename `vault_root_ca_path` to `signed_by`
15:03:53 <damiandabrowski> we can rename vault_root_ca_path to signed_by
15:03:57 <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:04:03 <damiandabrowski> but maybe you don't see it as a problem
15:04:08 <damiandabrowski> and its name - vault_root_ca_path was more explicit that this variable is about the vault path
15:04:12 <damiandabrowski> so that was the reason why I implemented it that way, but I don't have a strong opinion here.
15:04:25 <damiandabrowski> If you think it's better to rename it to signed_by, I'm okay with this
15:05:00 <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:06:23 <noonedeadpunk> regarding pki / pki_root - I just find current example being a bit unobvious to read
15:06:52 <damiandabrowski> yeah, you may be right about that
15:07:02 <noonedeadpunk> but using `signed_by` would also solve this ambiguity for me
15:07:39 <noonedeadpunk> so it's matter of just agreeing on some option
15:07:59 <noonedeadpunk> but I'm not sure if that what jrosser meant when mentioned signed_by
15:08:36 <damiandabrowski> okay, so maybe lets wait for his opinion until we make some decision about 2.
15:08:49 <damiandabrowski> and regarding 1. - I'll fix it tomorrow
15:09:02 <noonedeadpunk> But I think second thing we need to sort out, is actually aboput support for debian 12
15:09:12 <damiandabrowski> ah yes...
15:09:21 <noonedeadpunk> and hcl requirement (or how it's called)
15:09:29 <damiandabrowski> hvac :D
15:09:49 <noonedeadpunk> right
15:10:22 <damiandabrowski> so yes, TLDR; if we want to support debian 12 we need to install hvac with pip using --break-system-packages
15:10:36 <damiandabrowski> (debian 12 has too old hvac version in its repositories)
15:10:41 <noonedeadpunk> #link https://review.opendev.org/c/openstack/openstack-ansible/+/948888/10/requirements.txt
15:10:54 <noonedeadpunk> I don't like this ^ at all
15:11:44 <damiandabrowski> is there any other place where we can place this requirement?
15:12:20 <noonedeadpunk> well. we can do multiple things I guess...
15:13:32 <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:55 <noonedeadpunk> 2. Add documentation/alert/reno that the following module is requiredspecifically for debian 12
15:15:08 <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:17:09 <noonedeadpunk> for 1. we can ofc modify the bootstrap script or smth....
15:17:19 <damiandabrowski> just to clarify: this package is required for all OS
15:18:00 <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:06 <damiandabrowski> which is enough
15:18:34 <NeilHanlon> o/ sorry, triple booked today
15:18:46 <noonedeadpunk> and for 2. we can document adding the module to openstack_deploy/user-ansible-venv-requirements.txt
15:19:24 <damiandabrowski> but maybe let's start from scratch. Why do you think requirements.txt is a bad place for it? :D
15:19:55 <damiandabrowski> requirements.txt is used when building /opt/ansible-runtime venv, so it looked like a valid place for it
15:20:45 <jrosser> o/ sorry i'm late
15:23:01 <noonedeadpunk> no worries - there's a question to you above I believe
15:23:09 <noonedeadpunk> while I'm thinking on hvac :)
15:23:11 <jrosser> for signed_by it seemed that using the name of the root to sign the intermediate is quite "obvious"
15:23:22 <jrosser> and also for which intermediate signs a cert
15:23:49 <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:49 <noonedeadpunk> I think the problem there, is that you can't actually select a root or intermediate directly
15:24:19 <noonedeadpunk> as intermediate should be stored in the same place as certs I assume
15:24:24 <jrosser> you do it via the mount point?
15:24:29 <noonedeadpunk> yeah
15:24:57 <noonedeadpunk> so same mount point for intermediate as the cert, same or different for root
15:25:08 <jrosser> right, so its like `{{ vault_mount_point_prefix }}/{{ item.signed_by }}` or something
15:25:33 <damiandabrowski> i tried to explain it in this diagram: https://ibb.co/6R3rGYBC
15:25:36 <jrosser> i am just wanting to keep the data abstract in the input to the role
15:25:41 <noonedeadpunk> I have no idea if you can do it like that though
15:25:57 <damiandabrowski> we don't point to any specific issuer
15:26:11 <noonedeadpunk> as from what I got, you're limited only to `vault_mount_point_prefix` - what you can actually define
15:26:19 <damiandabrowski> yeah
15:26:21 <jrosser> oh right
15:26:37 <noonedeadpunk> so it's {{ item.signed_by }}/some/other/api/call
15:27:45 <jrosser> well regardless, if we can keep the input data not being shaped by the implementation in vault, that would be excellent
15:30:00 <noonedeadpunk> the problem here, is that it feels, that for intermediate you still need to introduce smth
15:30:42 <noonedeadpunk> for standalone we were using just `name` to identify the path
15:30:55 <jrosser> indeed
15:30:56 <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:58 <noonedeadpunk> I'm not sure this is gonna be applicable for vault
15:31:05 <damiandabrowski> at least I couldn't find a way to achieve this
15:31:14 <noonedeadpunk> and then root also needs some "signed_by" which makes limited sense
15:31:56 <noonedeadpunk> and then certs themselves don't have any choice
15:32:11 <noonedeadpunk> as they will be signed with whatever available on their mount point
15:32:23 <noonedeadpunk> But we can call that `signed_by` though
15:32:40 <noonedeadpunk> it's a matter of relation kinda.
15:33:03 <noonedeadpunk> sec
15:34:19 <noonedeadpunk> https://paste.openstack.org/show/bKHPlUr8lddmPwa1b1XF/
15:34:22 <noonedeadpunk> smth like that?
15:35:00 <damiandabrowski> yeah, we can do that
15:35:38 <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:36:09 <noonedeadpunk> Ie - we can use repo or utility containers even for pki_setup_host and vault
15:36:49 <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:37:39 <noonedeadpunk> so installing a package sounds like a way easier thing to do
15:37:59 <damiandabrowski> ahh right, makes sense
15:38:11 <noonedeadpunk> but sure - we can actually spawn a separate venv on the pki_setup_host with hvac
15:39:01 <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:20 <noonedeadpunk> it's pinned by u-c, but yeah
15:39:25 <noonedeadpunk> so "control" :)
15:39:52 <noonedeadpunk> ok, so are we in agreement about the paste above?
15:39:53 <damiandabrowski> but we want to spawn a separate venv only for debian12, do I get it right?
15:40:06 <noonedeadpunk> it makes sense to do it universally then?
15:40:11 <noonedeadpunk> Dunno
15:40:47 <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:50 <damiandabrowski> when we will drop support for debian 12?
15:41:13 <noonedeadpunk> we have to carry it through 2026.1 at this point
15:41:19 <noonedeadpunk> so early 2026.2
15:41:23 <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:39 <noonedeadpunk> well, reason is "control" of versions
15:42:08 <damiandabrowski> okay, I'll try implement this
15:42:33 <noonedeadpunk> it's possible that we get into this versioning situation again in the future
15:42:48 <noonedeadpunk> when we'd need to implement smth newer, which some os does not support
15:43:10 <damiandabrowski> yeah...ack
15:43:13 <noonedeadpunk> so it could be good to have in general, even for standalone backend, as jrosser mentioned
15:44:19 <noonedeadpunk> damiandabrowski: btw I've also spotted that you don;t use pki_setup_host_python_interpreter anywhere for the vault code
15:44:31 <noonedeadpunk> * just spotted
15:45:40 <damiandabrowski> ack, I'll look into that
15:46:36 <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:43 <noonedeadpunk> but Ironic still feeling bad
15:47:12 <jrosser> oh theres a depends on is there
15:47:17 <damiandabrowski> sorry guys, I'll drop off :D it's public holiday in Poland, I just joined to discuss PKI stuff
15:47:30 <noonedeadpunk> ah, sure, take care
15:47:58 <jrosser> we also still need to remove inspector?
15:48:24 <noonedeadpunk> It fails on `msg: Source /usr/share/ipxe/ipxe-x86_64.efi not found` for EL10
15:48:39 <jrosser> errrr
15:48:39 <noonedeadpunk> and for ubuntu on tempest tests
15:48:43 <jrosser> which parch are we looking at
15:48:46 <jrosser> *patch
15:48:51 <noonedeadpunk> https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/951003
15:49:51 <noonedeadpunk> But it could be we need to break relation chain
15:50:05 <noonedeadpunk> and rebase https://review.opendev.org/c/openstack/openstack-ansible-os_ironic/+/950508 on top of master
15:50:09 <noonedeadpunk> and add depends-in
15:50:13 <noonedeadpunk> *depends-on
15:50:28 <noonedeadpunk> right...
15:50:33 <jrosser> ironic service is down i think
15:50:49 <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:51:02 <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:40 <noonedeadpunk> it won't solve this one though: https://zuul.opendev.org/t/openstack/build/04300573a8434d26935a36fcaccd9bc7/log/job-output.txt#14411-14415
15:52:01 <noonedeadpunk> have no idea what provides this one
15:53:41 <jrosser> hmm https://opendev.org/openstack/ironic/src/branch/master/doc/source/install/configure-pxe.rst#L298
15:54:06 <jrosser> oh unhelpful link, but that doesnt help
15:54:30 <noonedeadpunk> will check if might be just the path is different
15:55:28 <jrosser> yeah
15:55:28 <noonedeadpunk> I think almost the last think - what do you think about uv patch here:
15:55:36 <jrosser> it didnt fail at installing `grub2-efi-x64`
15:55:43 <jrosser> so the firmware should be somewhere
15:55:55 <noonedeadpunk> #link https://review.opendev.org/c/openstack/openstack-ansible/+/966409
15:56:14 <jrosser> i thought this was good
15:56:28 <jrosser> but we have to be careful of how we test this, and if we decide to change the default
15:56:37 <noonedeadpunk> the problem is that uv has no way of building wheels so far
15:57:13 <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:28 <noonedeadpunk> but now what I was doing, is installing uv inside of the existing venv
15:57:43 <noonedeadpunk> as it's installation process is not really easy outside of venv
15:58:40 <jrosser> hah if python_venv_build needs its own venv with pip to install uv to then make a venv
15:58:44 <jrosser> thats quite something
15:59:25 <jrosser> theres a danger of adding a *lot* of tasks that ensure that is present on * places
15:59:43 <noonedeadpunk> well, so I made uv to operate inside already created venv by `python3 -m venv`
16:00:13 <noonedeadpunk> and then instead of upgrading pip in that venv, I'm installing uv there
16:00:24 <noonedeadpunk> but we're not benefitting from venv creation process
16:00:55 <noonedeadpunk> so uv usage is really minimal right now....
16:01:22 <noonedeadpunk> and about testing - yes, sure, I was thinking to add molecule coverage to the role
16:03:03 <jrosser> it could also be that the ever-present pip resolver errors happen in different ways
16:03:15 <jrosser> i think thats my bigger concern that we need to be using that one way, or the other
16:03:52 <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:04:04 <jrosser> making it switchable gives 2x (currently) the options for people to try and us to debug
16:04:31 <noonedeadpunk> but if we can save ~5mins on each CI job....
16:05:24 <noonedeadpunk> but indeed I get the concern...
16:05:50 <jrosser> yeah, we need, imho, to be comfortable enough to commit to "now we use uv" rather than make another tunable
16:06:02 <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:22 <noonedeadpunk> well, we can't for wheels at least
16:06:37 <noonedeadpunk> as it does not support building things for requirements, like pip does
16:06:48 <noonedeadpunk> it can build only wheels for "current" project
16:07:15 <noonedeadpunk> maybe we can skip wheels part with uv as a whole, dunno
16:07:38 <noonedeadpunk> as it does some efficient local caching...
16:08:01 <noonedeadpunk> and then drop whole repo part....
16:08:06 <noonedeadpunk> but I'm not sure about that
16:08:46 <noonedeadpunk> #endmeeting