16:00:55 <odyssey4me> #startmeeting OpenStack Ansible Meeting
16:00:56 <openstack> Meeting started Thu Aug 13 16:00:55 2015 UTC and is due to finish in 60 minutes.  The chair is odyssey4me. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:00 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:01:08 <dstanek> o/
16:01:12 <svg> o/
16:01:16 <sigmavirus24> o/
16:01:19 <odyssey4me> #topic Agenda & rollcall
16:01:20 <andymccr> o/
16:01:27 <odyssey4me> #link https://wiki.openstack.org/wiki/Meetings/openstack-ansible#Agenda_for_next_meeting
16:01:40 <evrardjp> \o/
16:02:14 <odyssey4me> howdy all :)
16:02:52 <stevelle> o/
16:04:03 <serverascode> o/
16:04:22 <BjoernT> Morning
16:04:31 <palendae> hi
16:05:08 <odyssey4me> #topic Review action items from last week
16:05:20 * odyssey4me sigmavirus24 and cloudnull to put together a POC for pip and epoch's
16:05:29 <sigmavirus24> ugh
16:05:35 <sigmavirus24> stuck in upgrade hell right now
16:05:39 <sigmavirus24> haven't had time for this
16:05:40 <odyssey4me> sigmavirus24 I take it that will need to carry considering that cloudnull is still on leave?
16:05:46 <odyssey4me> alright
16:05:47 <sigmavirus24> yeah that too
16:05:55 <odyssey4me> #action sigmavirus24 and cloudnull to put together a POC for pip and epoch's
16:05:55 <sigmavirus24> The idea is on the ML
16:06:09 * odyssey4me odyssey4me to release 11.1.0 on 7 Aug 2015, any blueprints not yet merged to be postponed to 11.2.0
16:06:36 <odyssey4me> so it was released on 10 Aug instead, but it was released with all the blueprints completed :)
16:06:52 <odyssey4me> well done everyone for getting that done, even with our busy days!
16:07:01 <odyssey4me> #link https://launchpad.net/openstack-ansible/kilo/11.1.0
16:07:15 <odyssey4me> there was a lot of work that went into there
16:07:45 * odyssey4me odyssey4me to set 11.2.0 release date to the (tentative) date of 4 Sep
16:08:23 <sigmavirus24> Good job everyone
16:08:30 <sigmavirus24> :round of applause:
16:08:47 <odyssey4me> I've set the date for 11.2.0 as 11 Sep to ensure that we have enough time to get two hotfix patches into 11.1.0, and another week for getting the 11.2.0 feature patches merged in.
16:08:54 <odyssey4me> https://launchpad.net/openstack-ansible/+milestone/11.2.0
16:09:00 <odyssey4me> #link https://launchpad.net/openstack-ansible/+milestone/11.2.0
16:09:07 <svg> from me a big thanks on helping meon the Ceph patch
16:09:38 <odyssey4me> thank you svg for doing that work and being patient with us in the reviews and testing
16:10:06 <svg> I thought you guys were the ones being patient :)
16:10:10 <odyssey4me> if any bugs are raised against that work, please target them to 11.2.0 for kilo so that we can track which ones need ot be backported
16:10:25 <svg> ack
16:10:48 <odyssey4me> alternatively patches can also be registered against the blueprint considering that it's still not released yet
16:11:04 <evrardjp> not master?
16:11:19 <evrardjp> ok my bad
16:11:36 <odyssey4me> evrardjp patches get initially added to master, but they won't be backported to kilo until the week before 11.2.0
16:11:49 <odyssey4me> so ceph patches into master are welcome
16:11:56 <odyssey4me> :)
16:12:10 <odyssey4me> is everyone happy with the dates for the milestones?
16:13:41 <odyssey4me> alright, moving on
16:13:45 <odyssey4me> #topic Blueprints
16:13:57 <odyssey4me> #link https://blueprints.launchpad.net/openstack-ansible
16:14:48 <hughsaunders> <-- late
16:14:52 <odyssey4me> I've added a liberty blueprint. For anything you see that may need follow up in liberty - whether it be an upstream bug, or perhaps settings that need changing due to deprecation - please associate them with that blueprint.
16:15:49 <odyssey4me> I'd like to propose adding the upstream liberty-related milestones to trunk so that we can target specific things and also have an easy reference for the dates to help with planning.
16:16:18 <odyssey4me> Are there any objections to that?
16:16:21 <palendae> Nope
16:16:29 <palendae> We need more structure around our Liberty stuff
16:16:42 <palendae> Even though forward progress on that has been slow
16:16:42 <odyssey4me> #link https://wiki.openstack.org/wiki/Liberty_Release_Schedule
16:17:01 <odyssey4me> all we have left is liberty-3, then liberty-release
16:17:10 <palendae> I have a feeling we'll miss liberty-release
16:17:18 <palendae> At least any configuration changes
16:17:39 <odyssey4me> palendae I think it'll be easier than you think. :)
16:17:56 <palendae> We'll see. I won't consider it working til we have working upgrades
16:18:25 <hughsaunders> now you're moving the goalposts
16:18:32 <odyssey4me> we will definitely have a functional release on the release day - we've been working through kinks as we've updated our sha's and have been fixing upstream bugs as we discover them
16:19:05 <palendae> hughsaunders: Nope, not at all
16:19:09 <odyssey4me> palendae the upgrades will probably be a lot easier as we don't have as many structural changes as juno->kilo
16:19:22 <palendae> hughsaunders: Function upgrades are more important than greenfield deployments IMO
16:19:27 <palendae> odyssey4me: Hopefully :)
16:20:18 <odyssey4me> I'd like to ask everyone to take the time in the next week to look through the registered blueprints and to self assign where possible, also setting a goal milestone
16:20:47 <odyssey4me> it'd also be a good idea to get a starting review uploaded so that the design discussions can happen
16:21:19 <odyssey4me> palendae has a good one up already
16:21:23 <odyssey4me> #link https://review.openstack.org/207713
16:22:01 <odyssey4me> personally I think this one is fine, and I believe it's important for adding RHEL support later
16:22:04 <odyssey4me> #link https://review.openstack.org/203708
16:22:49 <odyssey4me> also if we could get some reviews on this patch to the specs repo so that we don't get so many merge conflicts, that'd be grand: https://review.openstack.org/208440
16:23:39 <odyssey4me> #action odyssey4me to add upstream liberty milestones to the trunk series
16:24:10 <odyssey4me> #action all to review blueprints, self-assign and target, then submit and review blueprints
16:24:58 <odyssey4me> I'd like to suggest that we spend most of next week's meeting discussing our roadmap and breaking down some of the steps into easy pieces to chew on.
16:26:00 <palendae> Sounds reasonable
16:26:44 <sigmavirus24> +1
16:26:45 <odyssey4me> part of the thought we need to put into it is how we can best serve our downstream consumers
16:27:35 <odyssey4me> We have different types of consumers currently - RPC is an example of a consumer which embeds openstack-ansible wholesale into something bigger.
16:28:18 <odyssey4me> Compass is a relatively new project building a UI around deployment, and is looking to consume our playbooks and roles.
16:28:46 <odyssey4me> We also have deployers consuming the playbooks & roles as they are, and perhaps doing their own bits around or over the top.
16:29:33 <odyssey4me> I'd like us to consider as part of our roadmap making the roles individually consumable, testable and reusable outside of our reference builds.
16:30:23 <evrardjp> Do we have Compass contributors telling their opinion?
16:30:30 <evrardjp> that could be nice
16:30:46 <odyssey4me> It'll make it easier for SME's to get involved in adding functionality without having to get too involved in the entire stack.
16:30:58 <evrardjp> (or even commiting/improving the product)
16:31:35 <odyssey4me> #link http://lists.openstack.org/pipermail/openstack-dev/2015-August/071892.html
16:31:44 <odyssey4me> ^Compass call for contributors
16:32:34 <odyssey4me> I've been having conversations with various parties to get feedback about what holds them back from getting involved.
16:32:48 <odyssey4me> The feedback has been, so far:
16:33:12 <odyssey4me> 1 - it'd be great if it was easier to get a dev/test environment going
16:34:17 <svg> so they ask to make openstack easier? ⸮
16:34:19 <odyssey4me> 2 - there is no support for implementing on the platform I use (usually CentOS)
16:35:17 <evrardjp> ok
16:35:17 <hughsaunders> 1) curl | bash
16:35:44 <odyssey4me> svg not openstack, but a dev/test environment to understand how to do operator things (add nodes, replicate a bug, etc) and also how to do dev things (add a role, feature or functionality to the stack)
16:36:04 <stevelle> hughsaunders: I was perhaps reading 1 differently: as a multi-node environment which is not that simple.
16:36:26 <hughsaunders> stevelle: fair
16:36:35 <odyssey4me> stevelle yes, an AIO is relatively easy in a VM or Cloud - but not everyone has a VM environment or Cloud
16:36:48 <odyssey4me> #link https://blueprints.launchpad.net/openstack-ansible/+spec/deploy-with-vagrant
16:36:52 <palendae> So i'm not sure how we fix that
16:36:56 <palendae> If they don't have access to VMs
16:37:07 <odyssey4me> ^ has been added and I'm liaising with the guy to add his Vagrant conf and some docs into the repo
16:37:12 <andymccr> maybe we make an installable iso, Apsu could you get working on that?
16:37:16 <odyssey4me> this opens another door
16:37:24 <palendae> Or I'm misunderstanding what you're saying, because you just linked to deploying with vagrant after you said not everyone has access to VMs :)
16:37:25 <Apsu> andymccr: Right on it
16:37:27 <odyssey4me> we could also do better at docs
16:38:02 <andymccr> it could have like questions that stores vars like your public address range etc.
16:38:31 <evrardjp> Compass handles the PXE booting so I guess it won't be hard to add osad on top of it when the management network is running
16:38:46 <odyssey4me> anyway - part of getting more host OS platforms supported are these blueprints:
16:38:48 <evrardjp> andymccr: this wizard could be done with or without the iso
16:38:59 <odyssey4me> #link https://blueprints.launchpad.net/openstack-ansible/+spec/mariadb-upgrade-to-v10
16:38:59 <evrardjp> but we are getting far from original topic, right?
16:39:06 <odyssey4me> #link https://blueprints.launchpad.net/openstack-ansible/+spec/add-support-for-systemd
16:40:45 <odyssey4me> evrardjp right, the point is not for us to change what we do which is deploy on existing hosts - the point is to make it easier for evaluators and developers to get to grips with how what we've built works and how they can contribute
16:42:07 <odyssey4me> most of the time when people raise their issues I find that they just don't know that we already do things that they thought we didn't
16:42:50 <odyssey4me> so I think we could also do better at sharing our successes and engaging with SME's in the various projects to assist when we're working on things that they could help with
16:42:53 <stevelle> how much of the friction is from the particular way that we use Ansible?
16:43:05 <stevelle> thinking of vars specifically
16:43:35 <odyssey4me> stevelle the 3rd objection that they have is to do with the opinionation - we have a pretty rigid way of deploying
16:43:40 <stevelle> though I know questions about inventory exist too
16:44:08 <odyssey4me> stevelle I think that's more of an issue for us than others at this stage. No-one's mentioned that just yet.
16:44:29 <odyssey4me> #link https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCEQFjAAahUKEwiwivvewKbHAhUGF9sKHdx-B9U&url=https%3A%2F%2Fgithub.com%2Fopenstack-ansible%2Fopenstack-ansible&ei=YsnMVbDRDIau7Abc_Z2oDQ&usg=AFQjCNEdKMLeFRncUo1F0xilQ5svqPrfCA&sig2=trguuB1XtNTgs3jHgn3LTg&bvm=bv.99804247,d.ZGU
16:44:48 <odyssey4me> #action odyssey4me to slap himself with a wet fish
16:44:55 <odyssey4me> #link https://github.com/openstack-ansible/openstack-ansible
16:45:16 <odyssey4me> ^ I've engaged with the guys who worked on these playbooks and roles.
16:45:20 <palendae> odyssey4me: I've seen several questions from people about how the dynamic_inventory.py script works
16:45:43 <odyssey4me> They're currently on icehouse and have committed to evaluate the stack we have and provide feedback. It's early days though.
16:46:23 <evrardjp> I think variables handling could prevent adoption: I was afraid myself at first
16:46:35 <odyssey4me> palendae agreed, those questions come from those who've actually deployed and tried doing hard things :)
16:47:01 <odyssey4me> palendae has suggested that he'd like to write up some reference documentation about it all
16:47:21 <palendae> Yep, I have some things sitting on my hard drive to get pushed up
16:47:50 <odyssey4me> I'm of the opinion that we can break down a lot of barriers to adoption by making the roles independant units, consumable on their own.
16:47:56 <palendae> Sure
16:48:06 <odyssey4me> It will allow those interested to tackle broader OS support in a smaller unit.
16:48:30 <evrardjp> I agree
16:48:31 <odyssey4me> It will also allow people to deploy in whatever way they choose, instead of the way we've chosen.
16:49:05 <odyssey4me> It will also make it easier to get to grips with the pieces that people are interested in, instead of the monolithic large pile of code we have now.
16:49:12 <palendae> That's gonna be a very long term road map, fwiw
16:49:24 <odyssey4me> well, maybe - but maybe not
16:49:26 <palendae> I think Keystone's a great place to start, but this is not going to be all done by 12
16:49:39 <palendae> Some of our roles are very intertwined
16:50:30 <odyssey4me> if we split the roles into their own repositories - which will be in the openstack namespace, then we use submodule references in os-ansible-deployment in order to handle a full cycle of deprecation, then it may be achievable
16:50:51 <palendae> That's the high level, yeah..
16:50:57 <odyssey4me> during the M cycle we can work on making them more individually functional and individually tested
16:51:05 <palendae> Though submodules everywhere...we were down that road with the chef stuff, no?
16:51:39 <odyssey4me> yeah, not ideal - but after the one cycle we remove them and have them all as ansible galaxy roles
16:52:08 <palendae> Ok, I think it's a reasonable high level plan. I just think the details may bog it down
16:52:10 <odyssey4me> or shall we say the submodules stay in the branches they need to stay in, but in master we switch
16:53:09 <odyssey4me> Anyway - let's put some thought into the future this week coming, and try to get our thoughts into specs. We can make the blueprints dependant on each other to help understand what follows what.
16:54:02 <odyssey4me> Our time is just about up, so I'd like to open the floor for comments, questions, suggestions and general banter...
16:54:29 * odyssey4me slaps himself with a wet fish
16:54:37 * odyssey4me ticks 'action complete' checkbox
16:54:57 <meteorfox> I have the Rally ansible role, ready to go, https://github.com/meteorfox/ansible-rally
16:55:08 <meteorfox> well, you can say is the mvp version
16:55:44 <odyssey4me> yep :) didn't realise you were here meteorfox
16:55:45 <stevelle> it could use a bit of love in the readme :)
16:56:13 <odyssey4me> I forgot about that - I'd like to submit the review to register our first role in the openstack namespace.
16:56:20 <odyssey4me> We need to figure out a naming convention.
16:56:39 <meteorfox> yes, I'm aware of that, and there a few directories which are 'empty' and could be deleted
16:56:40 <odyssey4me> I was thinking something along the lines of 'openstack-ansible-<role name>' ?
16:57:21 <odyssey4me> once we've registered it, meteorfox can submit his code as a first review and we can collaborate on improving it
16:57:35 <odyssey4me> thoughts?
16:57:59 <meteorfox> I'm fine with the name convention
16:58:18 <odyssey4me> palendae sigmavirus24 andymccr hughsaunders mattt ?
16:58:28 <sigmavirus24> yeah that works for me
16:58:51 <palendae> you're submitting that for Liberty? Prior to the blueprint being finalized?
16:59:07 <andymccr> so it would be the first role in its own repo?
16:59:25 <andymccr> with the expectation others follow the same pattern (are moved to that pattern)
17:00:04 <odyssey4me> andymccr yep
17:00:13 <odyssey4me> we're out of time - move to #openstack-ansible
17:00:17 <odyssey4me> #endmeeting