16:00:16 #startmeeting openstack_ansible_meeting 16:00:16 #link https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting 16:00:16 #topic Roll Call 16:00:18 Meeting started Thu Aug 3 16:00:16 2017 UTC and is due to finish in 60 minutes. The chair is spotz. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:23 The meeting name has been set to 'openstack_ansible_meeting' 16:01:49 o/ 16:01:52 o/ 16:01:54 o/ 16:01:55 :) 16:02:23 We'll give folks a few minutes before things get turned over to evrardjp 16:02:52 o/ 16:03:32 #topic Review action items from last week 16:03:36 #topic evrardjp working on doc for a phasing out bugs as opinion schedule 16:03:46 You're up evrardjp 16:04:00 I didn't get the chance to work on that, let's keep that for next week 16:04:21 next topic? 16:04:23 :D 16:04:25 #action evrardjp working on doc for a phasing out bugs as opinion schedule 16:04:30 #topic evrardjp to update the 'hack day' to be follow the sun 16:04:46 ok, so for that we have one date that works for most ppl that answered the poll 16:04:51 it's the 17th of august. 16:04:53 I 16:05:00 sorry for the typo there :p 16:05:29 Cool we got a day! 16:05:46 We'll play it by hear 16:06:04 Okie 16:06:07 ok that sin 2 weeks! 16:06:09 *in 16:06:09 depending on how shows up, probably only talking with each other on the chan, or I'll write an etherpad with priorities, and we can put our names on bugs 16:06:33 If we have another session, that would be either the 5 or the 7th of September. 16:06:44 (equal amount of votes) 16:07:21 let's see what we can do for the 17th, and schedule at that time. If need be, we can use these two extra dates to prepare the PTG. 16:07:35 (depending on ppl's availability I guess! :D) 16:07:44 that's all I had to say. 16:07:48 And we can hangout if needed 16:07:48 good good 16:08:07 #topic Topics for Discussion 16:08:13 #topic PTG - 11-15 September - Denver, Colorado 16:08:19 ok! 16:08:23 #link https://etherpad.openstack.org/p/osa-denver-PTG-planning 16:08:28 2 announcements on that 16:08:53 1. Travel support 2nd round is open until the 6th, so if you are interested in going and don't currently have funding - apply before the 6th (which is this weekend!) 16:09:29 #link https://openstackfoundation.formstack.com/forms/travelsupportptg_denver 16:10:04 also there are still rooms available in the block book hotel for the summit - so if you are going and havnt got accommodation check that out. 16:10:39 it would be cool if we could get a count of who will be there, so if youre going and could let us know that'd be appreciated :) 16:11:13 so far we have 5 ppl, its tracked on the etherpad, but logan- jmccrory mgariepy hwoarang - and anybody else, if you're going would be good to know :) 16:11:42 i think that is all for the PTG from my side. put ideas in the etherpad, look at the ideas in the etherpad, etherpad. 16:11:54 pad pad pad! 16:12:07 sweet we have a logan :D nice 16:12:18 :D 16:12:21 woot! 16:12:28 Let's talk CI at the PTG. 16:12:30 :D 16:13:20 Gonna miss you guys:( 16:13:42 :( 16:14:06 Maybe at the summit! :D 16:14:21 its ok spotz we know you have priorities... ... 16:14:40 Uh huh, you get me video link yet?:) 16:14:45 haha oh yeah damnit 16:14:47 lemme email 16:14:57 priorities...... :) 16:15:15 Ready to move on to Summit? 16:15:41 i believe so spotz! 16:15:45 o/ 16:15:48 #topic Sydney Summit talks - voting phase closes soon 16:15:59 #link https://etherpad.openstack.org/p/osa-sydney-summit 16:16:11 so i put a list of some OSA talks that i found - added to an etherpad 16:16:18 voting closes soon, like tonight i think 16:16:26 but i encourage you all to go and vote for whatever looks interesting to you! 16:16:37 Anne will be doing the talk solo if it gets through, I'm not going:( 16:17:01 NB - definitely dont just vote for it if its on the etherpad, it was more just a way to catalogue some talks that are OSA related that may be interesting, so vote for wahtevers interesting to you :) 16:17:23 my talk didnt get my name against it weirdly :P so its not being given by anybody apparently! 16:17:42 anyway - sydney is far away, but talk voting closes so go and vote for talks! 16:18:12 Voting closes tomorrow I believe but I just clicked all the links so it's easy! 16:19:19 #topic Release Planning and Decisions 16:19:26 You're still up boss 16:20:13 haha 16:20:16 SO! 16:20:24 we released newton/ocata versions that should be stable 16:20:35 feature freeze is next week followed by RC1 so we're finishing up features and getting the last things in 16:20:53 i think we'll have to push the py3 work to next cycle for the majority of cases, but the wsgi work is going along quite well (for projects that support it) 16:22:00 that is all! 16:22:03 Do you have a topic for reviews? 16:22:25 Well, all reviews are good to take right :) 16:22:45 I like to draw attention to https://review.openstack.org/#/c/484440/6 16:23:05 https://review.openstack.org/#/q/topic:bp/goal-deploy-api-in-wsgi is the api-wsgi blueprint 16:23:19 we also have majors dnf work in https://review.openstack.org/#/q/topic:bp/centos-and-dnf 16:23:43 ok 16:23:50 https://review.openstack.org/#/c/490482/ will unblock the master gate 16:26:04 Not sure we want to push this through but I've got comments on https://bugs.launchpad.net/openstack-ansible/+bug/1703621 16:26:04 Launchpad bug 1703621 in openstack-ansible "Appendix A conflict with /etc/openstack_deploy/openstack_user_config.yml.example" [Medium,Confirmed] - Assigned to Amy Marrich (amy-marrich) 16:26:32 o/ 16:26:35 sorry im late 16:27:50 cloudnull == slacker 16:28:33 moving on... 16:28:37 #topic Blueprint work 16:29:31 cloudnull: You ever do your thingy? 16:30:12 that sounded weird, and I'm suprised I don't see a gif from major. 16:30:40 I don't think mhayden is actually here cause he's the only otherone I know with a blueprint/spec 16:30:48 it's about hyper converged I guess? 16:30:50 * mhayden stumbles in 16:30:54 yeah 16:30:59 i covered the dnf bp before, i think thats going well 16:31:02 and otherwise its the wsgi work! 16:31:06 ok 16:31:20 the dnf stuff is moving along quickly -- just dealing with finicky gates 16:31:23 xgerman_: i'll review that patch today before i leave 16:31:30 thx 16:31:31 thanks to logan- for more firewall spec feedback 16:31:31 mhayden: yeah we need to . swift is being a pain 16:31:46 xgerman_: btw - i have added a patch to use uwsgi for the octavia api service 16:31:49 i'll revise the firewall spec to use a templated iptables ruleset instead 16:33:20 spotz: no. 16:33:24 this is what I do for templating: https://github.com/openstack/openstack-ansible-os_octavia/blob/master/defaults/main.yml#L317-L370 16:33:32 we will / have removed the hyperconverged bits 16:33:46 cool 16:33:46 mhayden: I think it's a good idea 16:33:57 cool mhayden. i am working on publishing some internal iptables stuff I lay down on our infra here, but https://github.com/ansible/ansible/issues/27494 is blocking me on that, so we'll see what happens. otherwise if ansible worked I would have had everything published by now :( 16:33:58 thanks xgerman_ 16:34:23 yeah, I think we should come up with an universal way of doing it. 16:34:35 +1 16:34:37 so octavia could use it 16:37:54 logan-: fun stuff. 16:39:47 Ready for Open Discussion? 16:40:31 guess so:) 16:40:39 #topic Open Discussion 16:41:59 yay open! 16:42:00 discussion! 16:42:36 as most have probably noticed there is now a 3rd party CI from Limestone Networks running integrated builds on the master and stable/ocata branches. it exercises some untested paths in OSA such as the unbound resolvers and calico networking. the configuration it lays down is published here https://gist.github.com/Logan2211/61395dfd05af1819673bb5232d14077f and noted in the console log. I am the POC if anyone has questions or concerns about 16:42:36 this CI 16:42:45 https://review.openstack.org/#/c/448850/ ready for reviews, if anyone could help there 16:43:16 logan-: that's great, that's the only thing I want to say. 16:43:58 jmccrory: will review. 16:45:03 logan-: are we good to go on https://review.openstack.org/#/q/topic:bridge-nf-call 16:45:14 the master one merged, but you ok for the backports? I see you accepted the master one 16:45:22 imo needs a reno 16:45:27 on the backports 16:45:27 cloudnull: ^ 16:45:36 is that something you could add in? 16:45:37 thats my only concern on those currently 16:45:42 thanks evrardjp 16:46:22 I am not sure about the impact of this bridge-nf-call, but that should be in the reno if possible. 16:47:21 it has a potentially large impact on deployers using firewall rules on the control plane hosts depending on their firewall configuration 16:47:54 since it causes the lxc bridged traffic to be exposed to netfilter rules on the host i think? 16:48:11 someone can correct me if i'm wrong there but thats my understanding 16:48:31 hopefully cloudnull will be about to discuss that 16:48:33 oh. 16:48:52 as long as thats understood and folks are comfortable backporting it i'm fine with it. it makes good sense in master at least 16:48:53 we talking about this https://review.openstack.org/#/q/topic:bridge-nf-call 16:49:17 yes 16:49:52 this came about because it was discovered that sec group rules on compute nodes we're meaningless if that option was reset 16:50:05 we set it to 0 in the initial deployment 16:50:20 and the lxb agent sets it to 1 on start 16:50:32 however if you rerun the openstack-hosts role it resets the value to 0 16:50:52 which then ignores all of the sec group rules in place on a given compute node 16:50:54 i think a fix needs to be made in the stable branches for sure, but im not sure if the fix is backporting this change or simply removing the setting from stable 16:51:15 not sure if the fix should be* 16:51:26 I think it should be backported as is. 16:51:46 on an existing deployment folks would have the setting in the sysctl file 16:52:14 which would on boot set it back to 0 and the agent would then set it to 1 but if that file is reloaded for any reason 16:52:19 it could expose a deployment 16:52:32 in master I could make the argument that we drop the setting all together 16:52:49 just let the deployer/host deal with whatever they want 16:53:06 however in existing clouds I think it makes sense to lock things down 16:53:53 all that said, my personal opinion is that we lock it down by default. 16:53:56 we could remove the sysctl in stable+master and reno it as a critical fix -- "restart your neutron lxb agent" 16:54:07 ++ 16:54:45 consensus reached? 16:54:46 simply running sysctl -w ... fixes the issue on effeted nodes where the setting has flapped 16:55:48 we could reno the adhoc ansible command in master for upgrades and remove the setting all together. 16:56:04 I'm good no matter. 16:56:42 the kernel defaults it to 1 right? 16:57:00 if there's no override in our sysctl 16:57:27 I believe so 16:58:09 2 minute warning 16:58:31 we can carry over to the channel 16:58:48 yeah I think it would be best. 16:59:08 Ok shutting us down 16:59:12 #endmeeting