15:01:27 <noonedeadpunk> #startmeeting openstack_ansible_meeting
15:01:27 <opendevmeet> Meeting started Tue Mar 14 15:01:27 2023 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:01:27 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:27 <opendevmeet> The meeting name has been set to 'openstack_ansible_meeting'
15:01:32 <noonedeadpunk> #topic rollcall
15:01:34 <noonedeadpunk> o/
15:01:45 <damiandabrowski> hi!
15:02:36 <jrosser> o/ hello
15:03:22 <noonedeadpunk> #topic office hours
15:03:44 <noonedeadpunk> First I'd love to ask for some reviews of backports to Xena https://review.opendev.org/q/parentproject:openstack/openstack-ansible+branch:%255Estable/xena+status:open
15:04:32 <noonedeadpunk> unfortunatelly Zed and Yoga bumps didn't passed yet
15:05:07 <noonedeadpunk> As agreed, I've set upgrade jobs to NV from W to X
15:05:07 <damiandabrowski> okok, i'll spent some time on reviews today and tomorrow
15:08:46 <noonedeadpunk> Regarding upcoming PTG - I've just booked the room for us
15:08:50 <noonedeadpunk> #link https://ptg.opendev.org/ptg.html
15:09:25 <noonedeadpunk> I will send ML with info right after the meeting
15:10:49 <noonedeadpunk> Regarding our haproxy topic - I didn't have chance to iterate on that or review map patches thoroughly but they looked quite good to me and made total sense
15:13:35 <noonedeadpunk> So I overall had not much time last week.
15:14:38 <jrosser> i made a patch for the mysql reduced memory settings
15:14:43 <jrosser> no idea if it worked :)
15:14:54 <noonedeadpunk> yeah....
15:15:00 <jrosser> then got down the rabbit hole of why there is no log for my.cnf
15:15:09 <noonedeadpunk> dstat is ot running due to some my mistake...
15:15:33 <noonedeadpunk> For some reason each change I made either makes it run every time, even outside of CI or do not run at all...
15:24:48 <noonedeadpunk> but I don't have pretty much to say to be frank - a lot of work with haproxy that we should land at least...
15:24:58 <jrosser> so for haproxy it sounds again like we need to revisit the approach to agree what we do next
15:25:22 <jrosser> becasue if there is some agreement we could start to merge the things which don't change master
15:25:28 <jrosser> *change the behaviour
15:26:10 <jrosser> unfortunately rebasing the previous patches on top of my new work is going to be pretty difficult
15:28:04 <damiandabrowski> "so for haproxy it sounds again like we need to revisit the approach to agree what we do next" - are you talking about "temporary groups" vs. classic loop or something else?
15:28:18 <damiandabrowski> sorry it's my first day after vacation so I'm still catching up
15:29:01 <noonedeadpunk> It's about map support?
15:30:05 <jrosser> i mean that the map support i did should take away a bunch of complexity from the current separated config patches
15:30:25 <jrosser> but they will need rebasing in order to do that (and ideally splitting further into smaller patches)
15:30:49 <jrosser> i saw that currently one giant patch combines separating the config and also putting in the hooks to enable https backends
15:30:52 <noonedeadpunk> Well, splitting might be tought there
15:31:09 <noonedeadpunk> well, yes, that part can be :)
15:31:21 <jrosser> and https backend for repo server changes is currently breaking the splitting out part
15:31:28 <noonedeadpunk> But it still will be gigantic as we need to move things to playbooks
15:31:28 <damiandabrowski> jrosser: that's right, map support will simplify my patches
15:31:36 <noonedeadpunk> and from group_var
15:32:07 <noonedeadpunk> I;d propose to leave repo_server alone with https coverage right now
15:32:07 <damiandabrowski> not sure if we can split changes even more but at least I will try
15:32:12 <jrosser> and the LE CI job feels maybe heavyweight way to validate that
15:32:40 <jrosser> so i was not sure if that was a good idea or not, but we have no test coverage of that at all and pretty good chance to break it
15:33:29 <damiandabrowski> noonedeadpunk: with or without https coverage?
15:33:50 <damiandabrowski> regarding repo_server, I've described the issue before my vacation: https://review.opendev.org/c/openstack/openstack-ansible/+/876426/comments/8cde87f7_169011a5
15:33:57 <damiandabrowski> i'll dig into this tomorrow
15:34:15 <jrosser> yes but there is no reason at all to bring new https backends in with the same patch that splits out the config
15:34:39 <noonedeadpunk> damiandabrowski: without for now, as it's not really required and we don't have repo frontend covered with TLS as of today
15:34:57 <noonedeadpunk> So I'd leave repo_server after we do all major changes and cover services
15:35:34 <damiandabrowski> so maybe do it like this: if I won't be able to get it working tomorrow, I'll move this change to the top of relation chain, ok?
15:35:54 <jrosser> please just move around the existing config blocks for the services without changing them
15:36:10 <noonedeadpunk> ++
15:36:20 <noonedeadpunk> and all changes do in separate pachsets
15:37:36 <noonedeadpunk> So let's focus on 1. adopting maps 2. splitting configs to respect group_vars and service configurations on playbook level
15:38:07 <noonedeadpunk> then we will be able to look into tls with more narrow scope
15:38:43 <damiandabrowski> "splitting configs to respect group_vars and service configurations on playbook level" what config are we going to split?
15:38:54 <damiandabrowski> configs*
15:39:22 <noonedeadpunk> service configruation. Meaning - moving them from group_vars/haproxy to group_vars/service as you did
15:39:30 <noonedeadpunk> But not changing them at the same patch
15:39:56 <damiandabrowski> ah ok, got it
15:40:24 <noonedeadpunk> and including common task. basically https://review.opendev.org/c/openstack/openstack-ansible/+/871189/
15:40:44 <jrosser> and on top of this https://review.opendev.org/c/openstack/openstack-ansible/+/876851
15:40:59 <noonedeadpunk> But do changes to backends as follow-up, to be able to see what we're chaning, as otherwise it's just all green
15:42:50 <noonedeadpunk> regarding https://review.opendev.org/c/openstack/openstack-ansible/+/876639 - should we add the same job to haproxy as well? Or you did that already?
15:44:10 <jrosser> i added it to `openstack-ansible-deploy-infra_lxc-jobs`
15:44:35 <jrosser> ok yes that should run for haproxy too
15:46:37 <noonedeadpunk> aha, yes, you're right here
15:47:20 <noonedeadpunk> I was just thinking about different condition here https://review.opendev.org/c/openstack/openstack-ansible/+/876637/6/tests/roles/bootstrap-host/tasks/main.yml
15:47:39 <noonedeadpunk> like "'stepca' in bootstrap_host_scenarios_expanded or 'haproxy' in bootstrap_host_scenarios_expanded"
15:48:07 <noonedeadpunk> but yeah, adding to infra_lxc maybe even better
15:48:18 <noonedeadpunk> as another job
15:50:33 <noonedeadpunk> it's quite awkward that we need to generate self-signed to install let's encrypt....
15:50:39 <noonedeadpunk> anyway
15:51:05 <noonedeadpunk> That looks quite good to me. Are these stepca series waiting for anything before being ready for review?
15:54:59 <noonedeadpunk> oh, well. except missing rpm part :)
15:55:13 <noonedeadpunk> seems that they do have packages
15:58:18 <jrosser> no i think the stepca patches are reasonable and can be reviewed
15:58:43 <jrosser> for a real role to install it you'd want more idempotency but i was thinking not to make it too complicated just for AIO purposes
15:59:38 <jrosser> 'haproxy' in bootstrap_host_scenarios_expanded" would run it for all haproxy jobs so i think thats not what we want
15:59:44 <noonedeadpunk> I don't think bootstrap-aio is idemptent as of today
15:59:50 <jrosser> as also need to test the normal code path as well
16:00:06 <noonedeadpunk> yeah, I"ve realized that after wrote
16:04:23 <noonedeadpunk> #endmeeting