15:02:45 <noonedeadpunk> #startmeeting openstack_ansible_meeting
15:02:45 <opendevmeet> Meeting started Tue Dec  9 15:02:45 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:45 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:02:45 <opendevmeet> The meeting name has been set to 'openstack_ansible_meeting'
15:02:50 <noonedeadpunk> #topic rollcall
15:04:26 <noonedeadpunk> o/
15:04:54 <jrosser> o/ hello
15:05:58 <NeilHanlon> o/
15:09:08 <noonedeadpunk> #topic office hours
15:09:20 <noonedeadpunk> last week we got finally branched 2025.2
15:09:33 <noonedeadpunk> and now we're a week in delay with flamingo release
15:10:00 <noonedeadpunk> Huge cohntributing factor to the delay was rotation of rabbitmq repos, which we missed
15:10:08 <noonedeadpunk> and learned about once it has happened :(
15:10:21 <jrosser> were we late to move to an updated version?
15:13:06 <noonedeadpunk> I think they've announced about removal of ppa1 in advance
15:13:15 <noonedeadpunk> but I missed that completely
15:13:58 <noonedeadpunk> anyway, we have what we have, and hopefully backports will land today
15:14:12 <noonedeadpunk> then we will be able to produce rc2 tomorrow...
15:14:52 <noonedeadpunk> I have also proposed a patch to start tracking master again: https://review.opendev.org/c/openstack/openstack-ansible/+/970128
15:15:05 <noonedeadpunk> and there is one for EOM-ing 2024.1: https://review.opendev.org/c/openstack/openstack-ansible/+/966174
15:15:47 <noonedeadpunk> once we're done with release, I'd love to check in PKI patches again, and merge them early in the cycle
15:16:22 <jrosser> we also need to look at what we are happy with for the magnum patches
15:16:32 <jrosser> as those are now working functionally
15:16:57 <jrosser> just we might want to adjust the structure somewhat, or have a plan for what to do with it generally in the next release
15:18:30 <noonedeadpunk> ++
15:18:33 <noonedeadpunk> yes, totally
15:19:06 <noonedeadpunk> I was just looking today at some of them, and was wondering if we wanna keep the collection named as a specific driver for instance
15:21:02 <noonedeadpunk> ie: https://review.opendev.org/c/openstack/openstack-ansible/+/966666/11/ansible-collection-requirements.yml
15:21:50 <noonedeadpunk> so question is - what we wanna do with this collection?
15:21:54 <noonedeadpunk> rename it in place?
15:22:32 <noonedeadpunk> or make a new repo for it?
15:23:16 <noonedeadpunk> or move to plugins?
15:23:18 <NeilHanlon> i vote for whatever is less work
15:23:39 <noonedeadpunk> less work is to ignore `vexxhost` in it's naming :D
15:24:42 <jrosser> ultimately it is a confusion of two things
15:24:48 <jrosser> there is the control plane k8s deployment
15:24:52 <noonedeadpunk> ideally - I think, this content would better fit the collection where we deploy k8s from
15:25:04 <jrosser> and then laying over the top of that whichever capi driver and its accessories that are needed
15:25:09 <jrosser> (or indeed both of them)
15:25:41 <noonedeadpunk> so iirc, the only difference between them are namespaces and different set of helm charts...
15:26:50 <noonedeadpunk> so 2 roles - proxy and sonobuoy are kinda indeed on the top
15:27:53 <noonedeadpunk> I'm just not sure it's worth to have different colletions on top based of the driver?
15:28:24 <jrosser> maybe it just needs a capi collection
15:28:28 <noonedeadpunk> ie CAPI_XXX - collection XXX, CAPI_YYY - collection YYY
15:28:32 <jrosser> which can have all the bits for both
15:28:42 <noonedeadpunk> yeah....
15:30:20 <noonedeadpunk> I need to get some time to finally get working magnum sandbox deployment...
15:31:06 <jrosser> andrew has had this all running in AIO fairly straightforwardly
15:31:31 <jrosser> we are just a bit stuck now to take it beyond our staging environment until the code is in a mergable form
15:31:53 <jrosser> too much tech debt if we deploy it first tbh
15:32:06 <noonedeadpunk> ok, so we can land things as is, with commitment to refactor until the next release?
15:33:06 <jrosser> well i don't know really - like you say it is best to merge it once and right perhaps
15:34:03 <noonedeadpunk> also - this mcapi_vexxhost.rust role should be just a path in os_magnum, imo
15:34:26 <noonedeadpunk> it really doesn;t do much except doing apt install...
15:34:35 <jrosser> path?
15:35:25 <noonedeadpunk> well, include_tasks: magnum_vexxhost_driver.yml when: magnum_capi_driver == 'vexxhost'
15:35:40 <noonedeadpunk> or smth like that
15:40:08 <noonedeadpunk> inside of the os_magnum role?
15:41:17 <jrosser> right - well atm there is no integration of capi stuff in there at all, which i suppose is the thing we need to think about a bit
15:46:13 <noonedeadpunk> yes, true
15:46:35 <noonedeadpunk> I'm not sure, but be guessing that heat driver may vanish anytime now
15:46:44 <jrosser> currently there is many layers of stuff exactly to keep it separate
15:46:54 <noonedeadpunk> so it's also not that we had much choice, unless leaving jsut a noop one...
15:47:21 <noonedeadpunk> we can keep it separate just to have it said, if we want to
15:47:42 <noonedeadpunk> but probably it might be easier to merge, given we get compatability for both of them
15:48:08 <noonedeadpunk> and add some check to ensure operator has defined a driver (when heat is removed)
15:48:29 <jrosser> this sounds like it is a bigger discussion
15:48:49 <jrosser> maybe we can make an etherpad in a future meeting and try to tie down where all the different parts should live
15:52:43 <andrewbonney> ^ sounds good to me - I was concerned about having time for a full refactor right now with other priorities, but before next release sounds manageable
15:55:09 <noonedeadpunk> ++
15:55:25 <noonedeadpunk> works for me as well.
15:55:53 <noonedeadpunk> should we use this link?
15:55:55 <noonedeadpunk> #link https://etherpad.opendev.org/p/osa-magnum-capi-refactoring
16:01:29 <noonedeadpunk> #endmeeting