15:02:13 <noonedeadpunk> #startmeeting openstack_ansible_meeting
15:02:13 <opendevmeet> Meeting started Tue Oct  7 15:02:13 2025 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:13 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:13 <opendevmeet> The meeting name has been set to 'openstack_ansible_meeting'
15:02:17 <noonedeadpunk> #topic rollcall
15:02:20 <noonedeadpunk> o/
15:02:29 <DavidGomez> o/
15:02:40 <NeilHanlon_> o/
15:03:04 <damiandabrowski> hi!
15:03:08 <noonedeadpunk> courtesy ping: jrosser
15:03:16 <jrosser> o/ hello
15:03:32 <noonedeadpunk> #topic office hours
15:04:02 <noonedeadpunk> so releases
15:04:38 <noonedeadpunk> for 2025.1 I think only rocky left
15:04:42 <noonedeadpunk> #link https://review.opendev.org/q/parentproject:openstack/openstack-ansible+branch:%5Estable/2025.1+status:open+
15:04:47 <noonedeadpunk> *rocky 10 backport
15:05:19 <noonedeadpunk> 2024.2 is waiting for another vote on bump
15:05:31 <noonedeadpunk> and 2024.1 had issues yesterday with Rocky 9 mirrors
15:06:34 <noonedeadpunk> I'm considering to backport https://review.opendev.org/c/openstack/openstack-ansible/+/935362 as well if it's not gonna pass today
15:06:51 <NeilHanlon_> yeah i think that would make sense
15:06:57 <jrosser> yes it looked like a big mess yesterday
15:07:44 <noonedeadpunk> for 2025.2 beta I've pushed freeze https://review.opendev.org/c/openstack/openstack-ansible/+/963189 - will push unfreeze today right after the meeting
15:07:53 <noonedeadpunk> ideally I should have done that yesterday
15:09:04 <noonedeadpunk> I;ve also spotted a copy-paste issue during refactoring of releasing script while doing freeze, so pushed small path for it
15:09:58 <noonedeadpunk> Also run some tests/played with facts gathering yesterday evening. As today we basically are collecting all facts, as ANSIBLE_GATHER_SUBSET not respected anymore
15:10:13 <jrosser> that patch looked basically ok
15:10:14 <noonedeadpunk> got quite a massive patch out for playbooks: https://review.opendev.org/c/openstack/openstack-ansible-plugins/+/963204
15:10:34 <noonedeadpunk> I was thinking if I should simplify it
15:10:44 <noonedeadpunk> and drop `ANSIBLE_GATHER_SUBSET` altogether
15:11:22 <noonedeadpunk> as it could be `gather_subset: "{{ osa_gather_subset | default('!all,min') }}"` instead
15:12:01 <noonedeadpunk> really no reason except some compatability concerns not to do that
15:12:12 <noonedeadpunk> but we're now on non-slurp, so eh
15:12:14 <jrosser> the env var is no longer a thing in actual ansible so yes makes sense to simplify
15:12:16 <NeilHanlon> that all feels rather fine
15:13:09 <noonedeadpunk> I guess my thinking was that I didn't intend to add ansible var in place at the begining, but then realized it might be good to do it with anisble var
15:13:28 <noonedeadpunk> but left env var in place
15:13:54 <noonedeadpunk> I will check on that and I guess simplify it indeed
15:14:35 * noonedeadpunk having several envs which would need to convert from env var to ansible var
15:14:38 * noonedeadpunk is lazy
15:15:03 <noonedeadpunk> ok, we got some progress on pki route I believe
15:15:33 <noonedeadpunk> There were some comments in IRC about the last patch bringing in the new driver from jrosser yesterday
15:15:45 <noonedeadpunk> damiandabrowski: have you seen them and was able to process?
15:15:55 <noonedeadpunk> do we want to discuss them now?
15:15:55 <jrosser> yeah there still is vault_ vars in places
15:16:17 <jrosser> i already left comments on the patch a long time ago
15:16:52 <damiandabrowski> yeah, i think it's related to: https://review.opendev.org/c/openstack/ansible-role-pki/+/948881/comment/ee0404e1_b5ac6aae/
15:17:07 <damiandabrowski> I tried to explain there why I've implemented it like this
15:19:38 <noonedeadpunk> yeah, I hardly dealt with vault so it's hard to judge for me without deeper dive into specifics
15:20:18 <noonedeadpunk> at glance explanation kinda make sense
15:20:53 <noonedeadpunk> btw it's in merge conflict now
15:21:51 <damiandabrowski> yeah, I'll handle it during the evening
15:23:27 <noonedeadpunk> Will put some effort into reviewing this. As I was postponing this last bit for too long
15:24:02 <noonedeadpunk> But I think my main problem is that I'm really not sure what is the most widespread or reasonable pattern of vault usage is
15:24:36 <damiandabrowski> yeah, me neither. Didn't really have any experience with Vault before I started working on this integration
15:25:30 <damiandabrowski> okok, I'm currently adoping sevice roles to recent pki changes we made(type, dynamic permission/owner etc.)
15:26:03 <damiandabrowski> it's going slower than I expected but today I aim to finish patching and start testing it locally
15:26:13 <noonedeadpunk> ok, sounds good then
15:26:29 <noonedeadpunk> Debian 13 - I don't have any updates so far. Was not looking there :(
15:26:32 <damiandabrowski> btw. how can I upload a new patchset to the propsoed change but avoid triggerring CI jobs? Would workflow -1 do the job?
15:26:48 <noonedeadpunk> nope, I don't think you can do this
15:27:12 <noonedeadpunk> as jobs are triggered based of file changes and the trigger is new patchset
15:27:26 <damiandabrowski> ahh okok :/ thanks
15:27:27 <noonedeadpunk> labels do not really matter afaik
15:27:48 <noonedeadpunk> you can make a typo in zuul.d so that they instantly fail :D
15:28:05 <noonedeadpunk> or comment out jobs in project.yaml
15:28:07 <noonedeadpunk> but yeah
15:30:04 <noonedeadpunk> I wanna check on Debian 13 this week, but really no time to be frank, as need to prepare plenty of stuff for the summit
15:35:11 <noonedeadpunk> anything else for today?
15:40:21 <jrosser> sorry fire alarm here - back now
15:40:34 <jrosser> my only objection to the vault_* vars is that they look mandatory
15:40:56 <jrosser> if they defaulted to some sensible value and did not need always to be in the input data to the pki role it would be much cleaner
15:41:40 <jrosser> i also don't see why we can't use signed_by for either backend
15:44:08 <damiandabrowski> hmm, I can define some default values for vault_path and vault_root_ca_path, so they won't have to be explicitly defined
15:45:06 <damiandabrowski> I was thinking about  getting rid of vault_root_ca_path and using signed_by for both backends, but I was afraid it would be too confusing for users
15:45:34 <damiandabrowski> vault_root_ca_path specifies a vault path where the root certificate is stored. It doesn't point to the issuing certificate directly
15:46:09 <damiandabrowski> so that's quite a difference, comparing to how signed_by is used in standalone backend
16:02:02 <noonedeadpunk> #endmeeting