16:01:05 <cloudnull> #startmeeting OpenStack Ansible Meeting
16:01:05 <openstack> Meeting started Thu Jun 25 16:01:05 2015 UTC and is due to finish in 60 minutes.  The chair is cloudnull. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:06 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:09 <openstack> The meeting name has been set to 'openstack_ansible_meeting'
16:01:15 <Sam-I-Am> moo.
16:01:30 <rromans> .
16:01:57 <cloudnull> we have lots of ground to cover today so we're skipping the formalities.
16:02:00 <cloudnull> o/ everyone
16:02:05 <b3rnard0> hello
16:02:29 <cloudnull> #topic Defining the project mission - odyssey4me
16:03:00 <cloudnull> #link https://review.openstack.org/191105
16:03:12 <odyssey4me> sorry I'm late, now present
16:03:42 <cloudnull> did you want to talk about "Defining the project mission"
16:03:51 <hughsaunders> hey
16:03:55 <palendae> Present
16:04:05 <cloudnull> specifically - Is our mission to deploy OpenStack (just OpenStack services), or to deploy whole OpenStack environment (OpenStack and all supporting infrastructure)? Where do we draw the line?
16:04:55 <cloudnull> IMO i think its the later. we build a batteries included stack for use in production.
16:04:59 <Sam-I-Am> good question
16:04:59 <odyssey4me> Sure, I just wanted to raise the questions set out in the agenda and have us discuss them again. It seems that we didn't quite get to a conclusion before and we're being inconsistent already
16:05:37 <Sam-I-Am> with infra (such as galera) is more opinionated, but its easier to guarantee a working product when you do those things
16:05:39 <hughsaunders> cloudnull: I think the focus is on openstack, but we should be able to deploy all thats needed to get it to work.
16:05:51 <Sam-I-Am> if you say 'have a sql database' who knows what you're getting into
16:05:58 <palendae> How much of openstack?
16:06:02 <Sam-I-Am> could be mariadb, could be postgres, maybe redundant, maybe not
16:06:02 <odyssey4me> I don't have strong feelings either way, but I would like us to be clear on what we're about so that we can use the principle as a backing for reviews and spec decisions.
16:06:04 <palendae> For instance...mongo for ceilometer
16:06:34 <hughsaunders> I think we could probably focus more on openstack by reusing other people's bits for infra, however that always sounds easier than it is.
16:06:53 <Sam-I-Am> there always the option of making it an option
16:06:58 <palendae> I know others have expressed opinions on it before, just pointing out that deploying what openstack needs to work also leaves the question of what parts of openstack do we care about?
16:07:03 <odyssey4me> As a for instance, we could easily draw the ELK stack roles back into the project as they are OpenStack focused and developed for this stack...
16:07:09 <Sam-I-Am> just dont run the infra plays. if you dont, here's a set of prereqs
16:07:20 <cloudnull> Im with hughsaunders that if we can consume upstream other things we should do that, however I've not found roles that are "better" than what we already have .
16:07:30 <cloudnull> which we could replace
16:07:38 <git-harry> I'd like to see use break some of the roles out
16:07:43 <git-harry> *us
16:08:21 <git-harry> I've always thought osad should be a consumer of roles not an owner of them
16:08:23 <hughsaunders> #note git-harry spoke in a meeting
16:08:24 <odyssey4me> Sure, I think we could do better at breaking the roles out into their own repositories and posting them into galaxy. This would be especially useful for infra-type roles which could be used for other deployments.
16:08:52 <Sam-I-Am> hughsaunders: lol
16:09:17 <odyssey4me> however, my question related a lot more to whether our focus is on deploying openstack... or are we going the whole hog of also facilitating pinning, package additions/removals, host setups, networking setups, etc
16:09:38 <odyssey4me> these all support an openstack environment, but aren't essential
16:09:52 <odyssey4me> ... to include in this project
16:09:57 <cloudnull> once we move we'll have the ability to create new repos as needed, which will help facilitate moving roles into stand alone repos as needed.
16:10:12 <cloudnull> ah. i read the question wrong, odyssey4me
16:10:59 <git-harry> odyssey4me: that's where I see osad as a ref implementation. So all the roles should be broken out and then osad is essentially a way to test them
16:11:10 <git-harry> It's never going to be all things to all people
16:11:30 <git-harry> by breaking all the roles out it makes most of the project easy to consume by others
16:11:43 <git-harry> s/easy/easier/
16:11:54 <hughsaunders> this is presumably why we don't do pxe - so we can fit in with existing provisioning systems
16:11:55 <odyssey4me> git-harry yes, perhaps actually a role break-out is the way to show people how to be more flexible and consume other roles
16:11:57 <Sam-I-Am> so... back to the idea of saying you can use our infra roles or you need to meet a set of prereqs that the openstack roles expect?
16:11:58 <cloudnull> odyssey4me: in that sense i say no. we dont do pxe booting of hosts / network setup / pinning of system packages.
16:12:02 <hughsaunders> does mean we can't win rule the stack though :/
16:12:15 <Sam-I-Am> cloudnull: that sounds like more of a per-deployer task (like rpc)
16:12:22 <cloudnull> ++
16:12:30 <Sam-I-Am> unless its something that impacts openstack itself
16:12:43 <cloudnull> hughsaunders:  we can rule the stack, just bring your own pxe system
16:12:45 <cloudnull> :)
16:12:58 <hughsaunders> cloudnull:  :)
16:13:09 <svg> o/
16:13:25 * svg struggling to get online on it train
16:13:39 <odyssey4me> my concern is really down to the question of where we draw the line
16:13:44 <hughsaunders> svg: are you visiting the uk?
16:13:57 <Sam-I-Am> odyssey4me: i dont think we need to draw a line, just provide options?
16:13:59 <odyssey4me> if our arms are too wide open then we risk bit rot
16:14:15 <svg> *gr*
16:14:31 <Sam-I-Am> "heres what we test, if your stuff meets or exceeds the expectations, you can do your own thing for any part of it"
16:15:00 <odyssey4me> perhaps we should shift the question to where we draw the line in terms of testing things that get added
16:15:10 <cloudnull> i think its safe to say that we will do some host tuning and that we will have to interact with host machines however I dont think that we do anything in terms of provisioning.
16:15:12 <Sam-I-Am> we probably need a) more contributors b) more contributors with specialization in things like galera
16:15:42 <odyssey4me> cloudnull and what if someone decides to submit patches for provisioning
16:15:51 <Sam-I-Am> "we do software"
16:16:06 <Sam-I-Am> host provisioning sounds pretty generic
16:16:08 <cloudnull> in big tent i'd say those get moved to a new repo.
16:16:11 <Sam-I-Am> they can be used for anything
16:16:23 <cloudnull> but odyssey4me would that be ansible provisioning ?
16:16:31 <cloudnull> or ansible setting up a provisioning system ?
16:16:46 <cloudnull> that is later used to boot strap hosts?
16:16:51 <odyssey4me> cloudnull alright, I think essentially if we adopt the strategy of breaking out the roles then we're not creating first and second class citizens
16:17:42 <odyssey4me> which would then mean that we accept all the things, but we only test against a reference set of configurations and roles.... any other roles need to be tested individually
16:18:24 <palendae> Yeah, providing reference configurations would be helpful there
16:18:38 <palendae> Here's an AIO test, here's a 3 node test, here's a 5
16:18:43 <cloudnull> this is likely. and we're probably going to have to revise our test scripts to facilitate better testing of those roles.
16:18:53 <cloudnull> and add more jobs
16:19:16 <cloudnull> IE stand alone keystone, keystone + swift, all the things, etc. .
16:19:20 <palendae> Yeah
16:19:29 <odyssey4me> yup
16:19:47 <palendae> infra said they could support multi-node tests at summit, too
16:19:57 <palendae> But there'll be some networking monkeying we'll have to do
16:20:01 <odyssey4me> but, for instance, bugs like https://bugs.launchpad.net/openstack-ansible/+bug/1411897 would not be something we turn away if we accept all things
16:20:02 <openstack> Launchpad bug 1411897 in openstack-ansible "Make package auto updates tunable" [Wishlist,Invalid]
16:20:35 <odyssey4me> palendae yeah, it's on my to-do list to get multi-node working... I have all the info I need, I just need the time
16:20:40 <palendae> Cool
16:20:48 <Sam-I-Am> pfft time
16:20:49 <palendae> And that particular one they move to rpc-openstack
16:21:09 <palendae> moved*
16:21:11 <cloudnull> odyssey4me:  i dont agree.
16:21:20 <odyssey4me> palendae yep, it was moved because it was denied in the project because it was considered out of scope for OSAD
16:21:24 <cloudnull> we turn that away because we're not pinning
16:21:32 <cloudnull> but we've provided the ability for a deployer to pin
16:21:39 <odyssey4me> so the question stands, where do we draw the line?
16:21:59 <odyssey4me> sure, so should we provide the ability to blacklist packages?
16:22:01 <cloudnull> and that package is installed in the base os at install time, which they configure.
16:22:22 <odyssey4me> or to remove specified packages, or to tune the unattended updates?
16:22:22 <cloudnull> so its on their provisioning system to make that go away .
16:23:00 <palendae> Yeah, I kinda of agree with odyssey4me. We're allowing a hook to pin packages, but we're not allowing a hook to turn off auto updates?
16:23:46 <odyssey4me> we're not making consistent decisions about what we allow or disallow - that's what I'm trying to address
16:23:51 <cloudnull> again provisioning. would also add a hook to remove the gnome desktop should they have it installed ?
16:24:09 <odyssey4me> pinning has nothing to do with openstack, so why do we have a hook for it?
16:24:37 <cloudnull> pinning does not. and Id be happy to remove that role.
16:24:43 <odyssey4me> if we have a hook for that, why can't we have a hook for gnome desktop, widget1 and salamander_love123?
16:24:53 <cloudnull> it was added to help deployers (rax)
16:25:30 <odyssey4me> cloudnull yep, and I thought we had decided not to add it and had referred it just like we did the auto updates thing... then suddenly there was a patch merged for it
16:25:41 <odyssey4me> inconsistency :)
16:25:55 <cloudnull> i hate pinning, its up to the deployer to create a repo . if they dont have one they get the community repo.
16:26:33 * svg uses aptly to 'pin' packages
16:26:38 <odyssey4me> I really do feel that we can happily welcome anything and everything. I'm happy if someone preps a patch for it and agree that we can facilitate anything, but we only get opinionated about how to use that framework when it comes to a reference architecture for the project.
16:26:58 <cloudnull> svg:  doing it right
16:27:10 <palendae> So if we're doing things for deployers
16:27:17 <palendae> Not every deployer will agree with us on everything
16:27:28 <palendae> Regardless of whether one of our cores hates some approach or not
16:28:00 <odyssey4me> palendae sure, that's why I'm happy to provide a framework in the project - but the deployer needs to configure something for it to do anything
16:28:03 <svg> (but now I need to have the container images to use that repo too, IIRC not configureabl)
16:29:06 <odyssey4me> palendae but then we need to be consistent about it - we allow anything in terms of a framework, but not something opinionated unless it has a reference architecture with it which is gate-tested
16:29:16 <palendae> odyssey4me: I agree with you
16:29:57 <cloudnull> so lets revert this and stick to our guns https://review.openstack.org/#/c/180613
16:30:26 <odyssey4me> cloudnull what I'm suggesting is that we don't - we allow it and anything else
16:30:43 <odyssey4me> but much like that patch, it does nothing unless a deployer uses it
16:30:53 <palendae> Ok, so once that's reverted, how would a deployer add that functionality without having to edit osad roles directly?
16:31:29 <Sam-I-Am> of course this leads to... what if someone wants to deploy this on another distro :)
16:31:29 <cloudnull> if that means that we allowing provisioning into core OSAD, as a blanket "we accept all the things". i say no.
16:31:54 <cloudnull> svg: you could change the repo url to point to upstream and not add the repo containers ?
16:33:13 <odyssey4me> in fact, for these sorts of things the right way to do it would be to create a role in github/stackforge - then it can be consumed, but optionally
16:33:24 <cloudnull> palendae: a deployer could create their own role to pin.
16:33:38 <palendae> cloudnull: Ok, but then how do they make the osad ones rely on it?
16:33:39 <cloudnull> or have a proper mirror
16:33:47 <odyssey4me> we could perhaps just have a doc in our repo providing basic info on roles we've worked with and how to consume them in osad's framework
16:33:51 <palendae> That particular patch touches a lot of osad roles
16:33:59 <cloudnull> it does
16:34:40 <hughsaunders> but they are all role deps - the role could be run in an earlier play without those.
16:34:51 <odyssey4me> palendae cloudnull it only does because the decision was made to change all the disparate pinning in those roles to consume this role... which was a good decision
16:35:40 <odyssey4me> anyway, this has taken enough time and I think we should sleep on it and talk some more about it next meeting
16:35:50 <cloudnull> ok
16:35:59 <cloudnull> #topic What is our roadmap like? Will making fernet tokens in keystone be an 11.1.0 feature? palendae
16:36:23 <palendae> Yeah, my question here was do we have those point releases figured out yet?
16:36:35 <palendae> Fernet tokens is just a good example
16:36:45 <cloudnull> #link https://review.openstack.org/#/c/193729 (fernet tokens as the default)
16:37:10 <cloudnull> short answer palendae no.
16:37:17 <palendae> k
16:37:23 <palendae> I've heard rule-of-thumb
16:37:29 <cloudnull> generally, the road map is dicated by specs
16:37:31 <palendae> "It's a big change, changes a default"
16:37:32 <cloudnull> and not set
16:37:54 <cloudnull> but we dont really have much in the way of specs, yet
16:38:43 <cloudnull> in this case I'd say fernet hits master , and its backported to kilo, which changes the default token provider in a big way so we rev.
16:38:59 <cloudnull> and 11.0.4 becomes 11.1.0
16:39:03 <Sam-I-Am> so... why did we go with fernet?
16:39:09 <Sam-I-Am> (on a side note)
16:39:26 <cloudnull> its faster, and ha.
16:39:31 <odyssey4me> I agree with that as a strategy, but I kinda think that perhaps we should pile-up a few things before we declare a minor rev
16:39:33 <palendae> cloudnull: Ok
16:39:34 <dolphm> Sam-I-Am: performance, infrastructure overhead, scalability
16:39:34 <cloudnull> dolphm: -cc
16:39:42 <palendae> odyssey4me: I agree with that too
16:39:51 <odyssey4me> And yes, perhaps the switch to fernet tokens should be covered by a spec to infom people why
16:39:52 <palendae> So fernet as default goes in 11.1.0, but it's not the only thing
16:40:08 <cloudnull> this is what we have so far in 11.0.4
16:40:09 <odyssey4me> even if the spec is a small one
16:40:09 <Sam-I-Am> dolphm: ok, figured as much
16:40:10 <cloudnull> #link https://launchpad.net/openstack-ansible/+milestone/11.0.4
16:41:07 <cloudnull> we have quite a few "features" targetting 11.0.4
16:41:39 <palendae> odyssey4me: Agreed with a spec
16:41:41 <cloudnull> IE cinder on metal, keystone ssl, fernet, etc...
16:42:08 <odyssey4me> cloudnull fair enough - I think it may be worth shifting those to a new milestone and seeing how that looks
16:42:18 <dolphm> cloudnull: are they targeted to the milestone?
16:42:24 <cloudnull> they are
16:42:28 <cloudnull> 11.0.4
16:42:32 <dolphm> there's no Wishlist bugs or blueprints
16:42:54 <cloudnull> nope.
16:42:58 <odyssey4me> yep - we seem to have adopted a strategy of not marking things as wishlist any more
16:43:06 <dolphm> then there's clearly no features being tracked against 11.0.4!
16:43:09 <palendae> So many things went wishlist we never touched them
16:43:21 <odyssey4me> this is a bad habit
16:43:22 * cloudnull still sifting through them
16:43:25 <palendae> Yeah
16:43:27 <palendae> It is
16:43:31 <palendae> We swung the opposite direction
16:43:38 <palendae> So many things not marked wishlist, we never touch them :)
16:44:01 <cloudnull> i agree with specs being created.
16:44:18 <odyssey4me> wishlist items should be small feature changes - the rest should be blueprints and the bigger ones with specs
16:44:55 <odyssey4me> I think we should create a 11.1 milestone - move the ones that look like features to it, then decide on which become specs and which become wishlist items
16:45:11 <cloudnull> ++
16:45:12 <dolphm> there's not much point to a blueprint without a spec, given how broken blueprints are on their own. how to draw the line between the two is another story...
16:45:17 <palendae> odyssey4me: +1
16:45:40 <odyssey4me> we're too easily falling into the trap of letting everything be a bug and we need to get more disciplined about this
16:45:59 <cloudnull> so with that said we need people to write these specs and will need to do it retro actively for the items that we have had in the queue for a while
16:46:10 <cloudnull> example
16:46:11 <cloudnull> #link https://bugs.launchpad.net/bugs/1455238
16:46:13 <openstack> Launchpad bug 1455238 in openstack-ansible "Ceph Support" [Medium,In progress] - Assigned to Serge van Ginderachter (svg)
16:47:07 <cloudnull> so who, with me, is going to do this ?
16:47:50 <cloudnull> dont all speak at once. . .
16:48:09 <cloudnull> so maybe we do this going forward ?
16:48:48 <odyssey4me> cloudnull I'll be happy to assist after the federation sprints are done, so that'll be in around 2-3 weeks :/
16:49:44 <cloudnull> ok so if nobody wants to help write specs then im inclided to say that we do it from NOW on. and mark all of the "features" as wishlist which will be merged into 11.1.0
16:50:00 <odyssey4me> cloudnull I think that's fair
16:50:09 <cloudnull> going once.
16:50:29 <cloudnull> going twice.
16:50:32 <palendae> That also means we (cores especially) need to be vigilant about pushing back when someone doesn't propose a spec
16:50:42 <palendae> You want it, you spec it
16:50:44 <odyssey4me> palendae yep
16:50:53 <cloudnull> and sold.
16:50:54 <hughsaunders> bang?
16:50:58 <palendae> We can help, but shouldn't do it for you
16:51:28 <cloudnull> from this day forth no spec, no feature. everything in the pipline will be makred as wishlist and handled in our current targetted milestones.
16:51:37 <palendae> So say we all
16:51:45 <b3rnard0> by your command
16:51:56 <cloudnull> next
16:52:02 <cloudnull> #topic Discuss https://review.openstack.org/189998 (Fernet token support for keystone) odyssey4me
16:52:34 <cloudnull> i think we can do this with the same pattern we're using for the swift ring distribution .
16:52:44 <cloudnull> in terms of rotation.
16:52:45 <odyssey4me> So currently the patch we have has 3 keys, and only rotates when the playbook for installing keystone is run.
16:53:19 <cloudnull> in the proposed default patch its been set to 7
16:53:20 <cloudnull> https://review.openstack.org/#/c/193729/15/playbooks/roles/os_keystone/defaults/main.yml
16:53:28 <svg> back
16:53:45 <odyssey4me> I'm in favor of the keystone user having ssh keys and the keys being distributed on rotation in something like a cron job.
16:53:49 <cloudnull> s/proposed/merged
16:54:01 <cloudnull> odyssey4me:  me too.
16:54:20 <cloudnull> which will also get rid of the need to sync back the keys to the deploy host.
16:54:26 <cloudnull> and then distribute
16:54:42 <odyssey4me> I think that this should form part of the 'feature' for 11.1 and we shouldn't release 11.1 until that's done as it's a key requirement for making this production ready
16:54:52 <cloudnull> done.
16:55:07 <cloudnull> i am in agreement.
16:55:40 <odyssey4me> alright, so who's going to do it? sigmavirus24_awa ?
16:56:07 <cloudnull> im happy to bang it out. i know the swift code failly well .
16:56:14 <cloudnull> and it shouldnt take much to get it in
16:56:24 <odyssey4me> cloudnull cool, thanks :)
16:57:04 <cloudnull> so last 5 min.
16:57:08 <cloudnull> #topic open
16:57:36 <odyssey4me> open bar, perhaps?
16:57:43 <cloudnull> anything that we want to talk about ?
16:57:49 <cloudnull> open bar would be nice !
16:58:24 <dolphm> i just finished re-assigning a few bug priorities to wishlist in https://launchpad.net/openstack-ansible/+milestone/11.0.4, none are committed yet though, so it's still sane to release 11.0.4 at the moment
16:58:50 <cloudnull> tyvm dolphm!
16:59:41 <cloudnull> ok we're done here.
16:59:46 <cloudnull> #endmeeting