15:59:56 <mhayden> #startmeeting OpenStack-Ansible
15:59:58 <openstack> Meeting started Thu Jun  2 15:59:56 2016 UTC and is due to finish in 60 minutes.  The chair is mhayden. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:59:59 <rromans> mhayden: HERE
16:00:02 <openstack> The meeting name has been set to 'openstack_ansible'
16:00:16 <mhayden> #topic Rollcall & agenda
16:00:19 <odyssey4me> o/
16:00:22 <rromans> \o
16:00:27 <spotz> \o/
16:00:35 <mhayden> in case anyone needs a link, the agenda is here -> https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting
16:00:44 <automagically> o/
16:00:45 <evrardjp> o/
16:00:48 <ametts> o/
16:00:52 <keekz> o/
16:00:56 <antonym> o/
16:01:09 <mhayden> 𝘩𝘰𝘸𝘥𝘺
16:01:28 <cloudnull> yo
16:01:34 <andymccr> o/
16:01:43 <phil_h> Hello
16:02:25 * mhayden gives it one more minute
16:02:49 <jmccrory_> o/
16:03:29 <mhayden> okay, so let's do the thing :)
16:03:33 <mhayden> #topic Review action items
16:03:39 <asettle> \o/
16:03:40 <mhayden> #link http://eavesdrop.openstack.org/meetings/openstack_ansible/2016/openstack_ansible.2016-05-26-16.00.html
16:03:53 <mhayden> automagically: you were going to think about potential dates for hosting the midcycle?
16:04:29 <mhayden> and odyssey4me was going to talk about possibly hosting at Rackspace's HQ in San Antonio, along with dates
16:04:36 <mhayden> so i guess this is a general midcycle discussion here :)
16:04:52 <odyssey4me> mhayden my bad, I haven't managed to do the queries for dates and such
16:05:02 <automagically> Yes, we could host 60 from 8/29-31 if thats of interest
16:05:21 <odyssey4me> I marked it as an action item for me in the absense of other volunteers - if anyone wants to take over that aciton item I'd be happy to release it
16:05:39 <automagically> I have the space reserved temporarily, and would like to know if we want to use it in the next two weeks
16:05:46 <mhayden> odyssey4me: we had the security midcycle here last year and may have it here again -- i can ask someone who is working on that one
16:05:54 <odyssey4me> automagically wow, 60 is a lot... we'd likely only need room for 10-20, max 30 at a push
16:06:02 <mhayden> automagically: and yours is in Pennsylvania?
16:06:15 <automagically> Yes, downtown Phildelphia in the Comcast HQ
16:06:32 <mhayden> #info automagically has room for 60 people August 29-31 in Philadelphia at Comcast's HQ
16:06:35 <odyssey4me> it would be nice to have it hosted somewhere that's not SAT :)
16:06:46 <odyssey4me> for a change
16:06:47 <mhayden> we are having some wild weather as of late ...
16:07:12 <mhayden> should we get some Rackspace options as well and decide on this next week?
16:08:02 <odyssey4me> well, at the very least each of the core team members and any others who want to attend will need to validate whether they can get budget for a trip
16:08:07 <odyssey4me> jmccrory automagically cloudnull d34dh0r53 stevelle mattt hughsaunders andymccr mhayden ^
16:08:11 <mhayden> quite true
16:08:56 <odyssey4me> so we have a proposed date and venue, so now we get to work on figuring out who can make it and whether that'll be suitable
16:08:58 <mhayden> so it sounds like two actions: 1) get options on space at Rackspace and 2) determine who could travel to Philadelphia and/or San Antonio
16:09:08 <odyssey4me> yes
16:09:20 <mhayden> #action mhayden and odyssey4me to find out about Rackspace hosting options for midcycles
16:09:22 <odyssey4me> are we happy with a three day format?
16:09:23 <cloudnull> mhayden automagically: ++
16:09:29 <andymccr> i think 3 days is good.
16:09:36 <automagically> I’m good with 2 days
16:09:36 <mhayden> #action All community members should determine if they can get budget to travel to San Antonio or Philadelphia
16:09:41 <automagically> 3 days rather
16:09:42 <d34dh0r53> +1 on 3 days
16:09:45 <cloudnull> I think i can swing a philly trip
16:09:46 <mhayden> +1 on 3
16:09:55 <mhayden> sounds like we're in agreement on 3 days? any objections?
16:10:04 <cloudnull> +1 on 3 and !  SAT
16:10:13 <odyssey4me> nope, looks good to me - probably worth noting as an info item
16:10:20 <mhayden> #agreed OSA midcycle should be 3 days long
16:10:27 <mhayden> okay, are we good with this topic for now?
16:10:37 <automagically> AFK for a few
16:10:50 <mhayden> automagically: thanks for checking on space at Comcast! :)
16:10:58 <evrardjp> thanks indeed
16:11:00 <mhayden> next item is andymccr's repository -> https://github.com/andymcc/openstack-ansible-testing-core
16:11:15 <mhayden> the action from last week was to review it and ideally test
16:11:42 <evrardjp> I didn't test it :/
16:11:46 <evrardjp> I read it
16:11:52 <mhayden> i've looked over it but haven't tested it quite yet
16:11:53 <evrardjp> looks a good start
16:12:04 <mhayden> #link https://github.com/andymcc/openstack-ansible-testing-core
16:12:20 <andymccr> i tested it! :D but evrardjp had some additional ideas to try - would be good to get more feedback and ideas to improve/change/scrap
16:12:30 <mhayden> would someone like to volunteer to give it a test (besides andymccr) :)
16:12:31 <stevelle> I'm somewhat uncomfortable with the test vars being in a different repo for each role
16:12:38 <stevelle> that seems like a maintenance headache
16:12:45 <odyssey4me> I unfortunately haven't had the chance to give it a thorough look through.
16:13:12 <andymccr> stevelle: the vars are the same for each repo - the problem mostly is that we are duplicating the same sets of vars for each repo that uses a set role (e.g. keystone is common, or galera)
16:13:16 <odyssey4me> stevelle as I understood it from discussions with andymccr the test vars there are just a base which can be overridden by the role tests
16:13:19 <evrardjp> this is a first iteration, I guess we could indeed have a more integrated view?
16:13:25 <andymccr> but yeh they can be overridden.
16:13:38 <jmccrory> i tested the glance role, worked well. just ran into small issue with clone command of test playbooks in tox.ini
16:14:35 <stevelle> andymccr: my concern is that the test vars are not in the role repo. When the role changes and requires var changes it has an order of operations issue that will cause extra review traffic and challenging coordination of them
16:14:48 <odyssey4me> so we have the option of doing a full set of transition reviews to switch over to using this method, and trying it out for a while - we can always import the repo later
16:14:51 <stevelle> I fear the same for the tasks
16:14:55 <andymccr> stevelle: thats one of the main benefits though - because the vars are specific to one repo
16:15:10 <andymccr> whereas before if you changed a keystone var (for example) you would have to go into every other repo and change the var there --> 15 changes
16:15:29 * stevelle doesn't think he is being clear
16:16:00 <andymccr> you mean, id have to change the test repo before changing keystone in order to pass it?
16:16:15 <evrardjp> you want to set vars in the inventory only in this, this way we can override inside the roles?
16:16:38 <stevelle> andymccr: that is some of the concern yes
16:17:13 <automagically> back
16:17:20 <andymccr> stevelle: sure i guess its a trade off between that and having to manage 15 repo changes due to 1 change on a common repo.
16:17:35 <andymccr> but if there is a good way to get hte best of both! i'd prefer that.
16:17:40 <stevelle> we already have this coordination issue when we removed db create from the roles into the playbooks, it involves lots of extra steps
16:17:42 <automagically> I read through it and I like it
16:17:50 <automagically> I didn’t think I would, but I do. Nice work andymccr
16:18:01 <mhayden> would anyone be able to volunteer to test on it and help andymccr iterate?
16:18:37 <evrardjp> fine for me
16:18:43 <stevelle> If we can smooth that one point of friction I would be enthusiastic, other than that friction point this is really good.
16:18:44 <evrardjp> lacking time 'though
16:19:06 <odyssey4me> yeah, I'd ideally like another core at least to spend some quality time testing it out - and as evrardjp has good context with Ansible outside of OSA I think it'd be valuable for him to also test and help iterate
16:19:27 <mhayden> should we get a writeup about this repo along with its purpose out to the ML and ask for volunteers?
16:19:37 <mhayden> that would help me understand the goals
16:19:41 <evrardjp> yeah sure odyssey4me I'll help, don't worry :D
16:19:49 <automagically> That would be good. A specific call out of stevelle concerns would help contextualize
16:19:50 <asettle> Happy to help with the write-up. IF that's what's needed.
16:20:10 <mhayden> asettle: could you and andymccr work on an email to the ML?
16:20:18 <asettle> \o/ team ginger on the job
16:20:24 * mhayden chuckles
16:20:32 <jmccrory> i'll be out most of next week, but happy to help test as well
16:20:32 <asettle> Wow I just got massive stink eye from andymccr
16:20:41 <andymccr> ok. will get that done tomorrow
16:20:42 <automagically> haha ‘team ginger'
16:20:43 <mhayden> #action asettle and andymccr to send out an email to the mailing list about the testing repository
16:20:54 <mhayden> are we good to move on out of action items?
16:20:59 <andymccr> i think so!
16:21:15 <asettle> andymccr just wants to run from team ginger
16:21:17 <mhayden> asettle requested a little time earlier in the meeting since she needs to leav early, so i'll skip around here a little
16:21:20 <mhayden> #topic OSA Installation Guide restructure
16:21:25 <mhayden> asettle: you're up!
16:21:25 <asettle> Thanks mhayden
16:21:29 <asettle> Hey everybody!
16:21:44 <asettle> As some of you may know, we're focusing our efforts after the summit to rework the installation guide
16:21:56 <asettle> I've proposed a blueprint, and a subsequent spec with detailed information on how we're goin to do this
16:21:58 * mhayden is really pleased about these efforts :)
16:22:13 <asettle> I"m working alongside Darren Chan, who was at the summit and many of you met. His IA (information architecture) experience is assisting me in coming up with a new ToC
16:22:21 <asettle> I'd appreciate a community review of the spec: https://review.openstack.org/#/c/323471/
16:22:29 <mhayden> #link asettle's spec -> https://review.openstack.org/#/c/323471/
16:22:31 <asettle> We're looking to clarify a few points to ensure the community is happy with the output
16:22:48 <asettle> We need clarification on is whether we are simply documenting installation for a test environment and production environment
16:23:02 <asettle> And we've had a few conflicting suggestions that we also need to include examples and configs for role based documentation
16:23:15 <asettle> We're looking to get this spec approved asap, but we want to ensure everyone is on the same page
16:23:18 <asettle> If this makes sense
16:23:32 <asettle> The spec is still in WIP stage, but I will be removing that tag shortly and opening it up for full reviews.
16:23:41 <asettle> I'd like to have this approved within the next two weeks to get started on it
16:23:46 <asettle> Questions, comments, concerns?
16:23:51 * asettle drops mic
16:23:58 <odyssey4me> yeah, all agreeing on the end goal is important
16:24:10 <mhayden> thanks for doing this -- it should make it easier for new deployers to get through the manual and use opinionated defaults
16:24:24 <automagically> My commentary about the role docs is just that as we move a lot of config-specific doc out of the main guide, I want to make sure that it doesn’t just get removed, but rather ends up in the role-specific docs
16:24:33 <odyssey4me> this is going to be quite disruptive and can be easily misunderstood, so I'd like to ensure we're all agreed on the way it'll look at the end
16:24:33 <asettle> Very much so. I believe we have so far included everyone's thoughts and opinions from the summit, but please speak up if you feel like something else is required or missing
16:24:33 <mhayden> chapter four of the install guide currently hurts! :)
16:24:35 <automagically> I’m all for the re-orig
16:24:39 <automagically> re-org, rather
16:24:44 <asettle> automagically: yeah absolutely
16:24:54 <asettle> odyssey4me: yes, definitely.
16:25:03 <automagically> asettle: Great
16:25:03 <asettle> Does anyone have any immediate concerns?
16:25:22 <mhayden> none here
16:25:22 <evrardjp> none, if all the content is maintained
16:25:26 <odyssey4me> automagically yeah, I was thinking that step one would quite literally be a lift and shift of chapter 4 into the respective repositories
16:25:32 <palendae> I'd just echo automagically, making sure anything about roles is kept somewhere
16:25:39 <asettle> If not, please have a read through and comment. IF you'd prefer to talk directly to me, please just email me at alexandra.settle@rackspace.com
16:25:45 <evrardjp> whatever the way it is maintained
16:25:49 <mhayden> sounds good
16:26:05 <automagically> Will take another read through the proposed spec and add additional comments, but so far, I’m very supportive and happy to help however I can
16:26:09 <mhayden> okay, going back to discussion topics, we've covered the tests repo and the midcycle planning
16:26:13 <mhayden> so we're up to...
16:26:15 <asettle> palendae and automagically - to answer that properly, I believe there is a plan for it to be moved into a configuration guide, but that's in the future. In the immediate future moving it to the developer docs
16:26:17 <mhayden> #topic Astara
16:26:17 <odyssey4me> asettle everyone will need edit rights to see the comments and draft bits in https://docs.google.com/document/d/1WdcA7jIp8w1C52pJu4JmympFe8cOvcxi1I2E19Y6XYE/edit
16:26:22 <mhayden> phil_h: you're up
16:26:54 <mhayden> anything new for this week, phil_h?
16:26:54 <asettle> odyssey4me: I think it's best that that is just open for review at the moment. Otherwise we'll end up with a thousand different voices on a google doc when we should be concentrating our community efforts on the spec
16:26:55 <phil_h> yes, we have a blueprint up and a straw man in an etherpad
16:27:04 <phil_h> https://blueprints.launchpad.net/openstack-ansible/+spec/add-support-for-astara
16:27:11 <phil_h> https://etherpad.openstack.org/p/astara-openstack-ansible
16:27:14 <cloudnull> Nice!
16:27:15 <asettle> Okay, Alex out - tahnks everyone!
16:27:20 <mhayden> thanks, asettle
16:27:29 <evrardjp> thanks asettle
16:27:31 <phil_h> this is for adding a "chapter for astara"
16:27:55 <phil_h> We will use PlumGrid as a model
16:28:03 <automagically> Cool, thanks for the etherpad and blueprint phil_h
16:28:05 <mhayden> would a deployer need to choose Astara *or* neutron's l3 agent?
16:28:06 <cloudnull> phil_h: very cool.
16:28:29 <phil_h> I am hoping that they could use astara for the loadbalancer
16:28:41 <phil_h> and neutron l3 or astara for everything
16:28:47 <mhayden> got it
16:29:01 <phil_h> We need some testing on the mixed model
16:29:01 <mhayden> phil_h: what help could you use from the OSA community on your BP/etherpad?
16:29:22 <phil_h> If everyone can have a look and give us feedback
16:29:34 <mhayden> looks like odyssey4me is already on the case :P
16:29:58 <phil_h> thanks, I will have the astara folks on this also
16:30:29 <mhayden> sounds good -- i'd like to compare notes on Astara vs. Octavia for load balancers
16:30:30 <cloudnull> +1 for the boolean approach. Mixed referrence L3 + Astara doesn't seem like a good idea (if it's even possible).
16:30:58 <mhayden> #action All to review phil_h's etherpad on Astara and provide comments
16:31:02 <odyssey4me> cloudnull ++ agreed
16:31:08 <phil_h> The astara folks prefer the boolean approach
16:31:34 <odyssey4me> Certainly in terms of what we document and recommend it should be a binary approach. If people want to try and mix and match then they're on their own.
16:31:43 <mhayden> mixing sounds scary
16:31:45 <odyssey4me> We can't afford to stretch the test matrix.
16:32:05 <mhayden> wow, lots of stuff going into the etherpad already
16:32:07 <mhayden> nice
16:32:20 <phil_h> Thanks everyone
16:32:20 <mhayden> anything else on Astara, phil_h ?
16:32:27 <phil_h> not right now
16:32:37 <mhayden> #link phil_h's etherpad for Astara -> https://etherpad.openstack.org/p/astara-openstack-ansible
16:32:48 <mhayden> okay, next up...
16:32:57 <mhayden> #topic Deprecation of pip_lockdown
16:33:00 <mhayden> automagically: you're up! :)
16:33:11 * automagically scrambles to find the starred review
16:33:36 * mhayden plays jeopardy music
16:33:39 <mhayden> :)
16:33:47 <automagically> #link https://review.openstack.org/#/c/313878/
16:34:09 <automagically> That review is what we got proposed following the last meeting
16:34:16 <automagically> Thanks jmccrory for the quick turn-around on it
16:34:41 <automagically> I think we just need to get the feedback from odyssey4me resolved
16:34:44 <jmccrory> had some thoughts on where to go forward from there
16:35:04 <automagically> cloudnull: You were missing last week and we though you’d probably have some opinions, now is your chance to weigh in
16:35:13 * automagically hands mic to jmccrory
16:35:23 * cloudnull reading
16:35:31 <jmccrory> hard set the lockdown var to true in os playbooks, since pip_links are always to go be defined in group vars
16:36:02 <jmccrory> remove pip_lock_down dependency entirely from IRRs and just add the isolated option to pip_options for developer mode
16:36:29 <cloudnull> I think https://review.openstack.org/#/c/320216/10/meta/main.yml makes sense if we want to keep the API the same.
16:36:31 <automagically> I’d like to still test the length of pip_links which would allow a deployer to ignore the internal repo
16:36:45 <jmccrory> that way it'll avoid any existing lock down for both independent role use or it's they're deployed as part of integrated release
16:36:53 <cloudnull> If we're going to change it, keying off of links makes sense
16:36:58 <automagically> I agree entirely with the rest of that jmccrory
16:37:08 <odyssey4me> for the meta, all we need is the role inclusion
16:37:13 <cloudnull> as long as the links has a value of >=1
16:37:14 <jmccrory> sure length would work then, would be possible for deployment to override and empty it
16:37:14 <automagically> odyssey4me: ++
16:37:22 <automagically> yep jmccrory
16:37:27 <odyssey4me> it defaults to no lock down, so having the dep on developer mode makes no sense
16:37:43 <automagically> Consensus reached then it seems
16:37:45 <automagically> :D
16:38:04 <cloudnull> ++ jmccrory typie typie change all the open reviews :)
16:38:12 <odyssey4me> the only trick here is to cater for automagically's situation where he overrides the links in some builds, so the group_vars are negated
16:38:26 <jmccrory> yeah, was only in case someone wanted to set developer mode on a single role while doing an OSA deployment. and that's seems to have happened
16:38:28 <automagically> I _do_ appreciate being catered to
16:38:35 <mhayden> hah
16:38:42 <mhayden> so we're agree on this one? :)
16:38:49 <automagically> It seems we are
16:38:49 <mhayden> s/agree/agreed/ :)
16:38:50 <cloudnull> we can set that at runtime for a given role
16:38:51 <mhayden> woot
16:38:55 <stevelle> agreed here
16:38:56 <odyssey4me> jmccrory in that particular case a deployer has other options to negate the lock down
16:38:59 <jmccrory> https://bugs.launchpad.net/openstack-ansible/+bug/1585604
16:39:00 <openstack> Launchpad bug 1585604 in openstack-ansible "horizon_developer_mode does not work" [Undecided,New]
16:39:03 * automagically passes mic back to mhayden
16:39:04 <mhayden> automagically: all good on this topic?
16:39:06 <mhayden> woot
16:39:10 <mhayden> next up...
16:39:17 <mhayden> #topic Support for Xen via libvirt
16:39:20 <mhayden> and antonym is up!
16:39:27 <antonym> o/
16:39:34 <odyssey4me> welcome antonym
16:39:44 <antonym> how's it going?
16:40:00 <antonym> was chatting with major a bit yesterday about looking into libvirt and xen and he suggested we mention it here
16:40:21 <mhayden> let's just say that antonym works on a *very* large OpenStack cloud that happens to run on xen :)
16:40:21 <evrardjp> good indeed
16:40:26 <antonym> wanted to see what the thoughts were on adding it as a supported hypervisor to openstack-ansible
16:40:47 <automagically> Seems like something that might be popular
16:40:50 <antonym> was probably going to throw together a blueprint if it's something that has interest
16:40:53 <mhayden> since it's just another option in libvirt, it could work well
16:40:55 <odyssey4me> antonym it should be pretty easy I expect, probably not much more than extending https://github.com/openstack/openstack-ansible-os_nova/blob/master/defaults/main.yml#L93-L126
16:40:57 <mhayden> gate testing could get interesting
16:41:29 <antonym> odyssey4me: yeah, i had a proof of concept in december in openstack-ansible that built a vm using libvirt, needed to dig into the networking still
16:41:39 <antonym> but i don't think it should be a major effort
16:41:44 <evrardjp> Will this have a larger impact than nova? like a lots of changed due to specific ovs/cinder/glance way of doing things?
16:41:57 <evrardjp> just to be informed how it's planned :D
16:42:02 <odyssey4me> there's some work going in to support powervm too which is extending that and may introduce some more patterns which could be useful
16:42:20 <antonym> i think it aligns to kvm pretty well right now since it's mostly libvirt
16:42:48 <antonym> the xen guys have been busy stabilizing it too
16:42:55 <evrardjp> cool news
16:43:16 <mhayden> would we need a spec for this work?
16:43:21 <mhayden> i'm on the fence
16:43:23 <automagically> can’t hurt
16:43:26 <antonym> anyways just wanted to bring it up, sounds like there is some interest
16:43:35 <odyssey4me> antonym it would be ideal to have some sort of external CI checks in place to validate that any ongoing work doesn't break xen support, but if that's not possible then it's just going to place more responsibility on anyone using it to test properly before upgrading
16:43:38 <mhayden> antonym: want help building a spec + BP?
16:43:50 <antonym> mhayden: yeah, i can try and slap one together
16:44:02 <odyssey4me> yeah, it would be best to put the thoughts into a spec
16:44:03 <mhayden> #action antonym to build a blueprint and spec for Xen+libvirt support
16:44:10 <mhayden> thanks, antonym
16:44:16 <antonym> odyssey4me: yeah, i'm kinda new on the CI checks but it's something we should look into as well
16:44:18 <odyssey4me> the powervm spec will be a good one to model from
16:44:26 <antonym> odyssey4me: cool, i'll take a look at it
16:44:31 <antonym> mhayden: no prob
16:44:35 <mhayden> many thanks to the IBM folks for coming by and proposing good patches and doing reviews! :)
16:44:48 <odyssey4me> ++
16:44:50 <evrardjp> indeed
16:44:57 <antonym> hopefully 16.04 still has some basic xen support :D
16:45:03 <mhayden> antonym: anything else on Xen?
16:45:14 <antonym> mhayden: nope i'm done :)
16:45:17 <mhayden> sweet
16:45:25 <mhayden> that wraps up the discussion topics... on to...
16:45:32 <mhayden> #topic Release planning and decisions
16:45:35 <mhayden> odyssey4me: you're up!
16:46:09 <odyssey4me> do we have any blockers for the next tag for Liberty or Mitaka?
16:46:19 * mhayden is not aware of any
16:46:58 * automagically not that I know
16:47:02 <odyssey4me> as expressed in http://lists.openstack.org/pipermail/openstack-dev/2016-June/096466.html we're waiting for the final kilo-eol tags before we do our own Kilo eol
16:47:26 * mhayden sheds a tear for kilo
16:47:41 <odyssey4me> I need to request the Newton-1 tags today as well - I'm just trying to finalise a tool to help me simplify my release request process.
16:48:16 <odyssey4me> ok then
16:48:17 <evrardjp> good odyssey4me
16:48:17 <stevelle> does it use ansible?
16:48:31 <mhayden> it's written in perl
16:48:37 <evrardjp> :p
16:48:40 <odyssey4me> #action odyssey4me to request Newton-1 tags, and next tag releases for Liberty & Mitaka
16:49:09 <odyssey4me> stevelle nope, just python - I'm raging at different opinions about yaml formats
16:49:20 <mhayden> woot
16:49:28 <mhayden> anything else on this odyssey4me?
16:49:29 <odyssey4me> well, not raging, just trying to make yaml.dump output it the way that the release team wants it
16:49:36 <stevelle> I know that feel
16:49:45 <evrardjp> :D
16:49:54 <odyssey4me> I'll take the problem to the channel. Maybe someone can help.
16:50:02 <odyssey4me> mhayden no, thanks - all done
16:50:04 <evrardjp> do you need help?
16:50:16 <mhayden> okay, we got asettle's update already, so we're on to blueprints!
16:50:19 <mhayden> 10 minutes left
16:50:26 <mhayden> #topic Blueprint - Ubuntu 16.04 LTS Support
16:50:33 <mhayden> #link https://etherpad.openstack.org/p/openstack-ansible-newton-ubuntu16-04
16:50:51 <mhayden> lots more strikethroughs there!
16:51:06 <stevelle> I have the gnocchi role in progress right now
16:51:16 <stevelle> pretty close, might submit a review today
16:51:20 <evrardjp> my neutron role needs core reviews
16:51:30 <cloudnull> its progressing nicely
16:51:34 <cloudnull> cent7 support too :)
16:51:37 <michaelgugino> nova seems to be working locally, I basically just copied and pasted the work from neutron
16:51:40 <evrardjp> https://review.openstack.org/#/c/322249/
16:52:08 <odyssey4me> it looks like we're actually largely ahead of schedule here
16:52:11 <mhayden> #action Core reviewers can lend a hand on evrardjp's review -> https://review.openstack.org/#/c/322249/
16:52:18 <automagically> odyssey4me: don’t jix it
16:52:22 <automagically> jinx, rather
16:52:25 <mhayden> in the interest of time, i'll keep moving
16:52:38 <mhayden> #topic Blueprint - Install Documentation Update
16:52:39 <odyssey4me> all we needed to do for Newton-1 was get the vars split out implemented... but we're quite far down the road of getting Xenial working
16:52:48 <mhayden> actually -- i think asettle covered this well
16:53:00 <mhayden> #topic Blueprint - Ansible 2.1 Support
16:53:02 <odyssey4me> yep, I think we should move to discussion
16:53:10 <mhayden> odyssey4me: you wanna open it up?
16:53:11 <odyssey4me> considering we have 5 mins left
16:53:17 <mhayden> #topic Open Discussion
16:53:24 <michaelgugino> I vote 2.1 moves to O cycle
16:53:54 <mhayden> i'd like to thank everyone for helping learn the ways of a core reviewer
16:53:55 <evrardjp> would be happy to remove all the non 2.1 supported things for now
16:54:19 <michaelgugino> nova-lxd driver support will be implemented by my team soon, as soon as I can make them do it
16:54:30 <odyssey4me> michaelgugino cool :)
16:54:41 <evrardjp> yeah cool news michaelgugino
16:54:43 <odyssey4me> FYI to all https://review.openstack.org/#/q/project:openstack-infra/project-config+branch:master+topic:osa-additional-core-teams
16:55:13 <odyssey4me> there's another one for the swift role, and I can add any more if anyone wants to propose that we should have more role specific cores
16:55:21 <evrardjp> if the discussion is still open, please prepare your opinion on this: https://review.openstack.org/#/c/321582/
16:55:45 <evrardjp> goal is to simplify tox.ini, ansible.cfg ...
16:55:52 <michaelgugino> I'll also be working on the Watcher project, which has just made it into the big tent.  I'll be developing small contribs to that codebase, and acting as a liason between this project and that one
16:55:56 <evrardjp> not only for 2.1
16:56:23 <michaelgugino> They want to have OSA support for watcher, and I am happy to help them/do it
16:56:31 <odyssey4me> michaelgugino great, I'm happy that someone is - it looks like an interesting one to perhaps instrument into OSA at some point
16:56:32 <evrardjp> interesting project
16:57:10 <odyssey4me> evrardjp I'm not sure that it simplifies anything at all to have the plugins as a role requirement
16:57:29 <automagically> Very cool michaelgugino
16:57:58 <michaelgugino> I also need to submit some more openvswitch patches for neutron.  Right now, it only supports provider networking AFAIK.  I need to patch the config files to support the bridge mappings
16:58:07 <michaelgugino> br-int and br-ex, for example.
16:58:37 <evrardjp> odyssey4me: happy to discuss about your concerns (and everyone's)
16:59:10 <odyssey4me> ok, we need to clear the room mhayden
16:59:16 <mhayden> sounds good
16:59:18 <mhayden> thanks, everyone!
16:59:19 <evrardjp> ty everyone
16:59:21 <mhayden> #endmeeting