16:05:32 <noonedeadpunk> #startmeeting openstack_ansible_meeting
16:05:33 <openstack> Meeting started Tue Jan 19 16:05:32 2021 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:05:34 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:05:36 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:06:01 <noonedeadpunk> we have smth to discuss I guess this week, so I'd suggest to moe bug triaghe to the end if we have time for it
16:06:08 <noonedeadpunk> #topic office hours
16:06:20 <jrosser> hello
16:06:45 <mgariepy> hello.
16:06:56 <noonedeadpunk> so you had awesome progress with new pip resolver
16:07:16 <jrosser> yeah, i was expecting tons of horrid stuff but it's not been so bad
16:07:22 <noonedeadpunk> I think now we stuck with really weird thing
16:07:46 <noonedeadpunk> (ie setupttols missing)?
16:07:57 <jrosser> i think i figured that, unfortunatley setuptools is in u-c, and we also have it in global-requirement-pins
16:08:26 <jrosser> so if they dont exactly match you have a constraint of setuptools==X simultaneous with setuptools==Y which isnt possible
16:09:05 <noonedeadpunk> and moreover virtualenv is also pinned
16:09:06 <jrosser> so thats kind of the remaining thing to figure out, if we still want to keep complete control of the setuptools version in the openstack-ansible repo
16:09:46 <jrosser> i was considering extending the repo server role to retrieve the u-c URL and create a filtered version with these things removed
16:10:10 <noonedeadpunk> so now requirements does not have prescedence over constraints? (I guess it was the case previously)
16:10:41 <noonedeadpunk> then we can kind of drop tempest as well...
16:10:57 <jrosser> it's possible that having one thing constrained twice now behaves differently
16:11:36 <jrosser> i'm not sure that this is true any more https://github.com/openstack/openstack-ansible/blob/master/global-requirement-pins.txt#L1-L4
16:12:36 <noonedeadpunk> seems that it's not since it does not override u-c anymore :(
16:12:44 <noonedeadpunk> which is really bad imo
16:15:27 <jrosser> so i think we should look at maintaining a file on the repo server which as an adjusted version of u-c
16:15:50 <noonedeadpunk> yeah you're right http://paste.openstack.org/show/801739/
16:16:38 <jrosser> yes i think thats why my patch was total fail before because of that mismatch
16:16:56 <noonedeadpunk> so it should filter out stuff that is in the defined list + what we have in global-requirement-pins.txt right?
16:17:17 <jrosser> yeah, sounds about right
16:17:43 <jrosser> we have to do it this way as u-c is passed directly into pip as a URL
16:17:44 <noonedeadpunk> And it's the change to python_venv_build I guess
16:18:01 <jrosser> the alternative is to create a variable which is a filtered version u-c as a list
16:18:34 <jrosser> but thats a very wide ranging change
16:18:56 <noonedeadpunk> I'd rather download and store it I guess. However, another tricky thing is not to download it each time
16:19:26 <noonedeadpunk> So we might need to get uri like you did with tempest, filter things out, and save to file afterwards
16:19:56 <noonedeadpunk> or having some temp file that will be common across each role run....
16:19:58 <noonedeadpunk> uh
16:21:00 <jrosser> need to have a look at how the variables are at the moment
16:21:15 <noonedeadpunk> well, at least that sounds like smth that can be done...
16:21:36 <jrosser> the roles use requirements_git_url
16:21:38 <noonedeadpunk> ok, anyway souds like some plan:)
16:21:53 <jrosser> sure, i'll take a look, feels like this is nearly done tbh
16:22:13 <noonedeadpunk> yeah, it does :)
16:22:48 <noonedeadpunk> ok, another thing. Changing policies to yaml. Change is pretty straightforward actually. But not sure about upgrade path
16:23:32 <noonedeadpunk> I think the best way is to make old policy.json absent at the same place where we will be placing ploicy.yaml
16:23:58 <noonedeadpunk> but that would mean we need to do cleanup in every single role afterwards
16:25:44 <noonedeadpunk> and having them dropped at some pre-stage (like in upgrade-utilities) is kind of too early I guess. And I'm not 100% sure, but are policies pre-loaded or read from disk with each request and do not require service restart?
16:26:16 <jrosser> i'm not sure, but i think gmann can probably give us good advice here
16:29:14 <noonedeadpunk> yeah...
16:31:57 <noonedeadpunk> Another thing was our SSL topic
16:32:17 <noonedeadpunk> I think we should at least create a repo for that and I wanted to ask about proper name for it:)
16:33:49 <noonedeadpunk> should we use smth like ansible-role-ssl or openstack-ansible-ssl?
16:34:03 <noonedeadpunk> I kind of don't have really good ideas about how it should be called...
16:35:00 <jrosser> hmm yes, naming is always hard
16:35:17 <jrosser> there was also service tokens, is that something we need to get done?
16:35:37 <jrosser> this sort of thing https://docs.openstack.org/cinder/latest/configuration/block-storage/service-token.html
16:40:09 <noonedeadpunk> hm... I think I started doing smth related a while ago...
16:40:25 <noonedeadpunk> but what we should reflect for sure is healthapi endpoints
16:40:54 <noonedeadpunk> *healthcheck
16:41:14 <noonedeadpunk> But not sure if the're here for all services...
16:45:22 <noonedeadpunk> keystone_authtoken.service_token_roles_required <- that one
16:46:19 <noonedeadpunk> I guess that's kind of related things?
16:46:26 <jrosser> yes
16:46:48 <noonedeadpunk> I'm pretty sure I was patching it somewhere, but can't recall...
16:47:25 <noonedeadpunk> ok, octavia, zun and masakari are patched at least...
16:51:12 <noonedeadpunk> healthcheck is this https://docs.openstack.org/keystone/latest/admin/health-check-middleware.html
16:51:23 <noonedeadpunk> and it should be pretty simple to adjust
16:52:10 <noonedeadpunk> just need to be sure about what services have implemented that
16:52:25 <noonedeadpunk> btw, have you read about Venus?
16:52:56 <noonedeadpunk> which is new log management service
16:54:05 <jrosser> i saw some stuff on the ML but not looked too much, though it did look very interesting
16:57:09 <openstackgerrit> Jonathan Rosser proposed openstack/ansible-hardening master: Fix linter errors  https://review.opendev.org/c/openstack/ansible-hardening/+/771481
16:58:07 <jrosser> noonedeadpunk: any thoughts on the many many patches like this https://review.opendev.org/c/openstack/ansible-role-python_venv_build/+/768689
16:58:12 <jrosser> do we abandon them?
16:58:53 <noonedeadpunk> I clean forgot to take care about them...
16:59:02 * noonedeadpunk writes down on top of todo list
16:59:38 <noonedeadpunk> Yes, I think we should abandon them and I should go to release team and ask how we should stop publishing renos for each repo....
17:00:27 <noonedeadpunk> #endmeeting