14:00:40 <noonedeadpunk> #startmeeting openstack_ansible_meeting
14:00:40 <opendevmeet> Meeting started Tue Mar 31 14:00:40 2026 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:40 <opendevmeet> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:40 <opendevmeet> The meeting name has been set to 'openstack_ansible_meeting'
14:00:44 <noonedeadpunk> #topic rollcall
14:00:47 <noonedeadpunk> o/ hey
14:01:26 <mgariepy> hey !
14:06:15 <noonedeadpunk> #topic office hours
14:06:29 <noonedeadpunk> I have multiple updates from my side
14:06:46 <noonedeadpunk> I got almost working azimuth driver for magnum
14:07:02 <noonedeadpunk> as part of the https://review.opendev.org/c/openstack/openstack-ansible-os_magnum/+/979668
14:07:46 <noonedeadpunk> though magnum overall fails on Horizon collectstatic task
14:08:03 <noonedeadpunk> it seems that some plugin is either non-functional, or we need to do some bump for SHAs
14:09:17 <opendevreview> Dmitriy Rabotyagov proposed openstack/openstack-ansible-plugins master: Migrate k8s cluster from osa ops into main tree  https://review.opendev.org/c/openstack/openstack-ansible-plugins/+/975276
14:09:33 <opendevreview> Andrew Bonney proposed openstack/openstack-ansible-plugins master: Add magnum_capi_proxy playbook  https://review.opendev.org/c/openstack/openstack-ansible-plugins/+/979969
14:09:39 <opendevreview> Dmitriy Rabotyagov proposed openstack/openstack-ansible-plugins master: Add sonobuoy role for testing k8s clusters  https://review.opendev.org/c/openstack/openstack-ansible-plugins/+/975393
14:09:42 <opendevreview> Andrew Bonney proposed openstack/openstack-ansible-plugins master: Add magnum_capi_proxy playbook  https://review.opendev.org/c/openstack/openstack-ansible-plugins/+/979969
14:10:06 <noonedeadpunk> I was not checking on Horizon, but issue looks pretty much like what was dealt with for octavia and heat
14:10:27 <noonedeadpunk> #link https://review.opendev.org/c/openstack/heat-dashboard/+/979418
14:10:46 <noonedeadpunk> #link https://review.opendev.org/c/openstack/octavia-dashboard/+/980130
14:10:55 <noonedeadpunk> but probably it wasn't done for Magnum....
14:11:59 <noonedeadpunk> Going next, Freezer role I think is pretty much ready to the review
14:12:16 <noonedeadpunk> #link https://review.opendev.org/q/topic:%22osa/freezer%22
14:12:27 <noonedeadpunk> it has a relevant tempest test which is passing
14:13:16 <noonedeadpunk> #link https://528b8a200a0edba06989-58a9f5f5793940e036b8abf187f02364.ssl.cf5.rackcdn.com/openstack/bd1e8324d6384280b4f0c37d68be6823/logs/openstack/aio1-utility-container-b84a9bee/utility/stestr_results.html
14:13:29 <noonedeadpunk> so I think it's a good start
14:13:54 <noonedeadpunk> freezer patches for running scheduler centrally are almost ready, though they will be merged only for 2026.2
14:14:15 <noonedeadpunk> so I did not implement logic yet, as we're still in 2026.1
14:15:03 <noonedeadpunk> Going next - Octavia and Glance are kinda broken now. Octavia has merged a fix just today, so we need to pull it in
14:15:24 <noonedeadpunk> #link https://review.opendev.org/c/openstack/octavia/+/982744
14:15:51 <noonedeadpunk> regarding glance - it's not yet merged yet, but a workaround is available
14:16:21 <noonedeadpunk> (which we merged - #link https://review.opendev.org/c/openstack/openstack-ansible-os_glance/+/982526)
14:16:26 <noonedeadpunk> so I will retry swift now
14:18:20 <opendevreview> Dmitriy Rabotyagov proposed openstack/openstack-ansible master: Switch upstream repos to track 2026.1  https://review.opendev.org/c/openstack/openstack-ansible/+/982216
14:18:37 <noonedeadpunk> I have just updated ^ to include Octavia fix
14:18:43 <noonedeadpunk> Please, kindly re-vote on this
14:20:52 <mgariepy> done
14:23:16 <mgariepy> are you satisfied with https://review.opendev.org/c/openstack/openstack-ansible/+/981266 ?
14:23:33 <noonedeadpunk> I need to look at it again :)
14:23:53 <mgariepy> https://34e06260e11573290c97-76fc92e5e7c4e5a091c792a95503ad1d.ssl.cf2.rackcdn.com/openstack/4db5147acaae452ca1bdfbdf6ab27270/docs/reference/configuration/using-overrides.html#overriding-python-dependencies-for-services-in-openstack-ansible
14:23:53 <mgariepy> i would probably just remove sub-submenus  from that page.
14:25:28 <noonedeadpunk> I think that structure is fine
14:26:06 <noonedeadpunk> I am not completely sure though what is the difference between "Override with a released version" and "Override with a commit"
14:26:18 <noonedeadpunk> as I;d say these should be kinda same?
14:26:54 <mgariepy> it's kinda similar but you can either use a relaseased version  or the sha.
14:27:18 <mgariepy> we applied the patch with the sha on 2024.1 because it wasnt released a a new version.
14:27:28 <noonedeadpunk> but it's just how you define `xx_user_pip_packages`?
14:28:04 <noonedeadpunk> so having these 2 separately add unnecessary complexity to the original intention
14:28:18 <noonedeadpunk> Actually, I also discovered one interesting possibility
14:28:52 <mgariepy> maybe both need the same structure. in case you need to override a dependency accross multiple service.
14:29:16 <noonedeadpunk> first - you can just override user_requirements_git_url with your custom thing
14:29:41 <noonedeadpunk> but both of these are applicable only to the same service?
14:31:01 <mgariepy> i'll test the user_requirement_git_url a bit.
14:32:10 <mgariepy> i would use glance_user_pip_package: "{{ xx_user_pip_package }}"  but also nova_user_pip_package:..
14:33:30 <noonedeadpunk> but all of these have service_user_pip_packages ?
14:34:00 <mgariepy> maybe it should be <service>_user_**
14:34:11 <mgariepy> for clarity
14:35:15 <noonedeadpunk> mgariepy: actually second thing I found out, is that if you place any custom file inside of /etc/openstack_deploy/upper-constraints  - it will end up on a repo container
14:35:25 <noonedeadpunk> and then can be used as another constraint
14:35:28 <noonedeadpunk> but yeah
14:35:40 <noonedeadpunk> that would not help with the example/intention, as files are not merged
14:35:44 <noonedeadpunk> and would be conflicting
14:36:01 <noonedeadpunk> so doc is still good and relevant
14:36:22 <mgariepy> yeah, multiple ways to have the same-ish result.
14:37:20 <mgariepy> i'll dig a bit further and talk with Ourdia to update  the documentation a bit more.
14:37:55 <noonedeadpunk> but eventually, it should be kinda enough service_user_pip_packages: "{{ xx_user_pip_packages }}" for most cases, where we have service_user_pip_packages available
14:37:56 <noonedeadpunk> anyway
14:38:20 <noonedeadpunk> I except that difference between sections is not that obvious to me right now, I think it's rather good
14:38:40 <noonedeadpunk> and probably slightly renaming vars outside of example may bring extra clarity
14:39:04 <mgariepy> yep i will do that.
14:39:12 <mgariepy> documenting is hard. lol.
14:39:25 <noonedeadpunk> it is
14:39:30 <noonedeadpunk> I know that...
14:40:15 <mgariepy> on another note, i tested your libvirt multi-stream patch .
14:40:22 <mgariepy> i works wonders ;)
14:40:57 <noonedeadpunk> nice ;)
14:41:16 <noonedeadpunk> yeah, I wish it appeared in nova earlier...
14:41:25 <mgariepy> i wonder if we could push to backport it a bit.
14:41:37 <noonedeadpunk> it's a new feature
14:41:45 <noonedeadpunk> so not really eligible for backporting
14:41:47 <mgariepy> it's disabled by default..
14:42:18 <noonedeadpunk> because multicopy, and cpu utilization
14:42:34 <noonedeadpunk> really a lot of ppl use live migration as solution to hypervisors overload
14:42:47 <noonedeadpunk> and migrating with 5 cores will make things way worse in such cases
14:43:20 <mgariepy> in my tests i had to enable the auto-converge as well a a few threads.
14:43:32 <noonedeadpunk> and with TLS and 100gbit channel I was able to utilize around 8 cores
14:44:12 <mgariepy> i guess it depends on the hypervisor also, depending on how many nic/lacp and so on.
14:44:42 <noonedeadpunk> I was migrating 64gb VM with stress inside of it
14:44:53 <mgariepy> do you reserve the core on the hypervisor?
14:45:14 <noonedeadpunk> well, yes, but VMs were not with dedicated cortes
14:45:16 <mgariepy> i was migrating 60gb with stressapptest running.
14:45:22 <noonedeadpunk> so migration was taking from shared pool
14:45:41 <noonedeadpunk> or dunno...
14:45:47 <noonedeadpunk> maybe I am confusing myself now
14:45:51 <mgariepy> on older hw with only 2x12c..
14:46:05 <noonedeadpunk> At least I am sure I saw like 7 cores 100% util and 8th was around 70%
14:46:28 <mgariepy> but i didn't pin anu core to anything.
14:46:30 <noonedeadpunk> but I got like 80gbit throughput for migration
14:46:42 <mgariepy> so in my tests without the auto-converge feature it wasn't able to migrate.
14:47:04 <noonedeadpunk> yeah, I am pretty sure we're having auto-converge in production
14:47:32 <noonedeadpunk> but my point was that enabling by default can result in a problem, and some operator awareness is required
14:47:43 <mgariepy> anyway i'll have plenty of time to finetune it in the future..
14:47:43 <mgariepy> id i need.
14:47:44 <mgariepy> id/if
14:48:00 <noonedeadpunk> ++
14:48:40 <mgariepy> yeah indeed but still without it some vms are just impossible to migrate
14:51:33 <mgariepy> that's pretty much it for me.
14:52:01 <noonedeadpunk> cool, thanks!
14:52:15 <noonedeadpunk> I will wrap up the meeting then, as I don't think I have much else
14:52:19 <noonedeadpunk> #endmeeting