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