15:00:12 <noonedeadpunk> #startmeeting openstack_ansible_meeting
15:00:12 <opendevmeet> Meeting started Tue Mar 26 15:00:12 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:12 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:12 <opendevmeet> The meeting name has been set to 'openstack_ansible_meeting'
15:00:19 <noonedeadpunk> #topic rollcall
15:00:21 <noonedeadpunk> o/
15:03:09 <jamesdenton> o/
15:05:07 <noonedeadpunk> #topic office hours
15:05:31 <noonedeadpunk> first of all - I've seen there's a NTTData folk asking for AIO help in ML
15:05:51 <noonedeadpunk> I saw that but didn't have time to reply, so mostly bringing this in as a reminder :)
15:06:21 <noonedeadpunk> since yesterday I had quite some progress on logic building skyline with yarn
15:06:21 <jamesdenton> Saw that this morning, but i think an AIO in AWS might not give them the output they're looking for.
15:06:44 <noonedeadpunk> I haven't read their current issue...
15:06:48 <jamesdenton> Nice! Not sure if you saw jrosser's original commit, but it had yarn bits
15:07:31 <jrosser> i did see that and i thought there was confusion about AWS not allowing vlans
15:07:44 <jrosser> but afaik inside an AIO that should be completely OK
15:10:43 <NeilHanlon> o/
15:10:54 <noonedeadpunk> o/
15:11:20 <noonedeadpunk> Actually question to you NeilHanlon - did you have a chance to check if we still really need lxc-templates-extra?
15:11:46 <noonedeadpunk> jrosser: Yeah, inside AIO perimiter that should be fine indeed
15:12:03 <noonedeadpunk> not really if they want to extend inside AIO though
15:12:11 <jrosser> yes, indeed
15:14:17 <NeilHanlon> i didn't get a chance to check on that, no :(
15:16:45 <jamesdenton> noonedeadpunk FWIW that EC2 thread is an extension of a thread you're on already @ [Bobcat][Ansible][AIO] how to inspect lxc logs
15:17:26 <noonedeadpunk> Yeah, I just didn't had a chance to read through carefully their reply :(
15:17:28 <NeilHanlon> i'm adding it back to my todos... i lost it somewhere
15:17:37 <noonedeadpunk> sure, no worries :)
15:18:49 <noonedeadpunk> today I've also pushed switch to 2024.1 branch, and it looks quite broken right now: https://review.opendev.org/c/openstack/openstack-ansible/+/914188
15:19:03 <noonedeadpunk> moreover, we need to decide on how we wanna act with inactive projects
15:19:34 <noonedeadpunk> like senlin, murano and sahara
15:19:43 <noonedeadpunk> should we drop playbooks but leave roles?
15:19:54 <noonedeadpunk> should we drop inventory?
15:19:58 <noonedeadpunk> (env.d files)
15:20:44 <jrosser> so i guess it is a question of what we want to happen on new vs existing deployments
15:21:23 <noonedeadpunk> yeah
15:21:30 <jrosser> the smallest change would be to remove the playbook and env.d parts so that these inactive projects do not get into new deployments
15:21:40 <noonedeadpunk> as eventually, I guess we should just keep existing ones using old versions
15:21:46 <noonedeadpunk> while prohibit for new ones
15:22:08 <jrosser> and then existing deployments will be ok, but need a releasenote saying that their project X is no longer updated and deployers need to decide if to keep or remove it
15:22:11 <noonedeadpunk> but that means we should keep SHAs to..... to what?
15:22:34 <noonedeadpunk> or just drop them and let them install from master?
15:23:01 <jrosser> if we remove the platybook then the installation gets frozen effectively for that service
15:23:33 <noonedeadpunk> also, removing playbook kinda hit me, that then they can't also operate it in any way on old version
15:23:45 <noonedeadpunk> like change config or anything
15:23:59 <jrosser> maybe we are more subtle then and just remove it from setup-openstack
15:24:10 <noonedeadpunk> yeah...
15:24:51 <noonedeadpunk> ok, sounds fair enough - remove env.d, do not branch, remove SHA defenition, remove playbook from setup-openstack
15:25:05 <noonedeadpunk> write reno
15:25:23 <noonedeadpunk> document in contribtor docs
15:25:56 <noonedeadpunk> I will make it as a follow-up tosha bump to 2024.1
15:26:08 <noonedeadpunk> talking about which - that's the reason: https://zuul.opendev.org/t/openstack/build/27485728c1ef402198e50a05438860ca/log/logs/host/glance-api.service.journal-10-32-01.log.txt#246-256
15:26:10 <jrosser> that sounds reasonable
15:28:06 <noonedeadpunk> huh, why it even tries sqlite....
15:29:45 <jrosser> thats the default
15:29:57 <noonedeadpunk> https://opendev.org/openstack/glance/commit/309ca3aec26b6dd49b8d955c4900a5c390d14537 that looks kinda related
15:30:49 <jrosser> https://opendev.org/openstack/glance-specs/src/branch/master/specs/2024.1/approved/glance/centralized-cache-db.rst
15:32:59 <noonedeadpunk> um, okay
15:33:10 <noonedeadpunk> what worker_self_reference_url should be then....
15:33:25 <noonedeadpunk> Like really backend one on mr-mgmt?
15:34:31 <noonedeadpunk> As I'm afraid it can be exposed to end users?
15:36:05 <noonedeadpunk> feels like would be better idea to implement my_ip or smth instead....
15:37:30 <noonedeadpunk> as indeed - it feels to be exposed in image metadata? https://opendev.org/openstack/glance/src/branch/master/glance/api/v2/images.py#L287-L307
15:38:31 <noonedeadpunk> ok, I kinda don't understand that....
15:39:51 <jrosser> what even is this for
15:40:16 <noonedeadpunk> for direct-import
15:40:27 <noonedeadpunk> https://opendev.org/openstack/glance/src/branch/master/glance/api/v2/images.py#L434-L438
15:40:48 <noonedeadpunk> so I guess, it assumes that backend is publicly available directly
15:40:55 <noonedeadpunk> rather then be behind LB
15:44:45 <noonedeadpunk> and glance IRC is just dead as well...
15:46:38 <jrosser> this also seems to say that glance api hosts call each other on the backend http interfaces
15:50:25 <noonedeadpunk> I'm also looking at glance, and it feels that we don't really need an RPC for it
15:50:39 <noonedeadpunk> just notifications
15:51:04 <jrosser> before we are out of time i wanted to ask about the unmaintained branches
15:51:10 <noonedeadpunk> sure
15:51:14 <jrosser> they are pretty much totally broken
15:51:19 <noonedeadpunk> they are
15:51:30 <jrosser> and do we want to put any effort into some/any of these?
15:51:34 <noonedeadpunk> We need to merge them without CI and fix on unmaintained I think
15:51:50 <noonedeadpunk> As currently they're trying to pull master dependencies
15:52:09 <noonedeadpunk> since stable were dropped, so zuul just don't know what to pull in
15:56:58 <noonedeadpunk> I;ve spawned Xena locally and it failed just on rabbit then
15:58:00 <jrosser> yeah, i think this was the case before the branch names changed
15:58:43 <noonedeadpunk> yeah
15:58:56 <noonedeadpunk> so feels that Xena is kinda way to go for others
15:59:00 <spatel> I am running Xena and want to upgrade to next possible release :)
15:59:22 <noonedeadpunk> Was going to iterate on that once done with some other things
16:07:20 <noonedeadpunk> #endmeeting