15:00:33 <noonedeadpunk> #startmeeting openstack_ansible_meeting
15:00:34 <openstack> Meeting started Tue May  4 15:00:33 2021 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:35 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:37 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
15:00:44 <noonedeadpunk> #topic rollcall
15:01:10 <noonedeadpunk> o/
15:01:20 <jrosser> o/ hello
15:05:25 <noonedeadpunk> #topic office hours
15:05:39 <noonedeadpunk> I don't think there were new bugs for the previous weeks?
15:05:57 <jrosser> there was the issue with glance/uwsgi
15:06:09 <jrosser> which is a bug against glance really but the deployment was OSA
15:06:30 <noonedeadpunk> ah, yeah, I read and the bug was actually in glance thread.
15:06:40 <jrosser> i was wondering if this only showed up when the ceph speed is slower that the upload
15:06:41 <noonedeadpunk> which suggested to switch haproxy to tcp mode?
15:07:01 <noonedeadpunk> I was atually suspecting smth like that
15:07:19 <noonedeadpunk> as never saw this happening
15:07:22 <jrosser> i never see this, but then have got glance on nvme pool, so it's going to be quick
15:07:38 <noonedeadpunk> well, we have on hdd
15:07:55 <noonedeadpunk> and still looks okeyish
15:08:03 <jrosser> hrrm it's kind of wierd, or else accidental ceph-over-1G-interface somewhere
15:08:34 * jrosser looks at br-mgmt in the standard stup
15:08:36 <jrosser> *setup
15:09:56 <noonedeadpunk> also there was a recent update for https://bugs.launchpad.net/openstack-ansible/+bug/1877421
15:09:56 <openstack> Launchpad bug 1877421 in openstack-ansible "Cinder-volume is not able to recognize a ceph cluster on OpenStack Train." [Undecided,Confirmed]
15:09:56 <openstackgerrit> Merged openstack/openstack-ansible master: Add centos-8 stream jobs  https://review.opendev.org/c/openstack/openstack-ansible/+/776226
15:10:11 <noonedeadpunk> oh, centos stream jobs merged - nice!
15:12:20 <jrosser> huh interesting
15:12:33 <jrosser> there was definatly something odd when the backend was called rbd
15:12:59 <noonedeadpunk> but this still works in some scenarios...
15:13:06 <spotz> We still supporting Train? I can't keep up!!
15:13:34 <noonedeadpunk> um, I think there're 10 days left until Train goes to EM
15:13:49 <noonedeadpunk> iirc ML from release team?
15:14:25 <jrosser> relatedly there was stuff on the ML about deleting foo-eol branches
15:14:32 <jrosser> which we dont currently have any of
15:14:43 <noonedeadpunk> yep, and they talked about ocata atm
15:15:02 <noonedeadpunk> so ocata will be just dropped as far as I got it
15:15:27 <noonedeadpunk> btw, it's really smth I wanted to discuss as well - if we want to drop more branches then just ocata?
15:15:34 <spotz> Ok so we're in the grey area if someone wants to look at that new bug
15:15:58 <noonedeadpunk> well, we still can backport even to EM
15:16:09 <noonedeadpunk> it's more about that we don't have to :)
15:16:56 <noonedeadpunk> in EM we don't push new tags, and we remove bumps to SHAs, just switching to the stable/train all roles and services
15:17:22 <spotz> noonedeadpunk: I think it comes down to what the team can effectively support. Better to support fewer well then more badly
15:17:52 <noonedeadpunk> yeah, agree. But I'm not sure that this bug doesn't affect deployments after train
15:18:25 <noonedeadpunk> https://bugs.launchpad.net/openstack-ansible/+bug/1877421/comments/1
15:18:25 <openstack> Launchpad bug 1877421 in openstack-ansible "Cinder-volume is not able to recognize a ceph cluster on OpenStack Train." [Undecided,Confirmed]
15:18:41 <spotz> noonedeadpunk: Very true on that. was thinking more the comment on whether we should drop more then Ocata
15:19:14 <noonedeadpunk> ah, gotcha:)
15:19:45 <spotz> Yeah looks like we should look into that
15:19:53 <noonedeadpunk> yeah, I think we should not really support everything that in EM. It's probably metter of if we should remain branches to allow ppl to reffer the code they might be still running
15:20:57 <noonedeadpunk> As I wouldn't expect that all deployments are U now... But we probably can do clean up of branches until R?
15:21:39 <spotz> Looks like there's a fix for it already in the that 421 bug
15:22:14 <noonedeadpunk> um, yeah... but... not smth I'd want to playbook
15:22:37 <spotz> So we could doc it
15:22:41 <noonedeadpunk> but that actually points to misconfigured active/active cluster I think?
15:22:56 <jrosser> R is a good place to still have around, it's the xenial->bionic transition and also the last place where repo_build is a thing
15:23:37 <noonedeadpunk> yep, was talking up to R, excluding R (so leave R, drop Q,P,O?)
15:24:12 <noonedeadpunk> or actually, we can do nothing, and just have as much as we can, and follow releases team in that
15:24:32 <noonedeadpunk> they drop O and I'm fine with that actually
15:25:02 <mgariepy> please keep R for a while .. :S
15:25:41 <openstackgerrit> Dmitriy Rabotyagov proposed openstack/openstack-ansible master: [doc] Add OS compatability matrix  https://review.opendev.org/c/openstack/openstack-ansible/+/789376
15:26:00 <mgariepy> which openstack release does drop the py2 support ?
15:26:18 <jrosser> that depends if you're on centos or not
15:26:37 <noonedeadpunk> T for ubuntu, U for Centos ?
15:26:46 <jrosser> something like that, yes
15:26:59 <noonedeadpunk> btw, regarding that, I've created OS compatability page https://review.opendev.org/c/openstack/openstack-ansible/+/789376
15:27:07 <noonedeadpunk> which didn't render properly :(
15:28:18 <spotz> noonedeadpunk: You want me to fix grammary things?
15:28:44 <noonedeadpunk> yes, please :)
15:28:56 <noonedeadpunk> sorry for that :)
15:29:08 <spotz> That's my job:)
15:29:34 <noonedeadpunk> I'm sooooooo bad in writing docs :(
15:30:55 <noonedeadpunk> ok, so regarding dropping branches - I guess let's not hurry then, and just follow the general policy of EOLing them
15:31:15 <spotz> Just ping! I don't mind fixing though sometimes they're already merged when I wake up:)
15:31:50 <noonedeadpunk> sure, gotcha!
15:32:20 <noonedeadpunk> ok, another thing - https://review.opendev.org/c/openstack/openstack-ansible-os_adjutant/+/777607 - I kind of struggle to find nice solution here
15:33:00 <noonedeadpunk> which will suite both metal and lxc. Probably, adding mysqlclient installation separately of the venv build might work...
15:33:11 <noonedeadpunk> But still, we need some repos to be added
15:33:18 <noonedeadpunk> (at least for centos)
15:33:46 <noonedeadpunk> or play with package name depending on is_metal condition
15:34:01 <noonedeadpunk> which would be really weird assumption...
15:34:27 <jrosser> so adjutant somehow requires the mysql-dev C library directly?
15:34:41 <openstackgerrit> Amy Marrich proposed openstack/openstack-ansible master: [doc] Add OS compatability matrix  https://review.opendev.org/c/openstack/openstack-ansible/+/789376
15:35:22 <noonedeadpunk> it requires mysqlclient library, which requyires mysql-dev for it's operation, since it's just kind of lightweight proxy for python
15:35:54 <noonedeadpunk> and IIRC it won't be even built without mysql-dev being present on the host
15:36:08 <noonedeadpunk> s/built/installed/
15:36:32 <noonedeadpunk> we don't have issues with other services as they use PyMySQL instead
15:36:37 <jonher> background is it's using django and pymysql is not officially supported there, so dev does not want to use pymysql for now, but he would look into it
15:37:19 <jrosser> calling the whole galera-client role just for that is really not great
15:37:50 <noonedeadpunk> Yep....
15:39:26 <noonedeadpunk> but actually that's a solution as well I think
15:39:42 <jrosser> in fact even galera_client_main.yml looks like it installs *way* too much stuff?
15:40:33 <noonedeadpunk> I'm actually not sure it installs dev?
15:40:36 <jrosser> oh no it's fine actually
15:40:53 <jrosser> well, perhaps we can add an extra tasks file for installing just the repo and the -dev parts
15:41:38 <noonedeadpunk> You mean in galera role or adjutant?
15:41:39 <jrosser> that would be a small patch to define a new var for this https://github.com/openstack/openstack-ansible-galera_server/blob/master/tasks/galera_client_main.yml#L18
15:41:46 <jrosser> galera role
15:41:58 <jrosser> then we could re-use that to setup the repo and install the -dev stuff
15:42:10 <jrosser> in both the repo server and the adjutant install
15:42:38 <noonedeadpunk> oh, well... we can actually add when: galera_packages_list is not defined
15:42:48 <noonedeadpunk> and pass galera_packages_list from adjutant role?
15:43:31 <jrosser> would the set_fact take precedence?
15:43:33 <noonedeadpunk> (as passing galera_client_distro_packages won't work I think)
15:43:49 <noonedeadpunk> but if we won't do set_fact when variable is defined
15:43:56 <noonedeadpunk> then it won't)
15:44:03 <jrosser> oh i see, sure yes
15:44:34 <noonedeadpunk> I kind of like the idea
15:44:55 <noonedeadpunk> still pretty nasty, but well...
15:45:17 <noonedeadpunk> it could be even worse
15:45:54 <jrosser> alternatively we make a galera_lib_main.yml / galera_dev_main.yml or something
15:45:55 <noonedeadpunk> oh, and I also pretty strugle with passing tempest for manila on centos... It's failing on connecting instance via SSH...
15:46:10 <noonedeadpunk> well, yes, we can do that
15:46:47 <jrosser> we just want to avoid dragging into loads of deps of the -dev packages wherever adjutant is installed
15:47:09 <jrosser> i'm assuming some wheel needs to be built on the repo server then installed on the adjutant container
15:47:35 <jrosser> so -dev stuff on the repo server and just the libs on the adjutant end to be tidiest
15:47:48 <noonedeadpunk> Since mysqlclient is not in requirements anymore - we can install it afterwards jsut inside already built venv
15:48:15 <noonedeadpunk> that means no wheels for this lib, but meh
15:48:52 <noonedeadpunk> iirc - it requires dev both during building wheels and normal operation of the library
15:49:32 <noonedeadpunk> So I was thnking about just adding pip task to install this single pacjkage outside of the python_venv_build
15:49:56 <noonedeadpunk> and then we need mysql-dev only for adjutant containers and not on repo
15:50:01 <spotz> trying to see if I can't get the matrix to line up so ping if needed:)
15:51:04 <noonedeadpunk> oh, looks like it's working now ! https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_687/789376/3/check/openstack-tox-docs/6878899/docs/admin/upgrades/compatability-matrix.html
15:52:07 <jrosser> noonedeadpunk: that does sound simpler, so adding a galera_dev_main.yml to galera_server would work nicely for that
15:54:03 <noonedeadpunk> I'm not quite sure I got the whole idea with galera_dev_main.yml Should we also care about repository adding there like we do for https://opendev.org/openstack/openstack-ansible-galera_server/src/branch/master/tasks/galera_install_apt.yml ?
15:54:33 <noonedeadpunk> oh, we can probably use same include there
15:54:37 <noonedeadpunk> agree
15:55:18 <noonedeadpunk> ok, I see now, let's do galera_dev_main.yml ideed
15:55:31 <noonedeadpunk> and use smth like tasks_from
15:56:31 <noonedeadpunk> and probably add there as well along with `galera_install_devel`? https://opendev.org/openstack/openstack-ansible-galera_server/src/branch/master/tasks/main.yml#L31
15:57:15 <openstackgerrit> Dmitriy Rabotyagov proposed openstack/openstack-ansible-os_manila master: [goal] Deprecate the JSON formatted policy file  https://review.opendev.org/c/openstack/openstack-ansible-os_manila/+/782244
15:58:08 <openstackgerrit> Dmitriy Rabotyagov proposed openstack/openstack-ansible master: [doc] Add OS compatability matrix  https://review.opendev.org/c/openstack/openstack-ansible/+/789376
15:58:13 <jrosser> it's a bit of a corner case really knowig if we should include the devel files anywhere else
15:58:18 <spotz> Ok this matrix is frustrating!It's like we need a blank column in between the OSes!
15:58:53 <noonedeadpunk> or btw releases as well?
15:59:19 <spotz> Let me see whhat you just patched, I was working on the older version and getting frustrated
15:59:33 <noonedeadpunk> nah, it's the same in terms of the output
16:00:19 <noonedeadpunk> yeah, I don't really like the way of it being rendered as well actually... It's more like a POC for discussion now I think
16:00:45 <spotz> Bah, So we need the checks and xs centerred under the row above and to move Debian and Suse over a littl so not to be squished next to stream I think
16:01:23 <noonedeadpunk> um
16:01:36 <spotz> I just can't get it to do it and I'd be worried that Atom might be changing the checks and Xs to patchh it up even if I got it to look right
16:02:05 <spotz> So the chheck under 16.04 should be centered
16:02:09 <spotz> for example
16:02:54 <noonedeadpunk> do you see it the same way? https://ibb.co/WpT3qPc
16:09:57 <noonedeadpunk> #endmeeting