16:01:46 <cloudnull> #startmeeting OpenStack Ansible Meeting 16:01:47 <openstack> Meeting started Thu Jul 23 16:01:46 2015 UTC and is due to finish in 60 minutes. The chair is cloudnull. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:51 <openstack> The meeting name has been set to 'openstack_ansible_meeting' 16:01:59 <palendae> o/ 16:02:02 <cloudnull> #topic rollcall 16:02:07 <palendae> o/ 16:02:09 <Apsu> o/ 16:02:22 <d34dh0r53> */ 16:02:25 <jwagner> o/ 16:02:51 <odyssey4me> o/ 16:03:23 <b3rnard0> hello 16:03:53 <sigmavirus24> o/ 16:05:23 * sigmavirus24 clears throat 16:05:44 <cloudnull> so i guess thats all of us 16:05:46 <cloudnull> ... 16:05:52 <cloudnull> #topic Review action items from last week 16:05:54 <palendae> Good meeting 16:05:55 <sigmavirus24> Better than some glance meetings attendance =P 16:06:21 <cloudnull> Regarding EPOC and pip - add more hours to the day so sigmavirus24 can put together a POC <- sigmavirus24 16:06:31 <cloudnull> *epoch 16:06:35 <sigmavirus24> Yeah, I haven't gotten to that yet 16:06:40 <sigmavirus24> Still need those hours 16:07:08 <cloudnull> #action add more hours to the day so sigmavirus24 can put together a POC for pip and epoch's 16:07:10 <cloudnull> carried 16:07:13 <palendae> Would that solely be part of the upgrade script? 16:07:19 <palendae> Or changes to yaprt? 16:07:31 <cloudnull> id assume either can be done. 16:07:43 <cloudnull> or both . 16:07:47 <palendae> Ok 16:07:48 <cloudnull> sigmavirus24: what did you have in mind 16:08:05 <sigmavirus24> I was thinking keep it in the upgrade script for now 16:08:12 <sigmavirus24> Or go for that to see if that alone will work 16:08:21 <palendae> May not be a bad idea to make the master upgrade script be kilo -> liberty at this point 16:08:24 <sigmavirus24> I don't think yaprt needs this, unless we want to force yaprt to build with epochs 16:08:38 <sigmavirus24> which will then be something that has to happen for every upgrade after that 16:08:38 <palendae> And any juno -> kilo upgrade stuff just goes straight to kilo 16:09:22 <cloudnull> ok next item 16:09:24 <cloudnull> reenable the successerator for a single retry within the gate. To be removed as soon as Ansible v2 drops upstream - someone 16:09:32 <cloudnull> this was done. 16:10:09 <cloudnull> #link https://review.openstack.org/#/c/203257/ 16:10:18 <sigmavirus24> :thumbsup: 16:10:23 <odyssey4me> :) 16:10:29 <cloudnull> next 16:10:31 <cloudnull> get a thread going on the mailing list surrounding issues with upgrading Kilo > Liberty - someone 16:10:56 <cloudnull> and we're carrying that until there are more hours in a day 16:10:58 <cloudnull> #action get a thread going on the mailing list surrounding issues with upgrading Kilo > Liberty - someone 16:11:08 <cloudnull> o/ jwitko :) 16:11:27 <jwitko> Hello! 16:11:29 <cloudnull> #topic Blueprints 16:11:40 <cloudnull> #link https://review.openstack.org/#/q/status:open+project:stackforge/os-ansible-deployment-specs,n,z 16:12:03 <cloudnull> we have a few open ones, please review them when you get a chance 16:12:26 <cloudnull> important ones IMHO are https://review.openstack.org/#/c/203708/ 16:12:37 <cloudnull> https://review.openstack.org/#/c/203706/ 16:12:42 <cloudnull> and https://review.openstack.org/#/c/203754/ 16:13:53 <cloudnull> also https://review.openstack.org/#/c/202373/1 16:13:59 <cloudnull> which is a clean up of the specs dir 16:14:21 <palendae> I will commit to getting at least one of those reviewed today 16:15:05 <odyssey4me> I've looked through most of them already and have posted some questions. I'll get through a few more tomorrow. 16:15:24 <palendae> cloudnull: Does the my.conf one depend on the v10 one at all? 16:15:40 <cloudnull> palendae: no 16:15:43 <palendae> k 16:17:35 <cloudnull> also we have https://review.openstack.org/#/c/205062/ which is a continuation of the work done by svg 16:17:52 <cloudnull> #link https://review.openstack.org/#/c/181957/ 16:18:49 <cloudnull> #topic Reviews 16:19:16 <cloudnull> anything that we want to highlight regarding open reviews ? 16:19:45 <odyssey4me> cloudnull I think that https://review.openstack.org/#/c/205062/ is a spec by our team to cover the work done by svg, but with our revisions in it 16:20:13 <cloudnull> yes 16:20:18 <odyssey4me> it'll become the blueprint for that work - the team will revise svg's patch and bring it up to date and do some heavy testing on it 16:20:27 <cloudnull> ++ 16:22:15 <cloudnull> in our open reviews we have a few inflight that would be good to get nailed down soon-ish https://review.openstack.org/#/q/starredby:cloudnull+status:open,n,z 16:23:01 <cloudnull> does anyone have any issues with backporting https://review.openstack.org/#/c/205008/ https://review.openstack.org/#/c/205056/ and https://review.openstack.org/#/c/204996/ 16:23:26 <cloudnull> i'd like to have them in Kilo, to rid ourselves of key distribution issues. 16:24:36 <odyssey4me> cloudnull I'm happy with that - I'm surprised that they built first time! 16:24:57 <cloudnull> #startvote Should we backort the new key distribution process? Yes, No, Maybe 16:24:58 <openstack> Begin voting on: Should we backort the new key distribution process? Valid vote options are Yes, No, Maybe. 16:24:59 <openstack> Vote using '#vote OPTION'. Only your last vote counts. 16:25:11 <odyssey4me> #vote yes 16:25:15 <cloudnull> #vote yes 16:25:39 <andymccr> #vote yes 16:25:46 <d34dh0r53> #vote yes 16:25:54 <palendae> #vote yes 16:25:57 <Apsu> #vote yes 16:26:18 <cloudnull> #showvote 16:26:18 <openstack> Yes (6): d34dh0r53, palendae, odyssey4me, andymccr, Apsu, cloudnull 16:26:43 <cloudnull> ok i think its safe to say its a yes. 16:26:46 <cloudnull> #endvote 16:26:46 <openstack> Voted on "Should we backort the new key distribution process?" Results are 16:26:47 <openstack> Yes (6): d34dh0r53, palendae, odyssey4me, andymccr, Apsu, cloudnull 16:26:49 <andymccr> done :D 16:27:25 <cloudnull> #action backport https://review.openstack.org/#/c/205008/ https://review.openstack.org/#/c/205056/ and https://review.openstack.org/#/c/204996/ to kilo - someone 16:27:38 <andymccr> already done 16:27:49 <cloudnull> sweet 16:28:01 <cloudnull> #topic Open discussion 16:28:21 <cloudnull> what do we want to talk about? its time for festivus . 16:28:43 <odyssey4me> we could do with some eyes on https://review.openstack.org/194474 - the Keystone SSL cert/key distribution 16:29:08 <odyssey4me> that review brings that into line with the same mechanism as is used for horizon and fixes a lot of the brokenness 16:29:36 <odyssey4me> it also appropriately fixes the haproxy configuration depending on whether you have Keystone setup with SSL or not 16:30:50 <cloudnull> can we modify the commit to use the process outlined by andymccr which is being done in swift ? or do you think that can be done in a dependent patch ? 16:31:10 <cloudnull> for ssl cert sync 16:31:19 <odyssey4me> cloudnull this one's thoroughly tested and consistent with all other ssl cert distributions 16:31:52 <odyssey4me> I'd like to try out the method discussed with andymccr, but that'll be when there's time for that in a subsequent patch. 16:32:02 <odyssey4me> this one works as-is and fixes a lot of broken 16:32:08 <andymccr> yeh i think if its working now lets mark as "to do:" work and get it done at some point 16:32:27 <cloudnull> ok 16:33:00 <cloudnull> ill get a review in on all that today 16:33:39 <odyssey4me> thanks 16:33:59 <cloudnull> everyones favorite topic https://review.openstack.org/#/c/204315/ 16:34:22 <sigmavirus24> cloudnull: oh? 16:34:29 <sigmavirus24> I don't recall that being my favorite topic =P 16:34:31 <cloudnull> trying to make gate runs happier in hpb4 16:34:39 <cloudnull> you kno w you love it :) 16:34:58 <sigmavirus24> Oh hpb4 is my favorite topic. Carry on =P 16:35:04 <cloudnull> this forces an update to happen in all containers and logs all the things in a new gate directory "http://logs.openstack.org/15/204315/8/check/os-ansible-deployment-dsvm-check-commit/a495ded/logs/ansible_cmd_logs/" 16:35:32 <odyssey4me> cloudnull not the neatest of logs, but something's better than nothing 16:35:48 <cloudnull> yea the ansible return data is kinda shit to read 16:36:15 <sigmavirus24> cloudnull: do we want to recheck that until we get it to hpb4? 16:36:19 <sigmavirus24> last run was against raxdfw 16:36:34 <odyssey4me> I don't think so - the best way we're going to get it running on hpcloud-b4 is to merge it in 16:37:17 <sigmavirus24> odyssey4me: I saw one of the last rechecks was "recheck -hp1 success" 16:37:22 <sigmavirus24> so I figured we could keep rolling the nodepool dice 16:37:58 <cloudnull> odyssey4me: i think i can make the return output from ansible better if i add in "--one-line" to the ansible commands 16:38:16 <cloudnull> it will be a lot to read on oneline however it wont be something like http://logs.openstack.org/15/204315/8/check/os-ansible-deployment-dsvm-check-commit/a495ded/logs/ansible_cmd_logs/force_apt_update/aio1_memcached_container-541276d9 16:38:45 <cloudnull> youre call. if you think it best to rev it 16:38:59 <Apsu> cloudnull: Why not pipe to python -m json.tool to format it a little? 16:39:45 <cloudnull> each log file is generated with per node. 16:39:55 <cloudnull> i guess we could do a post process 16:40:05 <odyssey4me> cloudnull I think it's fine as-is and can be improved in a later patch 16:40:09 <cloudnull> ok 16:40:14 <odyssey4me> for now we need some sort of diagnostics for hpcloud-b4 16:40:21 <cloudnull> ++ 16:40:28 <cloudnull> i hate hpb4 .. . 16:40:31 <odyssey4me> and we won't be getting it unless we recheck ad nauseum, or merge it 16:40:48 <cloudnull> okiedokie typie typie make it go :) 16:41:11 <cloudnull> what else we got ? 16:41:20 <odyssey4me> sigmavirus24 made it go :) 16:41:28 <cloudnull> sigmavirus24: for PTL 16:41:32 <cloudnull> :) 16:41:35 <sigmavirus24> of? 16:41:37 <cloudnull> yes 16:41:40 <sigmavirus24> -_- 16:42:35 <cloudnull> ah liberty keystone is unhappy here https://review.openstack.org/#/c/199126/ 16:42:49 <cloudnull> if someone is board it would be a great help to get that narrowed down 16:43:03 <cloudnull> if its an upstream issue or an us issue, idk 16:44:03 <odyssey4me> cloudnull on another issue - upstream kilo merged the urllib cap, do you plan to rev the SHA's next week? if so, we can remove our cap in the same review 16:44:21 <cloudnull> ah good point, 16:44:29 <cloudnull> i plan on being on vacation next week 16:44:32 <cloudnull> :) 16:45:06 <cloudnull> maybe we rev it today 16:45:13 <odyssey4me> cloudnull ah ok, we can chat a bit after this then - we have a few things to sort out for your absence 16:45:15 <cloudnull> and remove our cap 16:45:25 <cloudnull> FYI odyssey4me will be handling bussiness while im gone. 16:47:43 <Apsu> Meet the new boss, same as the old boss 16:48:02 <b3rnard0> what can possible go wrong? 16:48:07 <d34dh0r53> I for one welcome our UK overlords 16:48:14 <Apsu> ^ 16:48:36 <d34dh0r53> b3rnard0: you could forget a y? 16:49:34 <odyssey4me> lol 16:49:46 <odyssey4me> I suppose that we're done here? 16:50:12 <cloudnull> yup 16:50:32 <cloudnull> thanks everyone 16:50:35 <cloudnull> #endmeeting