15:00:16 <noonedeadpunk> #startmeeting openstack_ansible_meeting
15:00:16 <opendevmeet> Meeting started Tue Jan  9 15:00:16 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:16 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:16 <opendevmeet> The meeting name has been set to 'openstack_ansible_meeting'
15:00:24 <noonedeadpunk> #topic rollcall
15:00:27 <noonedeadpunk> o/
15:01:53 <jrosser> o/ hello
15:05:26 <noonedeadpunk> #topic bug triage
15:05:48 <noonedeadpunk> So, we have quite some bugs. Some are already patched, but some I'd love to get some input on
15:06:37 <noonedeadpunk> #link https://bugs.launchpad.net/openstack-ansible/+bug/2048659
15:07:39 <jrosser> sounds reasonable
15:07:53 <noonedeadpunk> so I'm thinkin on what we want to do here
15:08:08 <noonedeadpunk> Like remove cdrom from lxc conatiner repos is bare minimum
15:08:19 <noonedeadpunk> But should we also try to remove that from host repos?
15:08:24 <jrosser> there wasnt an example with the cdrom attached to the bug?
15:08:30 <noonedeadpunk> nope
15:09:34 <NeilHanlon> o/ hiya
15:09:38 <noonedeadpunk> So likely need to get CDROM installation somewhere/somehow....
15:09:45 <noonedeadpunk> to get smth to parse
15:13:57 <noonedeadpunk> going next
15:13:58 <noonedeadpunk> #link https://bugs.launchpad.net/openstack-ansible/+bug/2048209
15:14:21 <noonedeadpunk> In fact not sure what's going wrong here and was not able to reproduce the issue
15:14:23 <jrosser> `add-apt-repository --remove <whatever> || true` or something
15:14:26 <jrosser> anyway
15:15:17 <noonedeadpunk> I think we should do that only on containers? Not touch metal hosts?
15:16:34 <jrosser> yeah
15:16:44 <jrosser> so the prep script could do that if we know the thing to remove
15:17:07 <jrosser> regarding the magnum roles thing
15:17:30 <jrosser> andrewbonney has made a magnum test environment yesterday and i don't think we ran into that
15:17:48 <jrosser> and i agree that this looks like a bug that was fixed long long ago
15:18:03 <andrewbonney> Yeah, ran with latest 2023.1 tag
15:18:39 <noonedeadpunk> I will suggest to run a test playbook then that will do pretty much same logic then
15:20:21 <jrosser> was there a bug where we handled single roles / lists of roles incorrectly?
15:21:06 <jrosser> this https://review.opendev.org/c/openstack/openstack-ansible-plugins/+/896017
15:21:27 <jrosser> hmm thats not the same at all
15:22:19 <noonedeadpunk> nah, I was thinking about different issue
15:22:32 <jrosser> could be the SDK version in the utility container somehow messed up
15:23:16 <noonedeadpunk> I was thinking about this: https://opendev.org/openstack/openstack-ansible-plugins/commit/a4357fbb9a43f44bfee72b01db219f080268fbe7
15:23:42 <noonedeadpunk> but yeah, what confuses me is that data plugin claims as missing is in args
15:23:52 <noonedeadpunk> so it pretty much looks like some collection issue
15:24:04 <noonedeadpunk> though it was reported as reproducible error
15:24:08 <jrosser> becasue the error actually is from the SDK not the collection
15:24:24 <noonedeadpunk> Yeah, could be actually
15:24:35 <noonedeadpunk> that is the good point
15:24:48 <jrosser> well what i mean is consistency between collection in contoller and SDK in utility host needs to be correct
15:25:21 <noonedeadpunk> I think, in 27.3.0 I did bumped collection version....
15:25:43 <damiandabrowski> hi! (sorry, my meeting delayed)
15:26:09 <noonedeadpunk> nah..... only plugins and config_tmeplate https://opendev.org/openstack/openstack-ansible/commit/80f717a1d82bd5561d2a71a820ee4999d7abf87d
15:26:59 <noonedeadpunk> and u-c seems to be left intact as well....
15:27:59 <noonedeadpunk> Ok, next
15:28:02 <noonedeadpunk> #link https://bugs.launchpad.net/openstack-ansible/+bug/2048284
15:28:05 <noonedeadpunk> this is very good one
15:28:09 <jrosser> suggest to rebuild utility container i think
15:28:22 <noonedeadpunk> which will take us quite some effort to implement I believe
15:29:24 <noonedeadpunk> So GPG defenition to install should be part of the repo stanza I assume.
15:30:04 <noonedeadpunk> Then I guess we in fact need a module to do apt_key basically
15:30:19 <noonedeadpunk> except it won't use apt_key
15:30:42 <noonedeadpunk> but will be able to convert to gpg format when the key is not in it
15:31:05 <noonedeadpunk> and download/paste regardless of source (data/url/file/etc)
15:31:28 <noonedeadpunk> And I guess we need to cover that sooner then later, as I guess apt-key will be absent in 24.04
15:34:05 <jrosser> well i did see in the latest debian that the structure of the /etc/apt directory is very much changed
15:34:42 <jrosser> it would need looking at but this might make it easier to manage config fragments than before
15:36:16 <jrosser> example https://2b411714dff7c938c230-49130948639ed40b079dd8450de896f5.ssl.cf5.rackcdn.com/878794/33/check/openstack-ansible-deploy-infra_lxc-debian-bookworm/c4d34b5/logs/etc/host/apt/trusted.gpg.d/
15:40:21 <noonedeadpunk> so, I guess idea now, is to have an explicit path to GPG key per repo
15:41:05 <noonedeadpunk> and have `signed-by`
15:41:12 <noonedeadpunk> ie https://www.digitalocean.com/community/tutorials/how-to-handle-apt-key-and-add-apt-repository-deprecation-using-gpg-to-add-external-repositories-on-ubuntu-22-04#option-1-adding-to-sources-list-directly
15:42:57 <noonedeadpunk> or you saying that it should be jsut enough to put the key to trusted.gpg.d?
15:45:18 <jrosser> well actually i wonder if we should migrate to this everywhere https://docs.ansible.com/ansible/latest/collections/ansible/builtin/deb822_repository_module.html
15:46:10 <jrosser> maybe the `signed_by` parameter allows us enough flexibility
15:46:37 <jrosser> if we were to change anything at all it would be worth migrating to the modern ansible module and regularising the data around that
15:47:08 <noonedeadpunk> Ah, I fully missed existance of this module
15:47:30 <jrosser> `Either a URL to a GPG key, absolute path to a keyring file, one or more fingerprints of keys either in the trusted.gpg keyring or in the keyrings in the trusted.gpg.d/ directory, or an ASCII armored GPG public key block.`
15:47:34 <jrosser> is that good enough?
15:48:03 <noonedeadpunk> yes, should be totally fine actually
15:48:09 <jrosser> cool
15:48:10 <noonedeadpunk> that really slipped my attention
15:48:29 <noonedeadpunk> (module name is also slightly cumbersome)
15:48:39 <noonedeadpunk> #topic office hours
15:49:05 <noonedeadpunk> I guess we're about out of time for bugs, depsite there're couple still around (less important)
15:49:23 <jrosser> so i did want to discuss cluster-api a bit
15:50:05 <jrosser> andrewbonny and i are putting quite some effort into the patches for the vexxhost driver
15:51:13 <jrosser> and we need to be sure that we do the right thing by putting it in the ops repo
15:52:16 <jrosser> the integration for an 'easy' AIO is pretty wild https://review.opendev.org/c/openstack/openstack-ansible-ops/+/902178
15:53:10 <jrosser> and this is only the start as it will need overridable playbook hooks putting in a bunch of the existing opesntack-ansible/playbooks/*
15:55:40 <noonedeadpunk> Suggest to place that all to integrated repo from the beginning?
15:55:46 <jrosser> well perhaps
15:56:16 <jrosser> even today there is talk in #openstack-containers of keeping the other driver out of tree
15:57:05 <jrosser> though there are probably downsides to putting it in os_magnum as well
15:57:35 <jrosser> maybe we don't want always to be carrying collection dependancies on the k8s stuff
15:58:14 <jrosser> though correct use of include vs import might make that not be an issue
15:59:49 <noonedeadpunk> as well as install bunch of vexxhost collections for everyone...
15:59:53 <jrosser> right
16:00:15 <noonedeadpunk> frankly speaking I don't know at this point
16:00:46 <jrosser> i am a bit sad about it all tbh
16:01:00 <jrosser> becasue for the first time ever magnum "just worked" in our environment
16:01:03 <noonedeadpunk> From one side I do fully understand and share your concerns. From other I don't want to support or be in any way "responsible" for having that as supported part of the project....
16:01:36 <noonedeadpunk> And at the same time will highly likely install one of capi drivers this year as well
16:01:49 <noonedeadpunk> so pretty much interested in a good outcome as well
16:04:25 <jrosser> i can continue with what i'm doing and add a bunch of playbook hooks
16:04:33 <jrosser> that might be a good feature anyway
16:07:26 <noonedeadpunk> If you think it's unreasonably cumbersome - we in fact may indeed prefer adding all in tree somehow
16:07:46 <jrosser> this is why i'd really like someone else to have a go with it
16:07:54 <noonedeadpunk> maybe through naming/comment/documentation remove liability for the feature from ourselves....
16:07:58 <jrosser> i think my tolerance of a complex setup is quite high
16:08:10 <jrosser> but that might not be good for everyone
16:08:11 <noonedeadpunk> then it should not be me lol
16:08:44 <jrosser> and ideally it should be trivial to make an AIO
16:08:50 <jrosser> and trivial to make a CI job
16:08:57 <noonedeadpunk> yeah....
16:09:59 <jrosser> eventually for a production deployment we are managing really fine with it out of tree, in a collection in the ops repo
16:10:37 <jrosser> but making an CI job in os_magnum is pretty challenging
16:10:53 <jrosser> as we have to "call out" to the collection
16:11:06 <jrosser> at some point after magnum and before tempest
16:28:09 <noonedeadpunk> #endmeeting