16:00:27 <odyssey4me> #startmeeting OpenStack-Ansible
16:00:28 <openstack> Meeting started Thu May 26 16:00:27 2016 UTC and is due to finish in 60 minutes.  The chair is odyssey4me. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:31 <openstack> The meeting name has been set to 'openstack_ansible'
16:00:43 <odyssey4me> #topic Rollcall & agenda
16:01:00 <automagically_> o/
16:01:23 <evrardjp> o/
16:01:34 <michaelgugino> hi
16:02:16 <spotz> \o/
16:03:56 <jmccrory_> o/
16:04:01 <odyssey4me> alrighty, let's get going on it
16:04:03 <odyssey4me> #topic Review action items
16:04:54 <odyssey4me> I did request the releases for Liberty & Mitaka - they finally got processed today.
16:05:09 <asettle> Bit late o/
16:05:18 <odyssey4me> Our stable branch release requests now need to be reviewed by both the stable branch team and the release team.
16:05:35 <evrardjp> asettle: that's rude
16:05:45 <evrardjp> oh you meant for being there, not for the release
16:05:49 <evrardjp> ok
16:05:58 <asettle> evrardjp: wow dude. ha.
16:05:59 <evrardjp> ETA odyssey4me?
16:07:07 <odyssey4me> #info All stable branch releases now require a minimum of a two day lead time as they require reviews by both the stable team and the releases team.
16:07:27 <odyssey4me> evrardjp the last release requests got processed today - they were requested last week
16:07:37 <evrardjp> now I understand
16:07:53 <odyssey4me> it's just FYI - the process is now quite onerous and I'm trying to work with both teams to make it go quicker.
16:08:11 <odyssey4me> Another action item on me was to retire the py_from_git repo - that's in progress: https://review.openstack.org/#/q/status:open+topic:retire-repo
16:08:48 <odyssey4me> unfortunately a lot of -infra's reviewers have been in sprints for the last two weeks, so I'm not getting much traction on reviews
16:09:53 <odyssey4me> I have several waiting for reviews, and they're not getting attention even if I ask nicely: https://review.openstack.org/#/q/owner:jesse-pretorius+status:open+project:openstack-infra/project-config
16:10:00 <odyssey4me> Anyway, I'll keep at that.
16:10:18 <odyssey4me> #topic Tests Repo
16:10:27 <odyssey4me> andymccr Do you have an update?
16:11:03 <odyssey4me> ok, we'll come back to it if he joins up
16:11:06 <odyssey4me> #topic Mid Cycle Planning
16:11:46 <odyssey4me> We discussed three options last week, and only two were of any sort of appeal.
16:11:49 <asettle> odyssey4me: he's just logging on
16:11:54 <asettle> laptop crashed.
16:12:09 <odyssey4me> 1 - Have a fully co-located mid cycle, most likely in the US.
16:12:42 <odyssey4me> 2 - Have a rolling mid-cycle over multiple time zones, with handovers between co-located groups.
16:13:13 <odyssey4me> Have we got any further thoughts or information regarding dates, venues, etc?
16:13:52 <andymccr> o/ sorry for the delay - ready to loop back on test repos
16:14:19 <automagically_> I have not had a chance to determine which dates we could offer up to host in Philadelphia. Let me make a note to try to get that done this week
16:14:30 <odyssey4me> no worries andymccr - we'll get back to that shortly
16:15:43 <odyssey4me> ping jmccrory d34dh0r53 stevelle mattt hughsaunders andymccr mhayden re: mid cycle
16:16:36 <andymccr> no additional thoughts to last week - i think dates and ability to travel are the most important factor right now
16:17:29 <odyssey4me> ok, it seems like we don't have a decent quorum of cores here to make much of a decision either way, so I guess we'll have to defer that discussion to next week
16:17:42 <evrardjp> k
16:17:42 <stevelle> I'm here, no preset opinions on mid cycle
16:18:00 <stevelle> I really just want to get dates first
16:18:18 <jmccrory> either option still works for me, but yeah, the sooner we can get dates to better to work around vacations or anything else
16:18:24 <automagically_> #action automagically to determine potential dates for hosting
16:18:50 <odyssey4me> thanks automagically_
16:19:00 <odyssey4me> #topic Tests Repo
16:19:03 <odyssey4me> andymccr over to you
16:19:07 <automagically_> There was some discussion about hosting in San Antonio as well IIRC. Who owns the action item there for potential dates?
16:19:16 <automagically_> D’oh, sorry andymccr
16:19:26 <andymccr> ok So. I have a PoC finished: https://github.com/andymcc/openstack-ansible-testing-core
16:19:34 <andymccr> i ran into some blockers today with non-test related packaging issues
16:19:49 <andymccr> but i confirmed that glance/swift/keystone all worked before today and nova was basically finished (i think i fixed it).
16:19:56 <odyssey4me> #action odyssey4me to check on RAX hosting option in SAT, and dates
16:20:07 <andymccr> regardless, the point is to show how i split it out, and to show some additional questions/discussion points that may arise and things we can consider
16:20:42 <andymccr> tl;dr if people want to take a look at that repo and the links in the readme to see the changes and decide whether its a good idea or not, and and how we should do it and discuss!
16:21:03 <stevelle> queued!
16:21:23 <odyssey4me> thanks andymccr - and thanks for describing the intents in the README :)
16:21:42 <automagically_> Looks cool, digging into the repo now
16:21:44 <evrardjp> let's put this as an action point for next week?
16:21:48 <odyssey4me> #action all to take a look through, and ideally test https://github.com/andymcc/openstack-ansible-testing-core
16:22:59 <odyssey4me> yeah, I think it's best we discuss it generally over the week in the channel and next week we can raise any more things
16:23:14 <odyssey4me> #topic Astara
16:23:20 <odyssey4me> Is Phil Hopkins around?
16:23:26 <phil_h> THis is Phil
16:23:33 <phil_h> I am here!!
16:23:34 <odyssey4me> hi phil_h - over to you :)
16:23:45 <phil_h> Major has told me
16:24:04 <phil_h> that you have been looking at Octavia as a loadbalancing solution
16:24:26 <phil_h> I wanted to introduce you to Astara which can do the same thing
16:24:50 <phil_h> Similar to Octavia it uses Vms as the loadbalancer
16:25:22 <automagically_> mhayden and phil_h - Are we talking about what the use as the OSA “opinionated” out of the box implementation?
16:25:27 <phil_h> But with the additional feature that it can implement routers in a VM also
16:25:30 <automagically_> s/the/we
16:25:53 <automagically_> Or what OSA will support and document?
16:26:07 <phil_h> I think for the future
16:27:13 <odyssey4me> phil_h it sounds good, and we're happy to assist someone working with us to instrument the deployment of whichever components Astara provides - but we would want someone who knows and understands Asatara and is prepared to build and maintain any instrumentation in OSA for it on an ongoing basis
16:27:13 <phil_h> Astara can replace the standard neutron L# stuff and set up both routers and loadbalancers
16:27:45 <phil_h> I would be willing to help and I can recruit some of the Astara folks also
16:27:48 <odyssey4me> phil_h there is also similar instrumentation for PlumGRID and Nuage already, so there's a fair amount of prior art to work with
16:27:49 <automagically_> So, starting point would be an openstack-ansible-os_astara role
16:27:55 <automagically_> Perhaps?
16:28:02 <phil_h> Yes
16:28:24 <odyssey4me> automagically_ it depends...
16:28:32 <phil_h> I have a simle ansible role that can convert to astara
16:28:43 <phil_h> which could be used as a basis
16:28:48 <automagically_> Well, right…I’m just browsing the docs and it looks like there is talk of using diskimagebuilder to produce an LB appliance...
16:28:50 <phil_h> simle -> simple
16:28:51 <odyssey4me> both PlumGRID and Nuage maintain their own roles/playbooks to setup all their bits - we only have code to connect OSA with their bits
16:29:15 <automagically_> phil_h - Basing that off of http://docs.akanda.io/en/latest/loadbalancer.html
16:29:27 <phil_h> I think that is correct
16:29:59 <phil_h> Astara does use diskimagebuilder
16:30:12 <phil_h> to create VM images such as the loadbalancer
16:30:57 <phil_h> So what is the best way to proceed?
16:31:23 <odyssey4me> it appears that someone has registered a blueprint: https://blueprints.launchpad.net/openstack-ansible/+spec/add-support-for-astara
16:32:09 <phil_h> I will talk to Eric about it
16:32:21 <odyssey4me> phil_h the best starting point is probably to put together an etherpad with notes on what the components are and where the touch points are with the OSA implementation
16:32:53 <odyssey4me> phil_h you can use the PlumGRID and Nuage implementations as a reference to see how they work to give you ideas
16:33:03 <phil_h> I will get started on that and I will stay in touch with everyone
16:33:16 <odyssey4me> phil_h FYI http://docs.openstack.org/developer/openstack-ansible/install-guide/app-plumgrid.html
16:33:17 <phil_h> I will look at how they have things set up
16:33:26 <odyssey4me> phil_h also http://docs.openstack.org/developer/openstack-ansible/install-guide/app-nuage.html
16:33:45 <phil_h> Thanks
16:34:14 <odyssey4me> you'll see how that all works in the neutron role itself https://github.com/openstack/openstack-ansible-os_neutron and for nuage there's also a bit in the nova role https://github.com/openstack/openstack-ansible-os_nova
16:34:50 <odyssey4me> phil_h if you can make the next meeting with a prepared etherpad, then we can discuss it together and help work out the next steps with you
16:35:04 <phil_h> OK, Thanks
16:35:07 <odyssey4me> of course you're also welcome to ask questions in #openstack-ansible at any time
16:35:17 <phil_h> I will!!!!
16:35:25 <phil_h> or bug Major!!
16:35:42 <odyssey4me> heh, of course - you'll find plenty of peopl in the channel are always happy to help
16:36:04 <phil_h> understand, I just like to tweek him from time to time
16:36:23 <odyssey4me> alright, moving on
16:36:35 <odyssey4me> #topic Ubuntu 16.04 LTS support
16:36:37 <odyssey4me> #link https://etherpad.openstack.org/p/openstack-ansible-newton-ubuntu16-04
16:37:29 <automagically_> odyssey4me: Don’t forget #topic Deprecation of pip_lock_down please ;)
16:37:54 <odyssey4me> heh, you snuck that one in after my last refresh automagically_ :)
16:38:35 <odyssey4me> ok, so the only roles we haven't done the var moves for to cover the Newton-1 milestone are nova, rally, ironic and magnum
16:38:56 <odyssey4me> for rally there's a review that didn't pass the gate check
16:39:10 <michaelgugino> cloudnull did an incredible amount of work in the last work
16:39:11 <michaelgugino> *week
16:39:13 <automagically_> odyssey4me: Yeah, I need to circle back to that Rally one and debug the apt issue
16:39:28 <michaelgugino> I've been MIA working on internal sprints, I'm hoping to pick up nova possibly
16:39:30 <automagically_> And rally isn’t really core now, i.e. not integrated into gate
16:39:43 <odyssey4me> do we have any volunteers to take on the nova, ironic and magnum roles? remember that the Newton-1 goal is simply to apply the var pattern and have it pass the Trusty gate check, nothing more
16:39:44 <michaelgugino> unless someone else wants it
16:39:59 <jmccrory> i'll take magnum
16:40:14 <odyssey4me> please add your name to the etherpad, thanks jmccrory
16:40:20 <michaelgugino> <<< nova
16:40:27 <odyssey4me> thanks michaelgugino
16:41:13 <odyssey4me> and yeah, cloudnull did manage to cover a lot of ground in the last week - but thanks to everyone for pitching in
16:41:49 <odyssey4me> what is nice is that we now have some patterns to work with for systemd support, and I think all of the infrastructure roles are already working on at least Xenial
16:42:16 <odyssey4me> can we get a volunteer to do the ironic role?
16:42:45 <andymccr> i'll take a look
16:43:10 <odyssey4me> thanks andymccr
16:44:04 <odyssey4me> cool, Newton-1 is next week Thu/Fri
16:44:18 <odyssey4me> right, let's circle back
16:44:18 <automagically_> Really sneaks up
16:44:31 <odyssey4me> #topic Deprecation of pip_lockdown
16:44:36 <odyssey4me> automagically_ over to you
16:44:55 <automagically_> Just wanted to get eyes on https://review.openstack.org/#/c/313890/ as the desirable pattern moving forward
16:45:08 <automagically_> So we can unblock a whole raft of jmccrory patchs
16:45:32 <automagically_> Looks like odyssey4me and mattt had objections, just want to see if we can clear those up
16:46:35 * odyssey4me is reading the discussion again
16:47:37 <evrardjp> I'll read that too
16:47:53 <odyssey4me> I've just been wondering why we should specifically apply the var there?
16:48:25 <odyssey4me> why not just include the role as normal, then apply the lock-down in the playbooks
16:48:47 <odyssey4me> the trouble here is that we're adding yet another place to look for vars being set
16:48:55 <automagically_> odyssey4me: I’d be okay with that, but we are always going to set it to true in the playbooks...
16:49:08 <odyssey4me> we already have role defaults, group_vars, playbooks and overrides
16:49:31 <automagically_> Sure, but this one is not something deployers are going to need to view/override
16:49:36 <jmccrory> we're doing this already a few other roles: https://github.com/openstack/openstack-ansible-galera_client/blob/master/meta/main.yml#L37-L39 https://github.com/openstack/openstack-ansible-repo_build/blob/master/meta/main.yml#L33
16:49:36 <odyssey4me> automagically_ not always, I don't think - certainly not for the repo server
16:50:27 <odyssey4me> jmccrory is there a reason why those can't live in the defaults instead?
16:50:30 <automagically_> If we want to do it at the playbook level, than my earlier opinion on that review stands, which is that we should remove the hard role dependency altogether
16:50:33 <odyssey4me> the role defaults?
16:50:44 <automagically_> And pip install and config is a decision purely made at the playbook level
16:52:01 <automagically_> There really _is not_ a hard dependency as such, more of an order of operations. I think order of operations ownership between roles is largely a playbook-level concern, rather than a role concern
16:52:14 <odyssey4me> automagically_ I agree with you, but I know that cloudnull disagrees strongly and he's not present.
16:52:28 <automagically_> Ah, alright, then this won’t be the meeting we solve this in then ;)
16:52:30 <jmccrory> odyssey4me: they could, for the lock down case the same ternary could be a default as well.
16:52:46 <jmccrory> if the main concern is where the variable is defined
16:53:09 <automagically_> Agreed jmccrory. My remove the dependency altogether argument is a far more wide ranging and invasive one
16:53:29 <evrardjp> Could we analyse this and give feedback next week?
16:53:34 <automagically_> Anyway, sounds like we #action all table pip_lock_down deprecation discussion til cloudnull returns
16:53:35 <odyssey4me> automagically_ yeah, that's my concern with that - so I'm more inclined to let this through even if I don't like it
16:53:52 <automagically_> odyssey4me: ++
16:54:12 <evrardjp> Agreed too
16:54:16 <odyssey4me> I would prefer the vars not being set in meta if possible - it just makes it that extra level more frustrating to figure things out
16:54:37 <automagically_> So odyssey4me - you’ll +2 if it moves to role defaults
16:54:43 <odyssey4me> but as jmccrory has noted, we already have precedent
16:54:58 <evrardjp> the extra level is fine but for having a build dependencies system only IMO, not for using that directly
16:55:11 <evrardjp> but yeah, I'll analyse this further
16:55:24 <odyssey4me> automagically_ for this particular case, I really don't see why the role needs to activate the lock down at all
16:55:36 <automagically_> I know…and I agree
16:55:51 <odyssey4me> for the other cases jmccrory pointed out, yes I think those could happily live in role defaults instead
16:55:54 <evrardjp> then it's clearly a misuse of meta
16:55:56 <automagically_> But…may be worthwhile to take small steps here sufficient to drop the lockdown role
16:56:00 <automagically_> And then re-evaluate
16:56:10 <odyssey4me> automagically_ sure
16:56:26 <odyssey4me> jmccrory thoughts?
16:57:10 <jmccrory> i could see the lockdown var moved entirely to OSA's playbooks
16:57:42 <automagically_> jmccrory: And the role as well, or would you keep the role deps the way they are?
16:57:54 <odyssey4me> so if the var was set in the playbooks that need it, and the role still set as a dep then I'd be completely happy
16:57:56 <automagically_> We are nearly out of time, I didn’t expect this conversation to go so long
16:58:05 <jmccrory> only pip_install in os_ role deps, OSA playbook would lock it down
16:58:06 <odyssey4me> automagically_ further suggestion to remove the role dep can be explored later
16:58:40 <automagically_> agree
16:58:55 <odyssey4me> ok, we're pretty much out of time
16:59:01 <odyssey4me> thanks all!
16:59:04 <automagically_> jmccrory: Will you propose that review to show that pattern? I think we like it
16:59:04 <odyssey4me> #endmeeting