16:04:14 <odyssey4me> #startmeeting OpenStack-Ansible
16:04:15 <openstack> Meeting started Thu Feb  4 16:04:14 2016 UTC and is due to finish in 60 minutes.  The chair is odyssey4me. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:04:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:04:18 <openstack> The meeting name has been set to 'openstack_ansible'
16:04:24 <odyssey4me> #topic Rollcall & Agenda
16:04:34 <oneswig> o/
16:04:34 <spotz> \o/
16:04:37 <vdo> o/
16:04:57 <serverascode> o/
16:05:05 * mhayden multitasks :)
16:05:31 <jmccrory> hi
16:05:32 <automagically> o/
16:05:49 <palendae> o/
16:06:17 <TheIntern> o/
16:06:19 <odyssey4me> Howdy everyone! Sorry for the late start - my bad. I'm not great at multitasking. :/
16:06:44 <michaelgugino> here
16:07:04 <odyssey4me> ok, let's get to it.
16:07:14 <odyssey4me> #topic Mid-Cycle meetup
16:07:55 <odyssey4me> A quick update. It seems positive that we'll be able to make use of the Rackspace Vidyo infrastructure to include anyone who wants to in the mid cycle.
16:08:36 <automagically> So, remote participation will be possible?
16:08:43 <oneswig> Will the mid-cycle be colocated with the ops meetup, which I hear is fully booked?
16:08:45 <odyssey4me> I'm not sure how well it'll work, and clearly the time zone differences will interfere with full participation - but we'll give it a try.
16:09:05 <odyssey4me> oneswig No, we're doing our own day after the Ops mid-cycle.
16:09:29 <odyssey4me> We will have some chats at the Ops Mid Cycle, but we'll focus most of our own discussions and work on our dedicated day.
16:09:36 <oneswig> odyssey4me ok thanks
16:09:40 <spotz> odyssey4me - yeah vidyo!
16:10:11 <odyssey4me> I'm going to setup another ticket type in eventbrite to indicate remote participation.
16:10:27 <odyssey4me> I'll then send the link to people who sign up for those tickets. :)
16:10:55 <odyssey4me> #action odyssey4me to create remote partiicpation tickets and send a ML update indicating the availability thereof
16:12:33 <odyssey4me> any questions/comments?
16:12:53 <odyssey4me> #action odyssey4me to propose topics for discussion and work items for the mid cycle
16:12:59 <logan-> if you don't mind post a link in the osa channel too for people who get behind on ML ;)
16:13:30 <odyssey4me> #action odyssey4me to add a link to the details about the mid cycle to the IRC channel topic
16:13:41 <odyssey4me> :) hopefully that helps logan-
16:13:45 <logan-> ty
16:14:41 <odyssey4me> #topic Support for multiple availability zones
16:14:46 <odyssey4me> admin0 ping?
16:15:23 <odyssey4me> #link https://bugs.launchpad.net/openstack-ansible/+bug/1539803
16:15:24 <openstack> Launchpad bug 1539803 in openstack-ansible "enable support for availability zones for compute and services" [Undecided,Invalid]
16:15:54 <odyssey4me> ok, in the absence of the person who raised the topic, we'll move on
16:16:03 <odyssey4me> #topic Release Planning and Decisions
16:17:09 <odyssey4me> Do we have any particular patches or bugs that anyone is aware of that should hold back the tagging of the next releases in the next 18 hours?
16:19:25 <odyssey4me> ok, I'll take that as a no - so I'll be tagging later today or early tomorrow, whenever I get the time to do so
16:19:41 <odyssey4me> #topic Open discussion
16:20:00 <odyssey4me> OK - does anyone have a topic they'd like to raise or discussion to be had?
16:20:13 <odyssey4me> I think we should perhaps have a chat about the pattern for multi-OS?
16:20:17 <michaelgugino> I figured we'd continue with multi-os
16:20:20 <palendae> https://review.openstack.org/#/c/274932/ - mattt and cloudnull were discussing this being backported to liberty yesterday
16:20:39 <vdo> yup, midonet support later
16:20:48 <odyssey4me> ah, vdo you're here
16:20:54 <palendae> I would argue that doing so makes a hard requirement on upgrading to a specific liberty release before moving to Mitaka, so I'd think it shouldn't be backported
16:20:56 <odyssey4me> ok - you're on the agenda so let's do that quickly
16:21:04 <odyssey4me> #topic Midonet support
16:21:12 <odyssey4me> palendae michaelgugino we'll come back to those topics
16:21:16 <michaelgugino> ok
16:21:24 <michaelgugino> ping me please, I'm in another meeting.
16:21:27 <odyssey4me> vdo it's your floor for no more than 10 mins
16:22:14 <vdo> ok, I would like to add midonet support to the project
16:22:21 <vdo> well at least midonet plugin
16:22:46 <vdo> As I understood from the docs that should be extended outside of OSA
16:22:58 <vdo> https://github.com/midonet/midonet-openstack-ansible (WIP)
16:23:05 <odyssey4me> sounds good vdo - have you managed to build an AIO and take a look through the existing patterns?
16:23:20 <vdo> yes, AIO
16:23:51 <palendae> vdo: Are cassandra and zookeeper hard requirements?
16:23:52 <vdo> I've added zookeeper service successfully to it following your patterns
16:24:04 <vdo> cassandra maybe not, zookeeper for sure
16:24:23 <palendae> vdo: Ok, I wrote the extending docs, I think I conveyed a wrong impression
16:24:23 <odyssey4me> looks interesting, thanks for sharing your WIP !
16:25:10 <vdo> roles are already in galaxy, but some code needs to be added
16:25:16 <odyssey4me> so vdo putting together your own Proof of Concept in your own repo is a great starting point
16:25:24 <vdo> very similar to plumgrid
16:25:43 <vdo> k
16:25:52 <odyssey4me> sounds good - do you need any active assistance?
16:26:18 <logan-> vdo: i have no idea if it is any value to you but I added projectcalico support for OSA in this branch https://github.com/logan2211/openstack-ansible/tree/liberty-calico. their plugin requires building etcd containers etc so there are roles built out for all of that
16:26:26 <odyssey4me> I think once you have a working AIO implementation then we can discuss next steps in terms of actually integrating into the stack's code base.
16:26:49 <vdo> oks
16:27:00 <odyssey4me> wow logan- you are a rather busy fella :)
16:27:06 <vdo> no assitance for now
16:27:25 <vdo> thanks logan- I'll have a look
16:28:39 <odyssey4me> logan- that looks pretty good too - I'll examine that a little more deeply with the intent of adding a gate test scenario for that
16:29:06 <odyssey4me> ok, thanks for letting us know vdo - and I'm happy to see that you're managing to figure stuff out
16:29:25 <vdo> yes I'm on it... not full time though :)
16:29:36 <odyssey4me> as you should know by know, we're always available to assist whenever you need help in any way - just ask in #openstack-ansible
16:29:44 <odyssey4me> we're looking forward to that
16:29:55 <odyssey4me> ok, moving on
16:30:05 <vdo> thanks
16:30:06 <logan-> odyssey4me: cool
16:30:22 <odyssey4me> #topic New nova DB that sneaked in under the radar
16:30:58 <odyssey4me> with thanks to SamYaple's heads up, we discovered that nova sneaked in a new DB in Kilo
16:31:12 <odyssey4me> but nothing has used it until a recent patch in Mitaka
16:31:44 <odyssey4me> thus https://review.openstack.org/274932 implements the new DB
16:31:58 <odyssey4me> there's been some discussion around whether this should be backported into Liberty
16:32:03 <odyssey4me> any thoughts on that?
16:32:19 <jmccrory> not even mentioned in liberty install guide http://docs.openstack.org/liberty/install-guide-ubuntu/nova-controller-install.html#prerequisites
16:32:27 <palendae> jmccrory: Nope, it was added in Kilo and missed
16:32:51 <palendae> My downstream consumers are very resistance to having to upgrade to a minor version to jump to the next major
16:32:54 <odyssey4me> palendae cloudnull michaelgugino automagically jmccrory d34dh0r53 andymccr hughsaunders mattt ?
16:33:14 <odyssey4me> stevelle ?
16:33:14 <palendae> So that's my concern about adding it to Liberty - it makes getting that liberty minor version in a mandatory step before moving to Mitaka
16:33:19 <michaelgugino> I don't see a reason we can't bp it, it looks pretty self contained
16:34:00 <michaelgugino> maybe have it not deployed by default in liberty?
16:34:13 <stevelle> I'm defaulting to no backport
16:34:23 <jmccrory> think it should be ok to be included in just mitaka, seems like it'll get created only after the commit that makes use of it. so upgrades/greenfield installs to that point shouldn't have any issues
16:35:06 <odyssey4me> personally I don't really understand why it would need to be backported if it's not used in Liberty. I'd rather just see it appear in Mitaka and only backport it if it becomes a requirement.
16:35:13 <palendae> Yeah
16:35:19 <palendae> I'm not sure it would
16:35:31 <palendae> Since they (nova) missed it in liberty and just now started using
16:35:37 <odyssey4me> as with most things though, once the master commit merges then a backport can be proposed and discussed
16:35:40 <odyssey4me> (in the review)
16:35:50 <palendae> Fair enough
16:35:51 <odyssey4me> but my current stand is that it shouldn't be
16:36:37 <odyssey4me> as it will be a fairly important thingto note, I've asked for the patch to include a release note
16:36:55 <palendae> Yeah, worth having
16:37:17 <odyssey4me> palendae are you happy to leave the topic there?
16:37:23 <palendae> odyssey4me: yep
16:37:30 <odyssey4me> #topic Release notes
16:37:57 <odyssey4me> just briefly, I'd like to say that from now on I'm going to be asking a lot more often for docs/releasenotes with patches
16:38:12 <odyssey4me> I'd like all reviewers to do the same.
16:38:39 <odyssey4me> FYI: http://docs.openstack.org/developer/reno/usage.html#editing-a-release-note
16:39:05 <odyssey4me> there are plenty of types of release notes, and the notes can be duplicated under different headings
16:39:43 <odyssey4me> the idea is that once we cut the mitaka branch, most things that a deployer would need to start planning their upgrade strategy would be contained there
16:39:51 <odyssey4me> any questions/comments?
16:40:01 <palendae> Not from me - I'm all for that
16:40:09 <michaelgugino> can we have that page linked in our contrib section
16:40:30 <palendae> Yeah, that'd be good
16:40:42 <odyssey4me> michaelgugino it's already there - see the last point in http://docs.openstack.org/developer/openstack-ansible/developer-docs/contribute.html#general-guidelines-for-submitting-code
16:40:53 <odyssey4me> perhaps it should be more obvious?
16:41:29 <michaelgugino> if it's a requirement, it should be more towards the top I think.
16:41:34 <odyssey4me> FYI releasenotes are published here: http://docs.openstack.org/releasenotes/openstack-ansible/
16:42:03 <jmccrory> ah that's useful
16:43:17 <odyssey4me> I'm busy doing a trawl of git commits since the Liberty release and putting notes together. If anyone else wants to dive in and help that'd be very nice. :)
16:43:31 <odyssey4me> hmm, it seems that there's a bit of a bug there, we have more releasenotes here: http://docs.openstack.org/releasenotes/openstack-ansible/mitaka.html
16:43:56 <odyssey4me> I'll figure that out and get it fixed up
16:44:44 <odyssey4me> ok, moving on
16:44:49 <odyssey4me> #topic Multi-OS Support
16:45:15 <odyssey4me> #link https://review.openstack.org/274290
16:45:22 <odyssey4me> michaelgugino it's your floor :)
16:45:48 <michaelgugino> well, I've put together one of the more simple roles with support for CentOS 7
16:46:12 <michaelgugino> a few of us collaborated on the approach, and I'm happy with how it turned out.
16:46:43 <michaelgugino> and I think it gives us a good pathway forward.  I think supporting the bigger two, debian/redhat distros, is where the primary focus should be
16:47:04 <michaelgugino> if someone is interested in supporting arch or some other distro, it's fairly obvious how to integrate the necessary changes, IMO
16:47:22 <odyssey4me> agreed, and that is the goal - to make it obvious
16:47:35 <michaelgugino> What I'd like to do now is use this template to deploy to a host with systemd where we currently deploy upstart scripts manually.
16:47:45 <odyssey4me> the initial work doesn't need to target CentOS support necessarily, but it does need to make it obvious how to do so
16:48:08 <michaelgugino> Centos is easiest for me, as that's what I'm most familiar with.
16:48:25 <odyssey4me> great, if you're keen to tackle both at once, then I'm very happy to support that
16:48:45 <odyssey4me> there's an army of interested parties in the etherpad who've indicated that they're keen to help out
16:48:58 <odyssey4me> but yeah, next step will be to figure out systemd
16:49:29 <michaelgugino> I've got a few cycles right now, so I don't mind tackling some of it.  And, as discussed last week, we needed to iron out the example of how to do it
16:50:00 <michaelgugino> If everyone is satisfied with the layout, I will work on other roles.
16:50:09 <odyssey4me> michaelgugino I'll liaise with the other cores to finalise the pattern and get it merged, then I'll see if we can raise some people to go ahead and start work on applying the pattern while you work on establishing the pattern for systemd.
16:50:13 <michaelgugino> we need to discuss testing as well.
16:50:54 <odyssey4me> I can add a non-voting check to all the roles if that will aid the development/testing process?
16:50:55 <automagically> michaelgugino work on laying down the pattern and responding to feedback
16:51:02 <michaelgugino> but, that's not my area of expertise, so I'll leave that to everyone else ;)
16:51:03 <automagically> Whoops, nice work, rather
16:51:38 <automagically> The question I’d have about per-role gates is how do we target the gate check to a particular OS/platform
16:51:52 <odyssey4me> #action odyssey4me to add a non-voting CentOS build to all the roles to aid the Multi-OS development process
16:51:54 <palendae> I believe that's in the infra project definitions
16:51:57 <palendae> automagically:  ^
16:52:06 <automagically> Ah, new to me, will check it out
16:52:08 <palendae> They use a repo with jenkins job definitions
16:52:22 <palendae> https://github.com/openstack-infra/project-config/
16:52:27 <odyssey4me> automagically I'll share the config changes to you so that you can see how :)
16:52:33 <automagically> thx gents
16:53:22 <odyssey4me> initially it'll be an 'experimental' job, so it won't run every commit - it'll only run when you specifically ask it to
16:53:26 <odyssey4me> I'll help explain that once it's in
16:53:43 <michaelgugino> that all sounds good to me.
16:53:54 <odyssey4me> thanks michaelgugino great work on working through the feedback - happy to see someone take this work on!
16:54:13 <michaelgugino> you're welcome.  Happy to contribute.
16:54:49 <odyssey4me> #topic Open discussion
16:55:01 <odyssey4me> ok, we have 5 mins for any other topics
16:55:16 <michaelgugino> well, my team is still working on DVR integration.  I opened a blueprint, but I'm not really sure how to make a spec and all the other steps, but we're working on plays
16:55:17 <automagically> michaelgugino: I know you had opened a blueprint around adding support for DVR, do you still have any plans to work on that area?
16:55:23 <automagically> Ha, nice timing
16:55:47 <automagically> My team is very interested in contributing to the DVR spec and work
16:56:03 <odyssey4me> excellent
16:56:04 <logan-> i'm cuious if anyone has done multi-region deployments with osa
16:56:09 <logan-> curious*
16:56:30 <odyssey4me> logan- we did some research and drew some conclusions a while ago - I'll chat in the channel after the meeting about it
16:56:40 <logan-> ok thanks
16:56:58 <odyssey4me> automagically michaelgugino perhaps you guys should work on a spec draft in an etherpad, then submit it as a review?
16:57:01 <michaelgugino> The changes to the neutron role where the services can be moved around will help us implement dvr greatly.  I was having to implement a lot of logic, and now I just need to dev a couple roles and make new env.d files.
16:57:30 <odyssey4me> ah, nice michaelgugino I didn't know you were that far along
16:57:33 <palendae> michaelgugino: You can see some existing specs and the template in http://git.openstack.org/cgit/openstack/openstack-ansible-specs
16:57:36 <automagically> I was thinking that this looks like a good spec example to follow: https://review.openstack.org/#/c/273749/2/specs/mitaka/lbaasv2.rst,unified
16:57:49 <palendae> Yeah, that one was good
16:58:12 <odyssey4me> fyi the specs are all published once they merge to http://specs.openstack.org/openstack/openstack-ansible-specs/
16:58:18 <automagically> michaelgugino: Can you share your WIP on DVR via GitHub or similar?
16:58:34 <michaelgugino> okay, I bookmarked those pages for later review.
16:58:38 <automagically> And then we can add it to next week’s agenda for discussion
16:59:04 <automagically> In the meantime, I’m stoked to hear that you’ve gotten so far
16:59:08 <michaelgugino> I don't think we'll be ready by next week, but if we are I'll put it up somewhere.
16:59:38 <odyssey4me> michaelgugino even if it's not entirely in a working state, sharing can enable others to help out and get it moving quicker
16:59:49 <odyssey4me> ok, we're out of time - we can chat in the channel
16:59:58 <odyssey4me> automagically I'd suggest adding that to next week's agenda
17:00:06 <odyssey4me> Thank you all for your time!
17:00:09 <odyssey4me> #endmeeting