16:02:05 <noonedeadpunk> #startmeeting openstack_ansible_meeting
16:02:06 <openstack> Meeting started Tue Jun 16 16:02:05 2020 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:09 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:02:10 <noonedeadpunk> #topic office hours
16:03:42 <noonedeadpunk> ok, so the  first thing I'd love to talk about - is cooperation with elastx
16:04:08 <spatel> jrosser: i found issue look like
16:04:33 <spatel> jrosser: look at /usr/lib/systemd/system/systemd-resolved.service  file
16:04:33 <noonedeadpunk> so for who missed that topic - folks have some specific user scenarios and I think we should help them with cotributing these things back to upstream
16:04:45 <spatel> ExecStart=!!/usr/lib/systemd/systemd-resolved   look like this is the issue
16:05:43 <gixx> Elastx would like to get as much as possibel upstream as well
16:06:30 <noonedeadpunk> jamesdenton can you help with integrating cisco specific thing?
16:06:49 <noonedeadpunk> I can help with adjutant and stuff if you want
16:07:12 <jamesdenton> yes, i can help with that. testing will be tough
16:07:34 <jamesdenton> gixx can you point me to that changes you've made to os_neutron role to deploy ACI bits?
16:07:40 <noonedeadpunk> I'd say let's leave reall functional testing in CI as for now...
16:08:02 <gixx> Yes sure, give me a moment
16:08:06 <noonedeadpunk> I guess it's https://github.com/elastx/openstack-ansible-os_neutron/tree/opflex/queens
16:08:28 <jamesdenton> those opflex packages require Cisco creds to download, don't they?
16:08:51 <gixx> That's the branch we're using
16:09:20 <gixx> Hmm not sure. All sources are available publicly on their github page
16:09:46 <gixx> But the pre-built binaries might be locked behind a login page
16:10:13 <jamesdenton> gotcha
16:10:34 <gixx> We build all python packages from source. It's only one package (not python) that we use their binary for.
16:10:35 <noonedeadpunk> eventually we can just make variables to set to access closed area
16:11:02 <noonedeadpunk> and if they are not provided, just omit that block
16:12:20 <gixx> It's possible
16:13:27 <noonedeadpunk> ok, and I'm about to push a patch to create another repository for os_adjutant role (unless you want to do that)
16:13:45 <gixx> We've built to you set neutron_plugin_type to opflex to load it, maybe you can run a check on that
16:14:09 <gixx> Sure, go ahead
16:14:18 <jamesdenton> cool
16:14:52 <noonedeadpunk> the question is how we're going to move content. And this point, I'm a bit afraid that we can loose all your progress in terms of commits during move
16:15:37 <openstackgerrit> Georgina Shippey proposed openstack/openstack-ansible-plugins master: Identity providers can be created with specifed domain  https://review.opendev.org/735654
16:15:41 <noonedeadpunk> I will ask folks if we can clone current state of the repo but not sure if itcan be achieved
16:15:55 <gixx> Probably, not an issue for us (most commits from when we developed it are ugly)
16:16:43 <noonedeadpunk> also I'd replace copyrights on files with your own, and changed things a bit (like the way mysql or services are created) to fit current state of our roles.
16:17:30 <noonedeadpunk> as it's rackspace now https://github.com/elastx/openstack-ansible-os_adjutant/blob/master/defaults/main.yml#L2 :p
16:17:36 <gixx> That is probably healthy. I copied another role and started work on top of those files
16:18:08 <noonedeadpunk> yeah, that's totally fine :)
16:18:29 <noonedeadpunk> btw, have you tested to launch adjutant with uwsgi?
16:18:40 <gixx> Yes, we run it with uwsgi
16:18:42 <noonedeadpunk> that can be left for next stage thoiugh
16:19:36 <noonedeadpunk> just out of https://github.com/elastx/openstack-ansible-os_adjutant/blob/master/templates/adjutant-httpd.conf.j2#L8 it seems your an it with apache as wsgi
16:20:10 <noonedeadpunk> oh, btw, is it on frontend or behind haproxy for you?
16:20:12 <gixx> Oh, my bad. I must have misunderstood the technology
16:20:30 <noonedeadpunk> I was meaning https://uwsgi-docs.readthedocs.io/en/latest/
16:21:00 <gixx> Alright then no, we use apache as you mentioned
16:21:33 <noonedeadpunk> yeah, ok. we jsut moved almost all of our services under uwsgi, except horizon and keystone
16:21:40 <noonedeadpunk> and deploy it with https://opendev.org/openstack/ansible-role-uwsgi
16:22:07 <noonedeadpunk> I think we can leave apache as for now, but later think about move to uwsgi as well
16:22:18 <gixx> That's something to look into at the next stage
16:22:27 <noonedeadpunk> yeah, totally
16:23:19 <noonedeadpunk> btw, did you installed adjutant horizon plugin?
16:23:20 <gixx> I'm not up to date with what has happened in the latest release of OSA, I'll read up on it
16:23:54 <gixx> Yes, work of that can be found at https://github.com/elastx/openstack-ansible-os_horizon/tree/elastx/queens
16:24:07 <noonedeadpunk> oh, ok
16:24:51 <noonedeadpunk> oh, so you use cloudkitty as well?
16:25:06 <gixx> As previously mentioned we run queens so there are things that are unique to our installation that have to be replaced
16:25:30 <gixx> Yes, that's also a bit of an hack to get py3 working in queens hehe
16:26:22 <noonedeadpunk> tbh at this point I really pretty scared about the way you're going to upgrade...
16:26:45 <noonedeadpunk> but htat's complete another story
16:26:50 <gixx> It will be a challenge but we are aware of it
16:27:16 <gixx> We have quite good knowledge of OSA I would say. Lots of extra work but that's what we signed up for
16:27:46 <noonedeadpunk> Yeah, ok.
16:28:08 <noonedeadpunk> another thing, that we'll need to backport things so they work for you as well
16:28:27 <gixx> Such as?
16:28:31 <noonedeadpunk> I'm not sure I'll be able to create stable branches for adjutant for example
16:28:44 <gixx> Ah that's fine
16:29:12 <noonedeadpunk> but the point is, that we already started using collections, which is totally not supported in ansible of queens version
16:29:31 <gixx> We are aware that our installation is unique and that we have to support a lot of things ourselves. If we get things in upstream we have something to look forward to in later releases :)
16:30:27 <gixx> I don't think we have to focus too much on queens support. We want to upgrade as soon as Cisco release support for newer releases
16:30:36 <noonedeadpunk> I kinda have a dream to make things usable for you asap, so that you could profit from them
16:30:56 <gixx> Just today we were discussing that Rocky is looking like something we can test out in a few weeks
16:31:01 <noonedeadpunk> and just push things upstream at once :p
16:32:41 <noonedeadpunk> btw, you also wrote about some " large administrative burden" regarding pushing things straight to upstream
16:32:56 <noonedeadpunk> I guess we're pretty tolerant with that at the moment
16:33:10 <noonedeadpunk> the main issue I see is pretty big gap between versions
16:33:26 <noonedeadpunk> as things really changed dramatically since rocky
16:33:33 <gixx> Yes, it sounds a lot more promising now than when it was last discussed in Berlin
16:36:56 <noonedeadpunk> yeah, I hope it will work out in the end.
16:37:02 <gixx> I'll read up on changes in the newer releases and we can discuss in more detail in a couple of days
16:37:35 <gixx> Does that sound good to you?
16:37:46 <noonedeadpunk> I'm not sure they're all really good described, as we had some lack of resources after rax mostly left osa
16:38:27 <noonedeadpunk> but yeah, sure
16:39:57 <noonedeadpunk> ok, so another thing I'd like to raise, is our CI thing...
16:40:53 <noonedeadpunk> so starting from train, we don't really test our bumps in CI. This eventually means, that we don't test our tagged releases, but tests always run against stable/train
16:41:25 <noonedeadpunk> this happens because we started using zuul provided repos with required-projects
16:41:56 <noonedeadpunk> as a result we just deploy what zuul provides us, and it knows nothing about our bumps at the moment
16:43:57 <noonedeadpunk> eventually we can probably use override-checkout https://zuul-ci.org/docs/zuul/reference/job_def.html#attr-job.required-projects
16:44:18 <noonedeadpunk> but I have no idea at the moment, how to distinguish if there's a depends-on present...
16:46:46 <noonedeadpunk> other thing we can do - run a checkout later (like during https://opendev.org/openstack/openstack-ansible/src/branch/master/scripts/get-ansible-role-requirements.yml) but it still raises question of depends on stuff, and, services bumps...
16:48:38 <noonedeadpunk> and what makes things worse, that we found it out because of train being completely broken because of https://review.opendev.org/#/c/735404/
16:49:15 <noonedeadpunk> we can ofc bump specific version both in a-r-r and required-projects, but that is veeeery hacky....
16:49:49 <noonedeadpunk> or set remove not branch specific repos from required-projects
16:50:32 <noonedeadpunk> then we will be controlling their version while clonning but that leaves us without depends-on for that repos
16:51:15 <noonedeadpunk> maybe I should go and talk to zuul folks - maybe they'll suggest smth...
17:01:34 <noonedeadpunk> #endmeeting