15:02:00 <noonedeadpunk> #startmeeting openstack_ansible_meeting
15:02:00 <opendevmeet> Meeting started Tue Feb 20 15:02:00 2024 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:00 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:00 <opendevmeet> The meeting name has been set to 'openstack_ansible_meeting'
15:02:06 <noonedeadpunk> #topic roll call
15:02:10 <mgariepy> hey
15:02:12 <noonedeadpunk> o/ hey everyone
15:04:39 <NeilHanlon> o/
15:04:59 <NeilHanlon> running a bit late will be at my computer in 10
15:11:18 <noonedeadpunk> #topic office hours
15:11:25 <noonedeadpunk> Frankly speaking - I don't have much
15:11:29 <NeilHanlon> (made it)
15:11:44 <noonedeadpunk> We had really teriffic bug fighting day
15:11:54 <noonedeadpunk> super nice to see bugs fitting just 2 pages :)
15:12:07 <NeilHanlon> :D super sorry i wasn't able to participate.. that was.. a day
15:12:10 <noonedeadpunk> hopefully soonish will be able to iterate over ones on the etherpad
15:12:36 <NeilHanlon> great job everyone
15:12:47 <noonedeadpunk> other then that - I failed to add us access to unmaintained branches. And Brians ML really confused me a lot
15:14:20 * noonedeadpunk looking through the review board
15:14:54 <noonedeadpunk> some backports are still pending to merge: https://review.opendev.org/q/parentproject:openstack/openstack-ansible+branch:%5Estable/.*+status:open+
15:15:02 <noonedeadpunk> or pending for recheck...
15:17:40 <NeilHanlon> i will poke at those in a bit
15:20:47 <noonedeadpunk> I guess once most important land - it should be time for another point releases and first minor release for 2023.2
15:20:58 <noonedeadpunk> it was never _that_ late frankly speaking...
15:21:14 <noonedeadpunk> The only known issue for upgrade might be missing rabbitmq flags actually
15:21:26 <noonedeadpunk> But they should be covered in OS upgrade right now at least...
15:21:52 <noonedeadpunk> We also had quite good progress on landing capi stuff
15:27:39 <opendevreview> Merged openstack/openstack-ansible stable/2023.1: [doc] Remove guidance to drain RMQ which can result in failures  https://review.opendev.org/c/openstack/openstack-ansible/+/908801
15:28:53 <noonedeadpunk> but it feels that other goals for the release might not be met :(
15:29:17 <noonedeadpunk> ie - proxysql, incus, pki + vault integration
15:29:38 <noonedeadpunk> mainly because of me having hard times lately with ENOTIME
15:29:48 <jrosser> o/ sorry in too many meetings, here now
15:32:32 <noonedeadpunk> Though, we can potentially add some things for OVN
15:32:39 <noonedeadpunk> like vpnaas support
15:32:54 <jrosser> magnum stuff too
15:33:05 <noonedeadpunk> Ah, Octavia OVN support was in our list as well, and I think this patch is not fair enough to go
15:33:08 <noonedeadpunk> https://review.opendev.org/c/openstack/openstack-ansible-os_octavia/+/868462
15:33:08 <jrosser> feels like endless yak shaving right now with that :/
15:33:55 <noonedeadpunk> ugh, magnum actually fails with openstack_resources role on upgrade
15:34:06 <noonedeadpunk> I was never able to really reproduce the thing :(
15:34:48 <noonedeadpunk> it's not that I was able to spend enough time though :( but it was tricky to do so
15:35:12 <noonedeadpunk> maybe now when openstack_resources landed, it will be easier to do...
15:36:29 <jrosser> there is also still the patch for OVN + octavia, regardless of the ovn provider
15:36:35 <jrosser> thats totally broken right now in AIO
15:36:48 <noonedeadpunk> oh, btw. all fixes for quorum landed to oslo.messaging: https://review.opendev.org/q/topic:%22bug-2031497%22
15:37:02 <noonedeadpunk> yes, true.
15:37:09 <noonedeadpunk> but it kinda works out of AIO
15:37:25 <jrosser> that is pretty much OK except that the patch needs to also work for !debians
15:37:49 <jrosser> i think it's ovs installation during bootstrap_host now working on centos/rocky
15:37:54 <jrosser> *not working
15:38:18 <noonedeadpunk> so... neutron was not failing on that
15:38:49 <noonedeadpunk> like this passed today: https://review.opendev.org/c/openstack/openstack-ansible-os_neutron/+/908341?tab=change-view-tab-header-zuul-results-summary
15:39:02 <jrosser> this https://review.opendev.org/c/openstack/openstack-ansible/+/894811
15:39:08 <noonedeadpunk> no idea what it testing though
15:39:17 <jrosser> the lbaas network is just not a thing currently in AIO
15:39:26 <jrosser> like totally broken
15:40:20 <noonedeadpunk> I guess we'd need a SIG for openvswitch?
15:40:26 <noonedeadpunk> It's not present in default repos
15:41:10 <noonedeadpunk> But also... It's weird we need to create ovs bridges in advance for octavia
15:41:28 <jrosser> we need to plumb the container bridges into the provider network
15:41:29 <noonedeadpunk> Shouldn't defining neutron_provider_networks do the trick?
15:41:53 <jrosser> well i'm not sure, this is why i asked jamesdenton and the result was that patch
15:41:59 <noonedeadpunk> https://opendev.org/openstack/openstack-ansible-os_neutron/src/branch/master/tasks/providers/ovs_config.yml#L16
15:42:30 <noonedeadpunk> I think this runs both for OVS and OVN... But like not 100% sure. >90 though
15:43:02 <noonedeadpunk> ok, for OVN it's here: https://opendev.org/openstack/openstack-ansible-os_neutron/src/branch/master/tasks/providers/setup_ovs_ovn.yml#L64-L86
15:43:06 <noonedeadpunk> but kinda same thing?
15:43:19 <jrosser> well also octavia role runs after neutron
15:43:27 <noonedeadpunk> yeah
15:43:30 <jrosser> so also i wonder if there is chicken/egg trouble
15:43:42 <jrosser> as there is network stuff defined in the octavia role
15:43:43 <noonedeadpunk> but if it's after - it should be fine...
15:44:03 <noonedeadpunk> and yes, octavia does create a neutron networks
15:44:21 <opendevreview> Merged openstack/openstack-ansible stable/zed: [doc] Remove guidance to drain RMQ which can result in failures  https://review.opendev.org/c/openstack/openstack-ansible/+/908802
15:44:23 <noonedeadpunk> so I think defining decent neutron_provider_networks should be jsut fine
15:44:28 <jrosser> anyway this is pretty big deal, i think it means we're not really testing octavia properly right now
15:45:26 <noonedeadpunk> I can try to look into that actually and compary with what I have in our full-scale OVN sandbox
15:46:02 <jrosser> that would be very helpful, i don't have anything like that as reference
15:56:35 <noonedeadpunk> ok, good
15:57:07 <noonedeadpunk> as frankly for sandbox it worked really out of the box once I've defined proper mappings.
15:57:53 <noonedeadpunk> just matter of doing that through provider_networks in openstack_user_config... But I guess at worst we can just define neutron_provider_networks in user_vars_octavia or smth
15:58:36 <admin1> the octavia  patch just worked out of the box .. and everyone copied it over as a procedure, so until now  no one tested it like you guys :)
15:59:44 <admin1> i meant since br-vxlan br-vlan etc  were necessary to be defined, even though br-lbaas was just a tag/patch on br-vlan, it took itself as a procedure
15:59:49 <noonedeadpunk> admin1: well. I made quite some clean-up of it, as there were never used variables added
15:59:57 <admin1> and its not a biggie also that people complained
16:00:14 <noonedeadpunk> but yeah
16:00:17 <admin1> out of dozens of steps to prepare the server and netplan, it became 1 more block of code
16:00:30 <admin1> its like don't fix unless broken type of procedure :)
16:01:02 <admin1> though an automated one will be nice as well .. no more /etc/rc.local stuff
16:01:33 <noonedeadpunk> #endmeeting