16:06:25 #startmeeting OpenStack-Ansible 16:06:25 Meeting started Thu Apr 14 16:06:25 2016 UTC and is due to finish in 60 minutes. The chair is odyssey4me. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:06:26 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:06:29 The meeting name has been set to 'openstack_ansible' 16:06:57 #topic Agenda & Rollcall 16:07:16 \o/ 16:07:20 \o 16:08:16 o/ 16:08:33 #link https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting 16:08:39 #link http://eavesdrop.openstack.org/meetings/openstack_ansible/2016/openstack_ansible.2016-04-07-16.01.html 16:09:27 I had two action items last week - one to instrument all repositories for release notes. That's done in terms of our repo prep, I need to actually submit the infra patch to activate the jobs. 16:09:54 #action odyssey4me to submit patches to OpenStack-CI to activate release notes jobs for all IRR's 16:10:38 the other action item was to post the session details and send a notification to the ML 16:10:54 #link http://lists.openstack.org/pipermail/openstack-dev/2016-April/091760.html 16:10:55 done 16:11:16 #topic Newton Summit Planning 16:11:33 o/ 16:11:49 automagically you posted an etherpad for the one session - can you post it now to add to the meeting reference 16:12:08 o/ 16:12:10 has anyone else managed to prep an etherpad and is looking for early feedback? 16:12:21 https://etherpad.openstack.org/p/openstack-ansible-newton-dynamic-inventory 16:12:37 #link https://etherpad.openstack.org/p/openstack-ansible-newton-dynamic-inventory 16:14:15 * odyssey4me looking 16:16:05 looks good to me 16:16:30 I encourage everyone to take a peek and if you manage to do any investigation and put patches together ahead of time, make notes and add them to the etherpad 16:16:41 the more prepared we all are, the more productive the work session will be 16:17:36 ++ to that ^ 16:18:19 ++ 16:18:44 alright, I'll be doing most of my summit prep next week and hope to propose a few review for consideration and discussion 16:19:13 any other thoughts, comments, questions on the topic of the summit before we move on? 16:19:50 none 16:19:57 none here 16:20:41 alrighty then 16:20:53 #topic Release Planning and Decisions 16:21:17 We're scheduled to release 13.0.1, 12.0.11, 11.2.14 next week Thu. 16:21:41 The current state of the branch heads looks good. It seems like we have a rather healthy, stable base of code. :) 16:22:05 the only issue that's a bit of a thorn in the side seems to be https://bugs.launchpad.net/openstack-ansible/+bug/1569446 16:22:07 Launchpad bug 1569446 in openstack-ansible "Secondary nodes fail to join galera cluster" [Critical,Confirmed] - Assigned to Darren Birkett (darren-birkett) 16:22:26 but it seems that mancdaz has managed to find a workaround that we can implement at least 16:22:28 not very started but #link https://etherpad.openstack.org/p/openstack-ansible-newton-role-docs 16:22:35 so we should have something suitable for those releases 16:23:24 spotz the link command needs to be at the start of the line I think 16:23:25 ie 16:23:30 #link https://etherpad.openstack.org/p/openstack-ansible-newton-role-docs 16:23:49 oops:) 16:23:59 :) 16:24:28 is anyone aware of any critical issues, or is anyone blocked on anything and needs assistance? 16:24:40 (related to any of the stable branches, or a master branch patch) 16:25:24 i don't 16:25:30 me neither 16:25:43 alrighty 16:25:50 #topic Blueprint work 16:26:23 any updates for any of the feature work? michaelgugino, automagically, vdo ? 16:26:36 logan- ^ 16:27:11 Still waiting on an internal team that’s been working OVS/DVR to get me their diffs so I can compare them to what we’ve already got in a submitted patch 16:27:12 will begin hacking on mitaka after the summit so next month perhaps ill have a review up for the calico stuff. 16:27:55 excellent logan- :) our network subsystem support is starting to really awrm up nicely :) 16:27:58 *warm 16:27:58 Thanks for the work 16:28:23 automagically great to hear that your team is on it too :) 16:28:35 #topic Open Discussion 16:28:50 well, we have plenty of time to shoot the breeze 16:28:50 have any of the broken out roles gotten multiple gate tests or scenarios tested in a single gate proposed yet? 16:29:10 stevelle well, the galera_server role does multiple things 16:29:13 I haven't seen, but there are a fair number of roles now 16:29:17 stevelle: the galera role will do an upgrade but its all in a single gate 16:29:37 stevelle and I think that the ironic role may too - IDK if you made it test both standalone and integrated cloudnull ? 16:29:50 odyssey4me: its all in a single gate 16:30:00 I'll peek at that then 16:30:02 yeah, all single job - but the preference is to pipeline things 16:30:17 afraid the galera upgrade isn't as comparable 16:30:23 ie if it's possible to build the env, test, reconfigure, test then that's what infra preferrs 16:30:24 we need to get the timeout higher to do more 16:30:31 ^ thats a concern for me 16:30:45 yep my nova + tempest functional test needs more time too :( 16:30:56 we may have to get more creative with keeping it under the timeout first 16:31:09 i think we just need to make it longer. 16:31:17 for instance it may make sense for some role to not bother building containers and just deploy everything on the host 16:31:41 I haven't done a time analysis yet because I still don't have convergence on gnocchi working in the gate but it seems strange to take a half hour to build 3 containers, install galera and 2 os_* services 16:31:44 i think that makes sense if the role doesnt have additional code paths when there is more than one instance 16:31:52 I also need to put in a patch for infra to mirror mariadb 16:32:03 if the role does something else when there is n+1 then we need to test that 16:32:18 cloudnull agreed, if n+1 is needed then containers make sense 16:32:20 do we have metrics different that just parsing logs? 16:32:54 I was planning to use tempest tests to verify a working deployment 16:32:56 we have 1.5 hours on the integrated gate, we should get the same for the roles too 16:33:00 need to collect additional logs for IRRs instead of just ansible output also 16:33:02 to see the time each step takes in average 16:33:12 +1 jmccrory 16:33:23 I won't have time to deploy tempest and run it right now 16:33:25 cloudnull infra is very reticent to increase timeouts 16:33:25 it'd also be nice to collect conf files too 16:33:41 stevelle if you cull the containers, might that help? 16:33:48 odyssey4me: then we need external CI and we need to make it voting. 16:33:56 yeah, we can add a log collection job - I'll do a patch for that 16:33:57 odyssey4me: can't cull containers when I have 2 services using apache 16:34:00 the infra roles are quick 16:34:14 but things like nova require building a cluster. 16:34:20 #action odyssey4me to add review for the collection of IRR job logs 16:35:13 which requires an image, networks, ect. 16:35:36 cloudnull external CI would be preferable, but that requires appropriate org sponsorship - I know that RPC may be ready to do that later in the cycle and automagically and I have spoken about it, but no hard plans yet. 16:35:54 nova can probably go full bare metal 16:36:06 I have agreement in principal within my org, but need to get the work prioritized 16:36:14 so i think our only option is to get infra to give the jobs more time 16:36:16 but it's easier putting things into containers 16:36:23 stevelle I think that perhaps we need to aim to adjust how we do the Apache bits so that we don't have them clashing 16:36:52 mattt nested virt could work 16:37:12 odyssey4me: agreed, and I would like to see abt fronting w/ nginx also 16:37:27 should apache be a separate role with horizon/keystone/whatever else providing vhost confs? 16:37:34 jmccrory: +1 16:37:36 jmccrory: +1 16:37:39 that would be ideal 16:37:45 jmccrory I would think so, yes. 16:37:47 Maybe re-use an existing apache role there? 16:37:51 I agree jmccrory 16:37:52 +1 jmccrory 16:37:52 looked like barbican wanted apache as well 16:38:06 There's likely a decent Apache role available in Galaxy that already supports multiple platforms and all that 16:38:07 some projects have timeouts as large as 190 16:38:12 jmccrory: They working on it last I was involved with them 16:38:25 idk think its an issue to ask for a full hour 16:38:41 +1 reuse a reverse-proxy if provided, identify roles to manage them -- ideally with optional container 16:38:50 cloudnull I'll do a request for an increased timeout, or perhaps try and get a per-role setting so that we can customised it based on the specific role needs 16:39:08 but I do want to ensure that we think creatively and try to reduce the moving parts in the role tests 16:39:16 odyssey4me what's the reason they are afraid? 16:39:22 of increasing the timeout 16:39:27 isn't it conditional on the repo? 16:39:37 based on our project config we're not setting a timeout for our roles. 16:39:37 evrardjp not afriad, they just have limited resources and longer timeouts mean that resources are held for longer 16:39:47 just for the intagrated build 16:40:18 I think getting it set to 60 should be an easy proposition 16:40:55 the reality is that deploying and functionally testing that takes longer than unit testing. 16:41:01 ^ 16:41:15 We're doing full deploys of stuff 16:41:16 also i'd rather us *not* think too creative to minimize time -- I'd like the tests to be representative of what will be deployed. 16:41:16 our peg isn't round 16:41:45 what stevelle said 16:42:16 Do the Puppet modules use infra? 16:42:20 they do . 16:42:29 I'd think they'd run into similar problems 16:42:39 their tests have a timeout of timeout: 60 16:42:39 Though Puppet's language is more like a full programming language 16:42:41 cloudnull we have the integrated build for the full functional test which is representative, and I hope that we can do the gate split to increase coverage 16:43:02 puppet, for instance, has 3 scenarios tested in their integrated build 16:44:23 so anyway, I'll discuss the timeouts with infra and find an appropriate solution which can be applied per role 16:44:42 but we should be creative in ensuring that we aren't wasting the time that we have to also ensure quick feedback 16:44:58 agree, best of both 16:45:35 also, less moving parts ensures a more focused test with a smaller chance of unrelated failures 16:45:48 i think that is fair 16:46:10 #action odyssey4me to submit a patch to increase the job timeout for selected roles 16:46:20 sorry lost connection for a min there. 16:47:34 #action odyssey4me to submit a patch to infra to mirror the mariadb repo to help reduce role job execution times, and reduce the risk of failure 16:48:16 alright, is there anything else I can help with to smooth the glide path to success? ;) 16:49:36 haha 16:49:45 is there anything else that anyone would like to raise? 16:49:45 you need to monitize your core competencies 16:49:53 :p 16:49:56 monitize? 16:50:07 monetize* 16:50:08 *monetize 16:50:30 :D 16:51:09 alrighty, if that's all then we're done for today 16:51:10 related to buzz words https://www.youtube.com/watch?v=GyV_UG60dD4 16:51:25 thank you all for participating - have an awesome day! 16:51:30 have a good one 16:51:31 #endmeeting