15:00:38 <noonedeadpunk> #startmeeting openstack_ansible_meeting
15:00:38 <opendevmeet> Meeting started Tue Apr 30 15:00:38 2024 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:38 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:38 <opendevmeet> The meeting name has been set to 'openstack_ansible_meeting'
15:00:46 <noonedeadpunk> #topic rollcall
15:00:47 <noonedeadpunk> o/
15:00:48 <jrosser_> o/ hello
15:02:55 <noonedeadpunk> #topic office hours
15:03:57 <noonedeadpunk> So, except weird current issues with tls job, one thing I wanted to discuss, if we should backport https://review.opendev.org/c/openstack/openstack-ansible-os_neutron/+/917192
15:04:13 <noonedeadpunk> as there're mixed feelings about it
15:04:45 <noonedeadpunk> I totally don't like that OVN/OVS will get upgraded on it's own
15:05:00 <noonedeadpunk> but then it won't help on current versions
15:05:06 <jrosser_> did we get any info about why these things were upgraded on a stable branch?
15:05:09 <NeilHanlon> hiya
15:05:11 <noonedeadpunk> and in case of minor upgrade - it might be even worse
15:05:38 <noonedeadpunk> I talked to rdo folks today, and kinda boiled down - neutron core recommended to use latter version of it
15:05:58 <noonedeadpunk> there're some comments in the patch above
15:06:51 <noonedeadpunk> along with RH ticket
15:07:22 <NeilHanlon> thanks for the link.. will look into this a bit more, too
15:07:30 <NeilHanlon> i do think it makes sense to pin versions to not... surprise people
15:07:51 <noonedeadpunk> yeah, true. though if we should backport - is tricky I think
15:08:29 <NeilHanlon> yeah.. i think it is hard to say without knowing how many people are using OSA and targeting RHEL or Rocky
15:08:37 <NeilHanlon> _and_ using distro path
15:08:42 <noonedeadpunk> NeilHanlon: btw, maybe you know... If we install specific version - I assume it means that it won't be auto-upgraded to the newer one?
15:08:55 <NeilHanlon> not on its own, you'd have to also add excludepkgs
15:08:55 <noonedeadpunk> and it's regardless distro path
15:09:08 <NeilHanlon> oh, right.. we install this on source path too.. nvm
15:09:13 <jrosser_> yes like UCA, some things always come from RDO
15:09:17 <jrosser_> even for source installs
15:09:34 * NeilHanlon forgot about that particular nuance
15:09:43 <noonedeadpunk> so I was suggested to use `excludepkgs=*rdo-openvswitch-3.[!2]*,rdo-ovn*-23.0[!9]*,rdo-ovn*-2[!3]*`
15:10:10 * jrosser_ parses
15:10:17 <noonedeadpunk> but then we can potentially do it only for trunk install.. which is the only working one though :D
15:10:29 <NeilHanlon> :D
15:10:47 <NeilHanlon> yeah i think that looks okay... though tbh I didn't know until just now that excludepkgs supported that format
15:11:08 <noonedeadpunk> I never tried it tbh
15:11:21 <noonedeadpunk> But also I somehow thought that it shouldn't be needed...
15:11:49 <NeilHanlon> there is a 'versionlock' plugin which can be used, but by default, dnf/yum will update to the latest version contained in the repository
15:11:50 <noonedeadpunk> as I'd assume that ovn23.09 can not or should not be upgraded to ovn24.03
15:12:01 <noonedeadpunk> as these should be kinda conflicting ones...
15:12:02 <NeilHanlon> let me check how they're configured..
15:13:01 <NeilHanlon> that's a good point though, they are named differently, not just versioned differently
15:13:07 <noonedeadpunk> yeah
15:13:30 <noonedeadpunk> though rdo-ovn-central is named same...
15:13:58 <NeilHanlon> i think it's the rdo-ovn-XXX stuff that does the upgrading
15:14:01 <noonedeadpunk> So I'm very confused, but also got rusty with EL
15:14:07 <noonedeadpunk> yeah
15:14:46 <noonedeadpunk> ok, yes, DNF update does replace things...
15:14:56 <NeilHanlon> https://git.centos.org/rpms/rdo-openvswitch/blob/c9s-sig-cloud-openstack-caracal/f/SPECS/rdo-openvswitch.spec
15:15:03 <noonedeadpunk> https://paste.openstack.org/show/b9hX0edVOSAnxF5LMgxm/
15:15:35 <NeilHanlon> are we targeting D now, or C?
15:15:36 <noonedeadpunk> Provides:   ovn
15:15:39 <noonedeadpunk> C
15:15:44 <noonedeadpunk> or well. B even
15:15:58 <noonedeadpunk> we haven't merged B->C switch yet
15:16:21 <NeilHanlon> yeah it looks like when they do a new version, they make they obsolete the old ones
15:16:38 <noonedeadpunk> ok, so in fact that version pinning doesn't make too much sense as they're upgraded right away
15:16:41 <NeilHanlon> but i don't know why we'd be getting 24.3 now, tbh..
15:16:58 <noonedeadpunk> they backported it to all stable branches as well
15:17:07 <noonedeadpunk> afaik
15:17:27 <NeilHanlon> right but I don't see ovn24.03 in their rdo-openvswitch package until D
15:17:40 <NeilHanlon> https://git.centos.org/rpms/rdo-openvswitch/blob/c9s-sig-cloud-openstack-dalmatian/f/SPECS/rdo-openvswitch.spec#_9
15:17:43 <noonedeadpunk> ah, it's not released yet
15:17:59 <noonedeadpunk> but it's already present in trunk
15:18:05 * NeilHanlon confused
15:18:19 <noonedeadpunk> we don't install it through cloudsig
15:18:26 <NeilHanlon> ah
15:18:45 <NeilHanlon> i forgot how this RDO/cloud sig stuff works
15:18:50 <NeilHanlon> but i am remembering now
15:20:39 <noonedeadpunk> so we just fetch https://trunk.rdoproject.org/centos9-bobcat/current/delorean.repo
15:20:48 <noonedeadpunk> and place under yum.repos.d
15:21:10 <noonedeadpunk> which is pre-cloudsig release kinda
15:21:45 <noonedeadpunk> would make sense to do cloudsig package install ofc on production, BUT, they do also ship tons of dependencies
15:21:58 <noonedeadpunk> like rabbitmq, ceph, messaging repos, etc
15:22:11 <noonedeadpunk> so really smth we'd prefer not to have
15:23:00 <noonedeadpunk> so rdo-ovn replacing ovn23.09.x86_64 really neglects any pinning attempt kinda...
15:23:34 <noonedeadpunk> NeilHanlon: what would you suggest?:)
15:23:44 <NeilHanlon> vodka
15:23:47 <noonedeadpunk> hahaha
15:24:01 <NeilHanlon> I will follow up with amorlej and see what we can come up with :D
15:24:12 <noonedeadpunk> ok, awesome, thanks for that
15:24:16 * NeilHanlon bows
15:24:35 <noonedeadpunk> as in fact I'm a bit lost in options as it all looks a bit confusing
15:25:06 <NeilHanlon> yeah, some of this requires a Doctorate in RPMology
15:25:21 <noonedeadpunk> as a matter of fact I know for sure that such upgrade between releases is executed and user is unaware - may lead to all kinds of weird things and downtimes
15:25:56 <noonedeadpunk> like in APT I would do just pin to version and forget about that I guess...
15:26:23 <noonedeadpunk> though UCA close to never does like this...
15:28:50 <noonedeadpunk> ok
15:29:10 <noonedeadpunk> regarding TLS failure - so far it's very weird. Though reproducible, which is nice
15:31:08 <jrosser_> do we have an LXC equivalent job?
15:31:17 <noonedeadpunk> no, I don't think so
15:31:28 <jrosser_> hmm i might try that too
15:31:42 <jrosser_> so far i don't find anything
15:31:52 <noonedeadpunk> if I was to guess - I think it would work
15:32:09 <jrosser_> it is a shame that the meta task does not seem to print any useful output
15:32:24 <jrosser_> not OK / Changed / Skipped, just nothing
15:32:44 <noonedeadpunk> as we do restart container
15:32:49 <jrosser_> which does make me wonder if it actually does anything
15:35:03 <noonedeadpunk> I kinda think if we should instead pass that somehow in python_venv_build
15:35:38 <jrosser_> the CA bundle location?
15:36:12 <noonedeadpunk> yeah
15:36:17 <jrosser_> i was looking at the pip module source and it uses module_utils.run_command
15:36:23 <noonedeadpunk> as we do same for uwsgi
15:36:31 <jrosser_> which kind of a long way from being command/shell module tbh
15:36:37 <noonedeadpunk> https://opendev.org/openstack/ansible-role-uwsgi/src/branch/master/vars/debian.yml#L36
15:37:22 <noonedeadpunk> but then I did logout from VM - login again and it worked
15:37:31 <noonedeadpunk> (as long as env was reloaded)
15:37:51 <jrosser_> i am just trying a second run of gate-check-commit in the same shell again
15:38:04 <jrosser_> but ~30mins between tries
15:40:12 <noonedeadpunk> are env cached in facts?
15:41:03 <jrosser_> they are
15:41:54 <jrosser_> we could perhaps use ansible_env to set environment: on the task
15:42:04 <jrosser_> which is pretty wierd construct tbh
15:42:58 <noonedeadpunk> yeah, and have risk of overriding thing
15:43:08 <jrosser_> huh now it worked on my second run of gate-check-commit
15:43:11 <jrosser_> no logout
15:43:26 <noonedeadpunk> though I was thinking as if instead reset_connection correct thing would be to clear_facts
15:44:07 <jrosser_> i would have been much longer than controlpersist timeout there
15:44:13 <jrosser_> between first and second run
15:51:38 <jrosser_> this looks massively out of date https://opendev.org/openstack/openstack-ansible/src/branch/master/tests/roles/bootstrap-host/templates/user_variables.aio.yml.j2#L283
15:52:15 <noonedeadpunk> I found this today: https://opendev.org/openstack/openstack-ansible-openstack_hosts/src/branch/master/vars/redhat-9.yml#L73
15:53:08 <noonedeadpunk> btw, I will be on OpenInfra Days in Sweden next week on Tuesday
15:53:28 <noonedeadpunk> which means I won't be around on Monday and Wednesday either...
15:54:10 <NeilHanlon> lol at openstack queens
15:54:26 <NeilHanlon> i can run next week, if we still want to meet
15:54:42 <noonedeadpunk> Damian would be also away just in case...
15:55:09 <noonedeadpunk> so potentially makes sense to skip, despite we're coming very close to the release due date
15:55:30 <noonedeadpunk> Which is Jun 03
15:56:26 <noonedeadpunk> basically in a month...
15:58:04 <jrosser_> hmm ok so we need to make sure we prioritise
15:58:45 <jrosser_> and just for more /o\ i think there will be zed moved to unmaintained
15:59:02 <jrosser_> still need to finish victoria which is close to working again
16:00:04 <opendevreview> Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Add Tempest test for OVN Octavia driver  https://review.opendev.org/c/openstack/openstack-ansible/+/916872
16:00:42 <noonedeadpunk> well, I've tried to add ovn provider testing for octavia ^
16:01:01 <noonedeadpunk> then capi I think is pretty much ready
16:01:42 <jrosser_> there is messaging improvement stuff on all roles (?) too
16:01:43 <noonedeadpunk> for skyline 1 path about yarn left: https://review.opendev.org/c/openstack/openstack-ansible-os_skyline/+/914405
16:01:46 <noonedeadpunk> yeah
16:02:01 <noonedeadpunk> this one I aim to finish pushing by end of the week
16:02:13 <noonedeadpunk> I paused just because gates are borked anyway...
16:03:16 <noonedeadpunk> and, ovn-bgp-agent is the last thing I guess?
16:03:40 <noonedeadpunk> ah, and we're out of time
16:03:44 <noonedeadpunk> #endmeeting