16:26:22 <noonedeadpunk> #startmeeting openstack_ansible_meeting
16:26:23 <openstack> Meeting started Tue Oct 27 16:26:22 2020 UTC and is due to finish in 60 minutes.  The chair is noonedeadpunk. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:26:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:26:26 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:27:03 <noonedeadpunk> #topic office hours
16:27:56 <noonedeadpunk> Well I realized we have some topics to discuss after PTG
16:28:17 <noonedeadpunk> first of all, I clean forgot to raise topic with our bugs
16:29:23 <noonedeadpunk> I think we need to somehow cleanup current bug reports, as there are tons of obsolete ones or issued for non supported releases
16:30:08 <jrosser> were do we say non supported is?
16:30:39 <noonedeadpunk> I was thinking about ones in EM
16:31:08 <noonedeadpunk> But we don't say this directly at the moment I think
16:31:58 <noonedeadpunk> but we can close them conditionally when we obviously see this is should not be relevant anymore
16:33:04 <noonedeadpunk> like https://bugs.launchpad.net/openstack-ansible/+bug/1736726
16:33:06 <openstack> Launchpad bug 1736726 in openstack-ansible "Pike update causes parallel restart of Galera containers" [High,Confirmed] - Assigned to Jesse Pretorius (jesse-pretorius)
16:33:13 <noonedeadpunk> I never faced this issue tbh
16:33:22 <noonedeadpunk> But it seemed relevant these days
16:33:58 <noonedeadpunk> or should we try to solve https://bugs.launchpad.net/openstack-ansible/+bug/1778663 ?
16:33:59 <openstack> Launchpad bug 1778663 in openstack-ansible "Pike→Queens upgrade fails on final step in run_upgrade.sh (running haproxy-install.yml)" [High,In progress] - Assigned to Antony Messerli (antonym)
16:33:59 <jrosser> i guess relatedly we should move one/some more releases to EM
16:34:15 <noonedeadpunk> well yes, it's stein...
16:34:55 <noonedeadpunk> I want to do last point release with fixed images and move to stable/stein branch afterwards
16:35:13 <noonedeadpunk> like we did for rocky
16:38:29 <noonedeadpunk> So ideas what should we do with pretty old bugs? Should we try to resolve them? Or close with saying that in case it happens for currently supported release please re-submit?
16:38:59 <noonedeadpunk> As I really want to start keeping track on our bugtracker
16:40:42 <jrosser> given we can only really actively support the later branches i would be closing the bugs where possible
16:40:43 <gshippey> https://bugs.launchpad.net/openstack-ansible/+bug/1744014 - have to still fix up my patch but hopefully we can get some movement on this one soon. I think we should cull the older bugs, especially if they're minor and ask for resubmission's where necessary.  https://bugs.launchpad.net/openstack-ansible/+bugs?orderby=-id&memo=&start=300&direction=backwards <- bugs listed oldest to newest, might be useful
16:40:44 <openstack> Launchpad bug 1744014 in openstack-ansible "[Docs] Expected Backups in OpenStack-Ansible" [Medium,Confirmed]
16:42:39 <noonedeadpunk> yeah, it is:)
16:43:20 <jrosser> some of this is really easy, its for deprecated things
16:43:42 <Adri2000> I wouldn't be shocked if older bugs, especially if no one can reproduce them on recent releases, were closed
16:43:54 <Adri2000> (even my bugs :))
16:44:16 <noonedeadpunk> #agreed to close old bugs for non supported / EM releases with asking to re-create in case still relevant
16:44:54 <noonedeadpunk> I will try to go through them
16:46:13 <noonedeadpunk> Regarding bug https://bugs.launchpad.net/openstack-ansible/+bug/1901619
16:46:15 <openstack> Launchpad bug 1901619 in openstack-ansible "Ansble-hardening role is not applied to containers" [Undecided,New]
16:46:25 <noonedeadpunk> I'd say it's invalid?
16:46:28 <noonedeadpunk> oh, wait
16:46:43 <SecOpsNinja> hi everyone. im  having a strange error iin nova api regargind oslo.messaging._drivers.impl_rabbit ... Connection failed: [Errno 113] EHOSTUNREACH (retrying in 2.0 seconds): OSError: [Errno 113] EHOSTUNREACH but i have confirmed that rabbitmq cluster is runing ok with 3 runing nodes and all the porst configured in /etc/nova/nova.conf are accesable using telnet test. what could be the cause o
16:46:43 <SecOpsNinja> f this failure?
16:46:47 <noonedeadpunk> let's first decide if we want to return recent bug triage?:)
16:48:19 <noonedeadpunk> I think that might be pretty useful to get other team opinion on bugs
16:48:47 <noonedeadpunk> and maybe will bring more involvment into meetings (hopefully but unlikely)
16:49:22 <noonedeadpunk> As I feel that doing triage was a good thing back then
16:49:40 <jrosser> i think getting more folk involved is good, particularly anyone using older releases
16:49:56 <gshippey> 👍
16:50:10 <openstackgerrit> Merged openstack/openstack-ansible-lxc_hosts stable/ussuri: Determine latest base image available  https://review.opendev.org/759298
16:50:38 <jrosser> mine tend to be N-1 age, others may have a different perspective
16:50:44 <jrosser> ebbex: is this something you can help with?
16:51:53 <noonedeadpunk> I think we here do N-1.5 or smth like this:) So not using every release but jumping through one, so doing upgrades on yearly basis
16:54:27 <noonedeadpunk> #agreed doing bug triage during meetings
16:54:39 <noonedeadpunk> so, https://bugs.launchpad.net/openstack-ansible/+bug/1901619 :)
16:54:40 <openstack> Launchpad bug 1901619 in openstack-ansible "Ansble-hardening role is not applied to containers" [Undecided,New]
16:55:01 <noonedeadpunk> anyone thinks we should run hardening against containers as well?
16:56:00 <gshippey> perhaps from a technical perspective, but doesnt the hardening role take ages to run
16:56:06 <noonedeadpunk> I don't think it's pretty useful there as we're using minimal images, time is taken from host and containers shouldn't be directly accesible
16:56:17 <noonedeadpunk> gshippey: well it's pretty fast
16:56:45 <gshippey> don't know why i feel it always takes an age - ignore me!
16:57:52 <noonedeadpunk> takes 2 mins according to ara:)
16:57:56 <noonedeadpunk> https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_da2/759229/4/check/openstack-ansible-deploy-infra_lxc-centos-8/da27ca7/logs/ara-report/playbooks/2.html
16:58:11 <noonedeadpunk> I think I know why - it has so many tasks....
16:58:53 <noonedeadpunk> so easy thing we can do if we want hardening to run against containers - is just change the order of execution in setup-hosts.yml
16:59:23 <noonedeadpunk> actually, hosts set is defined with a variable
16:59:32 <openstackgerrit> Merged openstack/openstack-ansible-lxc_hosts stable/train: Determine latest base image available  https://review.opendev.org/759299
16:59:41 <noonedeadpunk> so see no reason in not changing the order and allowing ppl to decide if they want it or not
17:01:53 <jrosser> they containers still do need some ssh
17:02:10 <jrosser> theres some rsync and things isnt there? and keystone key distribution
17:02:13 <jrosser> and rotation
17:03:32 <openstackgerrit> Dmitriy Rabotyagov (noonedeadpunk) proposed openstack/openstack-ansible master: Run hardening after container deployment  https://review.opendev.org/759907
17:03:54 <noonedeadpunk> well yes, I saw ssh running
17:04:14 <noonedeadpunk> But I thought that it's for repo server only
17:05:28 <noonedeadpunk> well we've returned it to the list of the packages but I forgot what removal of openssh breaks except repo
17:06:46 <noonedeadpunk> so should we try to run hardening against all hosts by default
17:06:48 <noonedeadpunk> ?
17:11:37 <jrosser> sorry just dealing with other things here
17:15:52 <noonedeadpunk> let me end meeting then and we can continue later:)
17:16:03 <noonedeadpunk> #endmeeting