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