15:00:12 <noonedeadpunk> #startmeeting openstack_ansible_meeting
15:00:12 <opendevmeet> Meeting started Tue Aug  6 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:18 <noonedeadpunk> #topic rollcall
15:00:20 <noonedeadpunk> o/
15:00:24 <jrosser> o/ hello
15:00:28 <hamburgler> o/
15:03:20 <noonedeadpunk> #topic office hours
15:03:42 <noonedeadpunk> So, I think we're ready to have new bugfix releases for stable branches
15:04:05 <noonedeadpunk> though, I realized that it's probably worth pinging/bumping config_template collection for that
15:04:19 <noonedeadpunk> #link https://review.opendev.org/c/openstack/releases/+/925750
15:04:28 <noonedeadpunk> or, we can include it in the next one
15:04:43 <noonedeadpunk> there's 1 "bugfix" that mainly affects 1 nova thing
15:05:26 <noonedeadpunk> so this topic is useless without config_template update
15:05:28 <noonedeadpunk> #link https://review.opendev.org/q/Ifc1239e4ef768e94c44d8d07df7a0b93c73638f9
15:05:54 <noonedeadpunk> Im kinda fine with both options
15:07:05 <jrosser> ah so in order to be able to use that we need to bump the version of config_template on stable branches?
15:07:11 <noonedeadpunk> yeah
15:08:09 <noonedeadpunk> maybe frickler will be able to help landing it when around :D
15:08:29 <jrosser> well - the change it needs to config_template is kind of small
15:08:43 <jrosser> not like a large change
15:09:06 <noonedeadpunk> yeah, so it should be not an issue to update it's version
15:09:17 <noonedeadpunk> just matter of time
15:09:28 <jrosser> i think thats OK if your happy with that
15:10:01 <noonedeadpunk> then, I just found an outstanding topic, that's been a while after initial discussion.
15:10:13 <noonedeadpunk> #link https://review.opendev.org/c/openstack/openstack-ansible-os_octavia/+/922837
15:10:53 <noonedeadpunk> was going to ask if probably you have a better workaround already in place?
15:11:29 <jrosser> that would be a question best for andrewbonney i think
15:12:00 <noonedeadpunk> as I wasn;t able to iterate on that and even already forgot what the problem was :(
15:12:24 <andrewbonney> Just reminding myself...
15:12:33 <noonedeadpunk> and that sounds like smth worth backporting to 2024.1 at very least
15:12:42 <jrosser> well yes - i think that at the moment the code doesnt really account for the deploy host being seperate
15:12:47 <jrosser> ^ sort of
15:13:05 <jrosser> and that you want to treat the utility containers as deleteable
15:13:18 <noonedeadpunk> yeah, true
15:13:28 <noonedeadpunk> now I've recalled
15:13:44 <opendevreview> Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Enchance reference_group logic for inventory  https://review.opendev.org/c/openstack/openstack-ansible/+/923596
15:13:55 <jrosser> perhaps it is actually better that the keypair is created on the deploy host, completely seperate
15:14:52 <hamburgler> For this since we use an ansible role to deploy OSA to our deployment host, we copy over the octavia private key to deployment host, which then gets deployed to utility lxc, and added a task to utility playbook to deploy the key to utility lxc in event it is deleted
15:15:18 <hamburgler> Maybe doesn't fit the use case here
15:15:37 <jrosser> i think the issue here is that in the past it worked kind of like that
15:16:00 <jrosser> but refactoring to use the openstack_resources role to handle creating the keypair has pretty different behaviour
15:16:33 <noonedeadpunk> but to be fair - location on the deploy host was also very unfortunate, as it was under ${HOME}
15:16:54 <jrosser> oh indeed yes
15:16:54 <andrewbonney> Yeah, I think I worked around this when upgrading to C making sure the existing keys were manually in the right places to prevent tasks running, but that doesn't fix things if we needed to do a fresh deploy with our model
15:17:09 <noonedeadpunk> so, we had some envs, where keypair was created under certain user home directories rather then "assumed" /root
15:17:27 <jrosser> we could move to the ssh_keypairs role we have in the plugins repo
15:17:54 <jrosser> then i think this all gets regularised with the other autogenerated keys
15:17:56 <noonedeadpunk> but I think this is smth we'd need to fix before doing 29.1.0? as this totally will mess upgrades...
15:18:52 <noonedeadpunk> and thinking about that... I guess I will get some time this week to look into the patch as part of upgrade preparation..
15:19:19 <jrosser> imho it is just making things more difficult by having nova generate the keypair
15:19:50 <noonedeadpunk> So openstack_resources role does not rely on nova for that anymore
15:20:01 <noonedeadpunk> moreover - this behaviour is deprecated in nova
15:20:15 <noonedeadpunk> so current microapi will refuse to generate a keypair for you
15:20:32 <jrosser> oh then we need to fix `comment: Generated-by-Nova`
15:21:02 <noonedeadpunk> well. the problem with the comment is... that for existing keys module will either fail or rewrite the key depending on options
15:21:16 <noonedeadpunk> so it's done to make it idempotent for upgrades case...
15:21:21 <jrosser> ah
15:21:40 <noonedeadpunk> (but as we know - upgrades are borked out of aio anyway)
15:21:58 <jrosser> we should just patch octavia to have an ssh CA :)
15:22:07 <jrosser> then you could make the key only when you need it
15:22:29 <noonedeadpunk> hehe
15:22:54 <noonedeadpunk> that would be too good
15:23:20 <noonedeadpunk> ok, another thing, is that we have a lot of CI failures recently
15:23:29 <jrosser> hmm well if you have some time to think about it - i don't think we will fix it here just now
15:23:40 <jrosser> yes i was trying to keep a list of whats failing
15:24:24 <jrosser> a bunch of failing to retrieve u-c which i think could be some regression as i thought we got that locally
15:24:44 <jrosser> a bunch of failing to download cirros which needs openstack_resources to have a concept of a cache directiry
15:24:51 <noonedeadpunk> one big change is that nginx got replaced with apache
15:24:54 <jrosser> ceph seems fragile
15:25:16 <noonedeadpunk> and there was obvious issue with rocky tls jobs which is now fixed
15:25:46 <noonedeadpunk> yeah, openstack_resources totally needs a bit more love regarding images...
15:26:19 <noonedeadpunk> And I also spotted ceph, but it seems to fail somewhere on tempest
15:26:27 <jrosser> right - we did discuss caching / format conversion / which SHA to specify previously
15:28:46 <noonedeadpunk> yeah, though was not able to check on that specifically
15:29:06 <noonedeadpunk> was trying to fix the tests repo - utter waste of time :(
15:29:28 <noonedeadpunk> we're doing so much things differently now....
15:31:54 <noonedeadpunk> ah. btw I've tried to propose some change to the apache role which we could potentially use, but seems it didn't went particulary well: https://github.com/geerlingguy/ansible-role-apache/pull/256
15:32:18 <noonedeadpunk> and yeah. there's quite some complexity needed not to break existing deployments
15:32:45 <noonedeadpunk> so likely we'd need to come up with own one (as usual)
15:33:45 <noonedeadpunk> and it's still on me to document how to run services on domain.com/<service_type>
15:34:45 <noonedeadpunk> pretty much got that example working :D
15:37:03 <noonedeadpunk> ended pretty much with this for services that use uwsgi: https://paste.openstack.org/show/bExMotkR2J2rZFmR9AzH/
15:37:58 <noonedeadpunk> but for those, that are not, I have to add `public_endpoint` option, ie for glance https://paste.openstack.org/show/bTA86aXPXL5rjHOJ6njP/
15:38:17 <noonedeadpunk> so having subdomains is way more neat, imo...
15:40:36 <noonedeadpunk> but question stands - how to make such setup neat enough
15:41:46 <noonedeadpunk> or just let it be documentation only
15:44:07 <hamburgler> subdomains are much neater - especially when dealing with multiple regions, prefer this too
15:45:58 <noonedeadpunk> the problem I was trying to solve - have single let's encrypt certificate
15:46:52 <noonedeadpunk> But well, it's possible to specify all subdomains in the list as well...
15:47:42 <noonedeadpunk> though until you will want to have different certs for internal and external endpoints...
15:49:22 <noonedeadpunk> but yeah - I wasn't able to make RGW to work under URI at all
15:49:24 <hamburgler> one thing you can do, if you place behind cloudflare using advance cert subscription, it proxys all. Still uses lets encrypt but makes management very simple and only a small fee
15:49:54 <noonedeadpunk> well - we can't use cloudflare compliance wise
15:49:59 <hamburgler> ah :(
15:50:15 <noonedeadpunk> but yeah, I have 2 options here, so hopefully will document both of them soon
15:50:35 <platta> I successfully modified the network configuration of an AIO in between deployment steps and ended up with an environment where I can create floating IPs that live on my physical network. Now I'll re-image and try using the same configuration files for a standard install.
15:53:47 * frickler is reading backlog, but not sure about the context, which change needs more power?
15:54:17 <noonedeadpunk> with the release hat on:) https://review.opendev.org/c/openstack/releases/+/925750
16:02:32 <noonedeadpunk> #endmeeting