16:01:07 <noonedeadpunk> #startmeeting openstack_ansible_meeting
16:01:08 <openstack> Meeting started Tue Nov 24 16:01:07 2020 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:11 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:01:56 <gshippey> o/
16:02:23 <noonedeadpunk> o/
16:02:48 <jamesdenton> o/
16:03:00 <openstackgerrit> wu.chunyang proposed openstack/openstack-ansible-nspawn_container_create master: Dep's should be restricted by tox-constraints  https://review.opendev.org/c/openstack/openstack-ansible-nspawn_container_create/+/764001
16:03:09 <noonedeadpunk> #topic bug triage
16:03:18 <noonedeadpunk> so I see 2 new bugs atm
16:03:34 <noonedeadpunk> https://bugs.launchpad.net/openstack-ansible/+bug/1904935
16:03:37 <openstack> Launchpad bug 1904935 in openstack-ansible "Get swift rings ssh conection" [Undecided,New]
16:03:50 <noonedeadpunk> I think we should replace these nasty commands with synchronize module
16:03:52 <jrosser> o/ hello
16:04:59 <noonedeadpunk> it should respect as ansible_ssh_port and ssh config
16:05:34 <noonedeadpunk> and the second is rgw related https://bugs.launchpad.net/openstack-ansible/+bug/1905174
16:05:36 <openstack> Launchpad bug 1905174 in openstack-ansible "Using radosgw as a drop-in replacement for Swift in openstack-ansible" [Undecided,New]
16:07:24 <jrosser> hmm
16:07:28 <noonedeadpunk> well, I think we can add endpoints when rgw hosts are set or enabled?
16:07:37 <jrosser> S3 will never appear in horizon
16:07:42 <openstackgerrit> wu.chunyang proposed openstack/openstack-ansible-nspawn_hosts master: Dep's should be restricted by tox-constraints  https://review.opendev.org/c/openstack/openstack-ansible-nspawn_hosts/+/764002
16:07:44 <jrosser> there is a terminology problem there
16:07:53 <jrosser> you need swift to make horizon work
16:08:03 <jrosser> or rgw configured to serve swift
16:08:23 <noonedeadpunk> well yes, agree
16:08:38 <jrosser> and also the change to the name with .rgw on the end looks suspect to me
16:08:44 <noonedeadpunk> and I thought we have some variables to make this ahppen?
16:08:49 <jrosser> becasue  you may have more than one rgw process on the same host
16:09:20 <noonedeadpunk> well yes, that's what not very clear to me currentl;y
16:09:22 <openstackgerrit> wu.chunyang proposed openstack/openstack-ansible-openstack_hosts master: Dep's should be restricted by tox-constraints  https://review.opendev.org/c/openstack/openstack-ansible-openstack_hosts/+/764007
16:09:31 <jrosser> also these patches ^^
16:09:33 <noonedeadpunk> but it's indeed hwat we have in defaults https://opendev.org/openstack/openstack-ansible/src/branch/master/inventory/group_vars/ceph-rgw.yml#L3
16:09:57 <admin0> jamesdenton, didn't worked :(
16:10:01 <noonedeadpunk> these patches seem valid for me
16:10:14 <jamesdenton> admin0 ok - let's sync back up after this meeting
16:10:21 <admin0> sure
16:10:58 <jrosser> noonedeadpunk: are you sure it doesnt inherit install_command from [testenv] ?
16:11:11 <openstackgerrit> wu.chunyang proposed openstack/openstack-ansible-openstack_openrc master: Dep's should be restricted by tox-constraints  https://review.opendev.org/c/openstack/openstack-ansible-openstack_openrc/+/764008
16:11:29 <noonedeadpunk> ah
16:11:51 <noonedeadpunk> we did that weird way lol
16:11:59 <jrosser> i'm fairly well -2 on these unless thats shown to be currently broken
16:12:12 <noonedeadpunk> agree
16:12:28 <openstackgerrit> wu.chunyang proposed openstack/openstack-ansible-os_aodh master: Dep's should be restricted by tox-constraints  https://review.opendev.org/c/openstack/openstack-ansible-os_aodh/+/764009
16:13:17 <openstackgerrit> wu.chunyang proposed openstack/openstack-ansible-os_barbican master: Dep's should be restricted by tox-constraints  https://review.opendev.org/c/openstack/openstack-ansible-os_barbican/+/764010
16:13:45 <noonedeadpunk> regarding 1905174 I'm not sure honestly - I never used ceph ansible and deployed rgw with swift only manually, so not huge expert
16:14:14 <openstackgerrit> wu.chunyang proposed openstack/openstack-ansible-os_blazar master: Dep's should be restricted by tox-constraints  https://review.opendev.org/c/openstack/openstack-ansible-os_blazar/+/764011
16:14:23 <jrosser> we have a deployment like that here which could be used as a reference
16:14:28 <noonedeadpunk> while only I agree that we probably should double check that we have all set to make it as full swift replacement
16:14:34 <jrosser> though we did deploy completely seperate rgw for S3 and swift
16:14:57 <openstackgerrit> wu.chunyang proposed openstack/openstack-ansible-os_ceilometer master: Dep's should be restricted by tox-constraints  https://review.opendev.org/c/openstack/openstack-ansible-os_ceilometer/+/764012
16:15:06 <jrosser> i think you need to have swift served from / if you want to pass tempest tests
16:15:10 <noonedeadpunk> yeah would be awesome in case you could take a look
16:15:13 <jrosser> and also S3 must be served from /
16:15:21 <jrosser> so there is a bit of a conflict there
16:15:24 <openstackgerrit> wu.chunyang proposed openstack/openstack-ansible-os_cinder master: Dep's should be restricted by tox-constraints  https://review.opendev.org/c/openstack/openstack-ansible-os_cinder/+/764013
16:16:09 <noonedeadpunk> and there're no options to configure tempest for root?
16:17:44 <jrosser> i would have to get stuargr to look back at what we did
16:18:02 <noonedeadpunk> I think for SWIFT it will jsut take endpoint from keystone so it doesn't matter what root it is set?
16:18:17 <jrosser> yes thats right
16:19:35 <noonedeadpunk> so we can set S3 in / and SWIFT in /swift/v1/AUTH_%(project_id)s (at leat that's wjhat I have
16:20:24 <noonedeadpunk> but I have `client.rgw.{{ hostvars[inventory_hostname]['ansible_hostname'] }}` and it's working perfect for me....
16:21:10 <noonedeadpunk> ok
16:21:15 <noonedeadpunk> #topic office hours
16:21:56 <gshippey> any high priority patches that I can give a go reviewing?
16:22:24 <noonedeadpunk> https://review.opendev.org/c/openstack/openstack-ansible/+/763063 <- this one breaks bump bot
16:23:45 <noonedeadpunk> https://review.opendev.org/c/openstack/openstack-ansible-os_adjutant/+/756313 <- huge adjutant patch that would be awesome to merge
16:25:06 <noonedeadpunk> I had smth to discuss but didn't write down and clean forgot now :(
16:25:31 <noonedeadpunk> I guess the main point was to do some reviews to be able to branch asap
16:25:43 <noonedeadpunk> as I again failed to released it time :(
16:25:54 <noonedeadpunk> *to release in time
16:25:58 <jrosser> sure - we should have a big push on reviewing things in order to release
16:26:34 <noonedeadpunk> I've updated https://etherpad.opendev.org/p/osa-wallaby-ptg but probably worth creating new etherpad
16:26:48 <noonedeadpunk> also, I think we never merged spec for ssl
16:26:56 <noonedeadpunk> and no feedbacck on it
16:27:19 <openstackgerrit> Dmitriy Rabotyagov proposed openstack/openstack-ansible stable/ussuri: Add magnum tempest URL  https://review.opendev.org/c/openstack/openstack-ansible/+/763908
16:27:33 <noonedeadpunk> https://review.opendev.org/c/openstack/openstack-ansible-specs/+/758805 <- this one
16:27:38 <jrosser> :( sorry
16:27:58 <noonedeadpunk> so everyone interested are welcome to comment out and probably merge it one day
16:31:07 <noonedeadpunk> oh, well, have everyone heard about change of the ansible versioning process? :)
16:31:32 <noonedeadpunk> that they will make 3.0.0 instead of 2.11?
16:32:30 <noonedeadpunk> and will release in .... february?
16:33:00 <noonedeadpunk> so I think we should aim to release W with 3.0.0
16:33:15 <noonedeadpunk> the main challenge will be py3.8
16:33:51 <noonedeadpunk> https://www.reddit.com/r/ansible/comments/jwzwwf/ansible300_schedule_and_preview_of_400_schedule/
16:34:08 <jrosser> is that centos (!) that we will have a challenge with?
16:34:31 <noonedeadpunk> and partially bionic that we can techically drop
16:34:49 <jrosser> yeah, though i wonder if we can move to pyenv or something to get the actual python
16:35:04 <noonedeadpunk> yeah, that was my sggestion as well
16:35:21 <noonedeadpunk> it will increase deployment time for several minutes, but I think that should be generally ok
16:36:12 <noonedeadpunk> but it will be one more thing that we should take care about :(
16:37:59 <noonedeadpunk> ah, well, I placed also https://review.opendev.org/c/openstack/openstack-ansible-os_nova/+/763216 (which is not currentl;y working -had no time to look what specificly rong with it, but there should be something minor)
16:38:12 <noonedeadpunk> and I have no idea how we technically can backport this...
16:38:51 <noonedeadpunk> and I really had second thoughts about just masking systemd services to rollback to classic libvirt behaviour
16:41:13 <noonedeadpunk> as replacing libvirtd.service provided by system package is no fun....
16:47:21 * jrosser looks now gerrit is back
16:48:23 <jrosser> noonedeadpunk: do we need to replace the service file?
16:49:11 <noonedeadpunk> well, not replace, but I'm placing new one in /etc/systemd that should have prescedence over package provided one
16:49:29 <noonedeadpunk> and I'm trying to make it as much the same as I can
16:49:34 <jrosser> if there is just things like socket activation we could use a systemd dropin
16:49:40 <jrosser> rather than replace
16:50:01 <noonedeadpunk> yeah, sorry, it's really not replace but drop in
16:50:26 <noonedeadpunk> if I got you right
16:50:49 <noonedeadpunk> (I think we can't just partially override that way)
16:54:43 <jrosser> a systemd dropin can (i think) be used to selectively override the one that comes with the package
16:55:22 <jrosser> "Along with a unit file foo.service, a "drop-in" directory foo.service.d/ may exist. All files with the suffix ".conf" from this directory will be parsed after the unit file itself is parsed."
16:56:29 <jrosser> so if there is one thing that we need to add, like a [socket] section, then it can be carried in a seperate file and we just leave alone the package on, if it doesnt otherwise need changing
16:56:56 * jrosser not looked at the detail of this though
16:57:26 <noonedeadpunk> yeah, ofc I added sockets as a separate files. but I think that service itself needs changing to add requirement of these new sockets?
16:59:11 <jrosser> yeah so if you want to just change one thing out of the original config you can put foo.service.d/bar.conf [section] key=value
16:59:31 <jrosser> and that will change the setting from the original service unit
17:00:02 <noonedeadpunk> hm....
17:00:20 <jrosser> it's the systemd native way of doing overrides of distro provided unit files
17:00:31 <jrosser> so that things dont vanish when you update packages for example
17:01:31 <noonedeadpunk> I'm strugling to do it properly then....
17:02:14 <noonedeadpunk> ok, yes, I think it's better approach that mess I was trying to do
17:02:20 <noonedeadpunk> *then
17:03:03 <noonedeadpunk> but how to place socket's itself... I thought that adding sockets deployment to systemd-service role should be perfect
17:03:28 <noonedeadpunk> but the problem is that sockets should be part of the service (and reference it)
17:04:06 <noonedeadpunk> And I have no idea what the right structure should be in case we don't define service
17:04:35 <noonedeadpunk> That what I come up with for systemd role https://review.opendev.org/c/openstack/ansible-role-systemd_service/+/763194
17:04:55 <noonedeadpunk> but maybe I should do sockets just indepenently from service....
17:06:19 <jrosser> i think they should be seperate .socket units?
17:06:48 <admin0> are we still on meeting ?
17:07:16 <noonedeadpunk> yeah, but they should have `Service`  in `[Socket]`
17:07:20 <noonedeadpunk> #endmeeting