16:00:40 <evrardjp> #startmeeting openstack_ansible_meeting 16:00:40 <openstack> Meeting started Tue Aug 1 16:00:40 2017 UTC and is due to finish in 60 minutes. The chair is evrardjp. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:44 <openstack> The meeting name has been set to 'openstack_ansible_meeting' 16:01:03 <evrardjp> #topic rollcall 16:01:18 <spotz> \o/ 16:01:19 <evrardjp> sorry for the lack of ping one hour before the meeting! 16:01:28 <evrardjp> You all know the drill ;) 16:01:29 <andymccr> im here but i need to leave in a few mins :( 16:02:02 <evrardjp> Ahah ok 16:02:10 <evrardjp> let's make it quick then 16:02:18 <evrardjp> #topic this week's bug 16:02:23 <evrardjp> #topic this week's bugs 16:02:34 <evrardjp> #link https://bugs.launchpad.net/openstack-ansible/+bug/1707265 16:02:34 <openstack> Launchpad bug 1707265 in openstack-ansible "config_template broken on ansible 2.3?" [Undecided,New] 16:04:31 <evrardjp> wasn't this recently fixed? 16:04:47 <andymccr> its not impacting other jobs, i wonder what the deal is there then 16:05:55 <logan-> not fixed yet 16:06:13 <logan-> it is broken when overrides are provided in 2.3 16:06:24 <evrardjp> yeah 16:06:25 <logan-> but not all overrides apparently, as the plugins gate still passes 16:06:58 <evrardjp> did you manage to split your openstack_user_config_overrides to see how it triggers? 16:06:58 <logan-> based on the error it sounds like it might be specific to yaml dumping, so maybe only yaml based templates 16:07:46 <logan-> let me try something real quick 16:08:18 <evrardjp> ok 16:10:23 <evrardjp> let's go onto next one then 16:10:41 <evrardjp> until proven confirmed 16:10:47 <evrardjp> next? 16:11:24 <logan-> well as far as confirming it, feel free to just use the regular openstack_user_config aio file and provide the overrides in my gist 16:11:42 <evrardjp> that's true :) 16:11:51 <evrardjp> I didn't got the chance to do it, sorry. 16:12:03 <evrardjp> I trust you on it anyway :p 16:12:16 <odyssey4me> I wonder if the unicode handling patch is the source of all the misery 16:13:20 <odyssey4me> sorry, this one I meant https://github.com/openstack/openstack-ansible-plugins/commit/76d5f02a32465028b47347048dde96533595036b 16:13:57 <odyssey4me> nah, that looks fine 16:14:18 <odyssey4me> anyway - apologies for the diversion 16:16:00 <evrardjp> ok let's move to something else 16:16:06 <evrardjp> we are losing time on the first bug 16:16:13 <evrardjp> #link https://bugs.launchpad.net/openstack-ansible/+bug/1707220 16:16:13 <openstack> Launchpad bug 1707220 in openstack-ansible "Swift Erasure Code fails with liberasurecode 1.4.0 on CentOS" [Undecided,New] 16:16:42 <odyssey4me> looks like things are happening there 16:17:08 <evrardjp> yeah, should mark this as confirmed, and low "scheduled to fix soon" 16:17:16 <odyssey4me> perhaps confirm, mark in progress and assign to andy? 16:17:37 <evrardjp> in progress low andy is ok 16:18:05 <evrardjp> next 16:18:07 <evrardjp> #link https://bugs.launchpad.net/openstack-ansible/+bug/1707142 16:18:07 <openstack> Launchpad bug 1707142 in openstack-ansible "pip_install: "The following packages cannot be authenticated"" [Undecided,New] 16:18:08 <odyssey4me> I'd say high actually, seeing as it's a breaking issue 16:18:38 <openstackgerrit> Kevin Carter (cloudnull) proposed openstack/openstack-ansible master: [WIP] Add nspawn container driver https://review.openstack.org/477017 16:20:24 <odyssey4me> we could perhaps switch to adding a key like we do for mariadb and such 16:20:31 <odyssey4me> instead of installing the package 16:20:35 <odyssey4me> but that is a little weird 16:21:13 <evrardjp> Well the thing is I didn't have the same issue on my latest ubuntu16.04 16:21:22 <evrardjp> but that's because it's intermittent 16:21:37 <odyssey4me> maybe add some retries to the install task? 16:22:17 <odyssey4me> I wondr where the real issue is here 16:22:34 <odyssey4me> maybe there's a race between the key being added to the keychain and the repo refresh being done? 16:24:02 <evrardjp> I don't know 16:24:15 <cloudnull> could be something with apt-cacher-ng 16:24:20 <odyssey4me> it'll be a tough one to confirm 16:24:28 <cloudnull> its proxy'ing through the repo server 16:24:29 <odyssey4me> hmm, that's true too 16:24:29 <evrardjp> cloudnull: oh... 16:24:37 <cloudnull> which is caching keys 16:24:45 <evrardjp> indeed 16:24:54 <cloudnull> so maybe there's a purge needed somewhere along the way ? 16:24:55 <odyssey4me> but the key is installed via a package 16:25:15 <evrardjp> well maybe there is vagrant cache too? 16:25:17 <odyssey4me> it could be that the metadata caching is an issue though 16:25:27 <cloudnull> ++ 16:25:39 <evrardjp> but the workarounds are weird to me 16:26:34 <odyssey4me> it is a little odd - the key install should actually be *less* reliable 16:27:54 <mw_> cloudnull: Hopefully a quick question for you. Is it possible to change the MTU of the lxcbr0 bridge that OSA creates? I've seen references to the `lxc_net_mtu` config that can be set in user_variables.yml in older versions of OSA, but not in the version recommended for Newton. I've tried setting it, but it doesn't seem to have any effect. Do you know if it still exists, or if there's another way to change it? 16:28:01 <evrardjp> I'll spin up the vagrant box 16:28:04 <evrardjp> and see how it goes 16:28:08 <evrardjp> or at least I will try 16:28:34 <evrardjp> let's talk about the next bug 16:28:37 <evrardjp> #link https://bugs.launchpad.net/openstack-ansible/+bug/1706595 16:28:37 <openstack> Launchpad bug 1706595 in openstack-ansible "Explicitly set file permissions on tasks" [Undecided,New] 16:28:50 <odyssey4me> mw_ it's all still there: https://github.com/openstack/openstack-ansible/blob/master/etc/openstack_deploy/openstack_user_config.yml.example#L164 16:29:34 <cloudnull> mw_: yes you can change the lxcbr0 mtu , let me grab the option you need to set 16:29:44 <cloudnull> what odyssey4me said 16:30:13 <evrardjp> I think it's a great idea 16:30:18 <evrardjp> confirmed wishlist 16:30:29 <odyssey4me> regarding the bug - I'd say it's wishlist, great idea for the lint test 16:30:39 <evrardjp> agreed 16:30:58 <evrardjp> next 16:31:01 <evrardjp> #link https://bugs.launchpad.net/openstack-ansible/+bug/1706446 16:31:02 <openstack> Launchpad bug 1706446 in openstack-ansible "Keystone bootstrap failed when using LDAP" [Undecided,New] 16:31:35 <evrardjp> mitaka is eol... 16:32:08 <evrardjp> I think the bug shows we need to improve our ldap testing. 16:32:57 <odyssey4me> that's not a mitaka upgrade 16:33:12 <evrardjp> venv is mitaka 16:33:12 <odyssey4me> keystone doesn't have a bootstrap in mitaka as far as I remember 16:33:40 <mw_> odyssey4me: Do I just need a new "network" entry in provider_networks for the lxcbr0 container_bridge and a container_mtu for that network? 16:33:45 <mw_> Is that how it's done now? 16:34:30 <odyssey4me> apparently there is:https://github.com/openstack/openstack-ansible-os_keystone/blob/mitaka-eol/tasks/keystone_service_setup.yml#L38 16:34:42 <odyssey4me> mw_ we're busy with bug triage right now, please wait until we're done 16:36:07 <mw_> Sorry, will do. 16:36:21 <odyssey4me> well, it's mitaka - there's nothing we can do for that, but if the issue is also valid for master then we can try to resolve it there 16:36:22 <evrardjp> I think it's low 16:36:34 <evrardjp> because of the amount of ppl working with ldap 16:36:44 <evrardjp> but I think there is a gap with our testing for ldap 16:36:49 <odyssey4me> ideally we need an ldap test in the keystone role 16:37:09 <evrardjp> what do you think? 16:37:17 <evrardjp> confirmed / low ? 16:37:34 <openstackgerrit> Logan V proposed openstack/openstack-ansible-plugins master: [DNM] Reproduce bug 1707265 https://review.openstack.org/489660 16:37:34 <openstack> bug 1707265 in openstack-ansible "config_template broken on ansible 2.3?" [Undecided,New] https://launchpad.net/bugs/1707265 16:37:42 <jmccrory> think it would be fixed by keystone here, https://review.openstack.org/#/c/293488/ 16:38:40 <evrardjp> jmccrory: 1y 5mo ago? 16:38:59 <evrardjp> that's like M timeline right? 16:39:14 <openstackgerrit> Kevin Carter (cloudnull) proposed openstack/openstack-ansible master: Use ansible-runtime python for internal scripts https://review.openstack.org/489661 16:39:15 <jmccrory> that made it into mitaka, wonder what tag it would've been for OSA 16:40:00 <openstackgerrit> Kevin Carter (cloudnull) proposed openstack/openstack-ansible master: Use ansible-runtime python for internal scripts https://review.openstack.org/489661 16:42:40 <jmccrory> keystone_admin_user_name probably needs to actually exist in LDAP too 16:42:40 <evrardjp> well mitaka-eol tag should get keystone mitaka-eol 16:42:47 <evrardjp> so we should be covered. 16:42:52 <evrardjp> if we ever run that 16:43:12 <odyssey4me> I don't think we managed ot update to mitaka-eol, but a user can do that if it's not included. 16:43:20 <odyssey4me> That's a good review to add to the bug though 16:44:02 <odyssey4me> yes, if I recall correctly if ou're using LDAP as the *only* back-end (which is not actually what keystone is designed for btw), then you have to precreate all the users 16:44:36 <odyssey4me> keystone is designed to have the services in SQL in the primary back-endand LDAP for users as a secondary back-end 16:45:17 <evrardjp> ok let's continue then 16:45:25 <evrardjp> I'll document this in the bug 16:45:48 <evrardjp> next 16:45:51 <evrardjp> #link https://bugs.launchpad.net/openstack-ansible/+bug/1706122 16:45:51 <openstack> Launchpad bug 1706122 in openstack-ansible "openstack-ansible rabbitmq installs latest release of erlang which is not supported" [Undecided,New] 16:46:47 <evrardjp> looks like valid and critical 16:46:47 <odyssey4me> cloudnull jmccrory I thought this was resolved? 16:47:17 <evrardjp> oh so better than confirmed, we could go fix released? 16:47:32 <openstackgerrit> Kevin Carter (cloudnull) proposed openstack/openstack-ansible master: Use ansible-runtime python for internal scripts https://review.openstack.org/489661 16:47:37 <jmccrory> https://review.openstack.org/#/c/478679/ 16:47:56 <cloudnull> yea that should be resolved. 16:48:15 <cloudnull> jmccrory: and i think that was backported to ocata 16:48:16 <cloudnull> ? 16:48:33 <jmccrory> yep, https://review.openstack.org/#/c/478548/ 16:48:39 <evrardjp> I'll mark at "reporter should give more info" 16:48:47 <evrardjp> with a link to the review 16:50:13 <evrardjp> next 16:50:21 <evrardjp> #link https://bugs.launchpad.net/openstack-ansible/+bug/1705476 16:50:21 <openstack> Launchpad bug 1705476 in openstack-ansible "AIO Builds for Newton & Ocata failing on Ubuntu 16.04 running on Virtual Box (exact same process works OK on Rackspace Public Cloud Ubuntu 16.04 Images)" [Undecided,New] - Assigned to Major Hayden (rackerhacker) 16:50:57 <evrardjp> I'll mark this is as incomplete, as we are waiting for feedback from Geoff 16:51:14 <evrardjp> next 16:51:16 <evrardjp> #link https://bugs.launchpad.net/openstack-ansible/+bug/1705469 16:51:17 <openstack> Launchpad bug 1705469 in openstack-ansible "newton config-template change breaks previously working configuration" [Undecided,New] 16:52:10 <logan-> fwiw since we're back on config_template here's an isolated repro of the earlier bug https://review.openstack.org/#/c/489660/ 16:52:21 <logan-> cloudnull ^ 16:52:52 <cloudnull> oh excellent 16:52:59 <cloudnull> and that's in newton ? 16:53:20 <evrardjp> thanks logan- 16:53:51 <cloudnull> looks lke we may need to revert https://review.openstack.org/#/c/486754/ 16:53:54 <evrardjp> logan may I edit your patch? 16:53:57 <logan-> evrardjp go for it 16:54:06 <evrardjp> I'd like to write fixes-bug: 16:54:17 <evrardjp> in case we actually fix it there:p 16:54:38 <evrardjp> or alternatively, the revert. 16:54:50 <evrardjp> oh no that's just for the latest. 16:55:48 <odyssey4me> newton either needs fixing, or a revert of both https://review.openstack.org/484980 and https://review.openstack.org/486754 - I also asked prometheanfire to add tests to validate whether the patches fixed things, but that hasn't happened 16:56:18 <evrardjp> why did this merge? 16:56:34 <odyssey4me> no tests, therefore no ability to verify 16:56:56 <evrardjp> yeah, ok we'll improve next time :) 16:57:10 <evrardjp> ok so let's mark the bug as confirmed, and assign it to prometheanfire ? 16:57:19 <evrardjp> prometheanfire: are you there? 16:58:35 <evrardjp> I marked it as confirmed and high 16:59:25 <evrardjp> we are done for today 17:01:32 <evrardjp> #endmeeting