20:02:11 <ttx> #startmeeting tc
20:02:12 <openstack> Meeting started Tue Jun 23 20:02:11 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:15 <openstack> The meeting name has been set to 'tc'
20:02:22 <ttx> Meeting agenda for today:
20:02:23 <lifeless> o/
20:02:25 <cloudnull> o/
20:02:27 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:02:30 <dhellmann> o/
20:02:35 <adrian_otto> o/
20:02:41 <ttx> Lots of ground to cover, hopefully we won't spend too much time on straightforward things
20:02:48 <ttx> #topic Add compute starter kit tag
20:02:52 <ttx> #link https://review.openstack.org/180112
20:02:59 <ttx> Last week we had limited attendance to the TC meeting so we said we would wait for this week before pushing this in
20:03:13 <ttx> I think the remaining objections can be proposed as subsequent patches at this point
20:03:23 <dhellmann> I still have strong reservations about this one. Can someone reassure me that we're not going to use this tag to allow cross-project teams to refuse to help projects that don't have it?
20:03:25 <ttx> still short of one vote
20:03:43 <ttx> dhellmann: I don't think cross-project teams need the tag to do that
20:04:02 <flaper87> dhellmann: I certainly hope that won't happen
20:04:07 <dhellmann> ttx: I'm differentiating "help" from "do the work for them"
20:04:08 <lifeless> dhellmann: our job is to encourage cross-project tings
20:04:09 <flaper87> because that's not how I'm seeing this
20:04:11 <markmcclain> similarly not certain that a few of the recommendations are things should be suggesting currently
20:04:54 <lifeless> I'd really love a more product centric view on things; I think this is a balanced, neutral stab at that, driven by requests from our newest users.
20:05:05 <ttx> dhellmann: if a cross-project team refuses to help a given project, then that's a different problem. My point is the tag doen't help or prevent that
20:05:10 <dhellmann> ttx: for example, annegentle expressed interest in having this for the doc team, and I would not want them to then say "we're only going to support projects in the starter kit" or "we're only going to include starter kit apps in the install guide" (not saying they would, just an example)
20:05:23 <dhellmann> ttx: it might encourage it
20:05:45 <lifeless> dhellmann: so, you're asking for a guarantee that noone here will support the idea of projects not helping other projects based on starter kit membership ?
20:05:47 <russellb> i do see it as useful input to docs, if for example they did want to write the simplest starter install guide they could
20:05:48 <ttx> dhellmann: I could see the starter kit prioritizing effort, but not excluding it
20:05:52 <russellb> or whatever guide
20:05:53 <dhellmann> lifeless: yes
20:05:59 <flaper87> I'd love to see other kits to be proposed as well. I may do that if I find the time in the next couple of weeks
20:06:00 <jaypipes> russellb: ++
20:06:01 <russellb> ttx: good summary
20:06:02 <flaper87> I think that'd help
20:06:14 <lifeless> I'd love to see -more- cross stuff, not less. So you have my guarantee.
20:06:39 <ttx> dhellmann: if it's used for evil, you can come back and suggest we get rid of it :)
20:06:46 <annegentle> dhellmann: oh that's not the point
20:06:46 <annegentle> dhellmann: more "starter docs definition help"
20:06:46 <annegentle> dhellmann: and yeah, we don't only include certain tags, it's just that tags are doc anyway
20:07:00 <dhellmann> ttx: you can't put the genie back into the bottle, though, right?
20:07:08 <sdague> well, as someone that spent a ton of the last six months building external plugin mechanisms for devstack and grenade for the big tent, I kind of feel my actions speak pretty strongly for supporting a wide range of the ecosystem
20:07:09 <dhellmann> annegentle: right, I wasn't saying docs would, just using it as a concrete example of what I wouldn't want to see
20:07:13 <russellb> i think we could easily remove this tag
20:07:19 <russellb> right now anyway
20:07:23 <markmcclain1> apologies my bouncer lost connectivity
20:07:36 <annegentle> dhellmann: sure, it's a decent example
20:07:56 <ttx> dhellmann: I'm not sure what you mean, we can certaiunly remove the tag as well as we can create it
20:08:13 <dhellmann> because if we're ever going to have another tag that requires *this* tag, or we're going to have teams saying "we only work on the  starter kit" then I think we should not be documenting this in the governance repository where it implies that is ok
20:08:28 <ttx> and if a team says I'll only support A B and Cn then the fact that a tag at a given moment covered A B and C doesn't really help or prevent
20:08:31 <mordred> I'm +1 on this - I _DO_ worry that we're pointing new users at deploying a thing we want to deprecate
20:08:39 <mordred> that said - I get the purpose, and I think it's well described
20:08:45 <mordred> and I support its existence
20:08:50 <russellb> mordred: which, nova-net?
20:08:51 <mordred> yes
20:09:00 <sdague> yeh, the nova-net / neutron bit doesn't honestly have a great answer today
20:09:00 <markmcclain1> mordred: I share the same concern
20:09:06 <sdague> so I went for simplicity
20:09:07 <mordred> I would like to reduce the number of new nova-net deployments
20:09:13 <russellb> i'd like it just the same swapping nova-net for neutron
20:09:14 <russellb> personally
20:09:18 <mordred> and if the "start with this" says "deploy nova-net" that's bad for us overall
20:09:29 <russellb> yeah, we don't really need to make the migration problem worse
20:09:32 <flaper87> dhellmann: does having a "deploy starter kit" in devstack worry you? Because I see that like something that could easily happen
20:09:33 <edleafe> that would be the starter kit *today*. It can change as the neutron story improves
20:09:37 <markmcclain1> we're also pointing them to multi-host which has the fuzziest migration path of all
20:09:38 <ttx> mordred: we could quickly iterate on it though
20:09:58 <russellb> i think it's better to assume you start with neutron, and fall back to nova-net only if needed
20:09:59 <mordred> yah. we don't need to spin on this - we can adjust and move forward - I just wanted to vocalize that
20:10:00 <sdague> edleafe: right, my hope is it flips next cycle because we feel confident we have a simple enough story there
20:10:03 <lifeless> dhellmann: so actually, I want to pick up on something here
20:10:12 <russellb> but yeah, follow-up patch is fine to debate that point ...
20:10:14 <lifeless> dhellmann: I think it would be entirely reasonable for a group to form around making the onramp super easy.
20:10:18 <lifeless> dhellmann: I'd support that.
20:10:21 <mordred> ++
20:10:29 <lifeless> dhellmann: I wouldn't support e.g. nova saying 'starter kit only thanks'
20:10:30 <edleafe> flaper87: seems like if you're using devstack, you're past the need for a starter kit
20:10:48 <flaper87> edleafe: but that doesn't mean you couldn't have it
20:10:50 <dhellmann> lifeless: right, someone working from this to make things easier is fine. Someone using this to exclude other projects is not fine.
20:11:09 <flaper87> we're discussing the meaning and implications of having the starter kit
20:11:13 <lifeless> right
20:11:13 <edleafe> flaper87: yeah, but still, one does not imply the other
20:11:15 <dhellmann> lifeless: we have had a history of "in" projects vetoing ideas and requests from other projects, and I think we should not be encouraging more of that.
20:11:19 <flaper87> so, I kinda feel it's relevant to dhellmann's point
20:11:22 <lifeless> dhellmann: ah
20:11:37 <flaper87> I don't mind having it in devstack (if that ever happens)
20:11:40 <dhellmann> lifeless: nova/ceilometer, for example. Or, frankly, nova/neutron.
20:11:45 <ttx> dhellmann: I guess we'll have to stay vigilant
20:11:47 <lifeless> dhellmann: so, if there's a history, how about we actively oppose that where it shows up, unless you think this is structurally supportive of that...
20:11:50 <lifeless> dhellmann: (I don't)
20:11:51 <flaper87> I just want to know other folk's thoughts
20:12:15 <dtroyer> I'm in support of this doc, but it is no longer the thing for which I had hoped we would get that describes technical relationships between the projects.
20:12:15 <dhellmann> lifeless: I am a bit worried that it is, but I am glad that most everyone seems to be saying that's not the goal and would not be supported.
20:12:34 <annegentle> dhellmann: hm
20:12:43 <lifeless> dhellmann: one of the things that makes me say it isn't is that its less than a fully useful cloudin every dimension
20:13:08 <flaper87> I believe the moment we see this is going the wrong direction, we should just sit and take a step back
20:13:13 <flaper87> or take a step back and then sit
20:13:19 <flaper87> that makes more sense :P
20:13:30 <dhellmann> lifeless: i am much less worried about the technical details than the message we send by identifying a group of projects like this *in governance* vs. a product guide or documentation somewhere else
20:13:31 <dhellmann> lifeless: it's the location, not the content, that bothers me
20:13:36 <ttx> markmcclain: the bit you oppose to is the proposed application of the tag. we could fix that or rediscuss it) when a patch comes to apply that tag
20:13:37 <lifeless> k
20:14:02 <dhellmann> lifeless: that said, the nova-net/neutron thing caught my eye, too, though I do understand sdague's goal
20:14:09 <sdague> and, honestly, the way we keep teams collaborating is by getting in and helping them collaborate. I feel like we made a bunch of progress in the last week on nova / ceilometer interaction for instance
20:14:19 <sdague> and that was about people just deciding to talk and make things better
20:14:44 <markmcclain> ttx: yeah the specific recommendations are a stumbling block
20:15:02 <dhellmann> sdague: I won't go over the whole history there, but we tried for a long time to get the nova team to talk about that stuff and were rebuffed. So I think *finally* is the operative word.
20:15:09 <lifeless> sdague: yes, its all conways law :)
20:15:39 <dhellmann> and that is a perfect example of what I want to avoid -- nova rebuffed ceilometer because that team was not an integrated project, will we see the same thing for non-starterkit projects now?
20:16:22 <russellb> we can drop the whole thing because of that risk, or wait to see if that happens and call it out if we see it
20:16:24 <ttx> dhellmann: slightly different though. Ceilometer was not an openstack project ?
20:16:33 <flaper87> I really think that we should keep our eyes super open to this  cases and just rollback
20:16:40 <dhellmann> ttx: at some point when we still wanted better nova integration, it was
20:16:57 <russellb> if it would help, another paragraph could be added to the tag definition around that point
20:17:07 <ttx> dhellmann: then it was integrated ?
20:17:16 <dhellmann> having been on the receiving end of "go away, you aren't one of the cool projects" a couple of times, I might be overly sensitive to this particular issue
20:17:18 <ttx> or was it during incubation ?
20:17:41 <adrian_otto> dhellmann: +1
20:18:00 <ttx> Anyway, I think all the tags designate a subset of projects, and people can piggyback on them for evil
20:18:06 <dhellmann> ttx: the problem they're solving now has been there since we started collecting more hypervisor metrics than nova had. I don't know when that started off the top of my head, but I would guess more than 1 year easily
20:18:24 <ttx> some random person could decide that they don't support projects without team:diverse-affiliation
20:18:43 <ttx> I don't see how that tag is different or more significant
20:18:47 <dhellmann> ttx: this particular tag smells a lot like the integrated release or core, so I think it's different from "release:managed" or whatever
20:19:01 <markmcclain> dhellmann: ++
20:19:08 <dhellmann> ttx: the members of this group are unlikely to grow
20:19:23 <ttx> I don't know what can be done to make it smell less than calling it starterkit
20:19:27 <dhellmann> and so no project not in it at the beginning is likely to ever get support from someone that says "you must be in the starter kit"
20:19:57 <edleafe> ttx +1
20:20:22 <ttx> Just trying to see what's the next step here. You raise fear and doubt, it's hard to be constructive from that
20:20:24 <edleafe> it's clearly a small subset, not a cool club to join
20:20:44 <dhellmann> ttx: we should probably move on. I feel like I'm saying the same things I've been saying since this came up, and I feel like the only one hesitating.
20:21:02 <lifeless> dhellmann: markmcclain seems also concerned
20:21:05 <dtroyer> this set of projects will grow to exactly one more in the forseeable future.  that is based on technical requirements, not popularity
20:21:15 <ttx> dhellmann: no, I think your concerns are shared, it's just that we trust our ability to fix that if it arises
20:21:28 <sdague> so, honestly, I think keeping it small is part of what prevents that. Because it's too small for most use cases, except my "first openstack". If we let it get big, then it becomes convoluted with core.
20:21:29 <annegentle> seems like this particular tag needs some additional parallel tags to make people more comfortable
20:21:33 <ttx> basically it's not a bylaws change, we can iterate and change it
20:22:12 <markmcclain> this sends a very powerful signal no matter how we down play it
20:22:19 <ttx> ok, we need to move on
20:22:31 <flaper87> dhellmann: FWIW, I do share your concern and I was completely opposed at the previous version of this tag
20:22:43 <flaper87> dhellmann: now, that it is called starterkit, it seems more reasonable
20:22:48 <ttx> it has a majority if Sean votes in favor
20:22:59 <flaper87> and I do, as ttx mentioned, believe in our ability to rollback
20:23:28 <markmcclain> ttx: still very concerned with how we'll actually apply the tags
20:23:39 <ttx> markmcclain: that's a different change though
20:23:47 <markmcclain> ttx: there's no mechanism for saying this component in this exact config
20:23:54 <ttx> we may iterate on the tag defv before we even apply it
20:23:58 <sdague> dtroyer: you are supposed to roll-call vote as well
20:24:14 <dtroyer> argh, done
20:24:26 <ttx> sdague: you abstain ?
20:24:37 <sdague> yeh, I said I was going to abstain because it was my patch
20:24:52 <sdague> I think that's in the early comments
20:25:17 <ttx> Alright, I think at this point it's easier to merge it and iterate on it
20:25:34 <ttx> but Doug's point is duly noted, we should keep our eyes open
20:26:10 <ttx> this is for users to have a short list of projects to start playing with a compute use case
20:26:25 <ttx> not for excluding projects from the discussion
20:26:45 <dhellmann> I could vote for this if it had a non-exclusion section, but I don't feel comfortable voting for it as it is now.
20:27:04 <ttx> dhellmann: I'd suggest you propose it as a subsequent patch
20:27:06 * flaper87 thinks it'd also help to have other kits instead of just one. That way folks would see that it's not something dedicated to just a set of projects
20:27:19 <dhellmann> ttx: ok
20:27:24 <annegentle> ttx: do we have a plan for more use case tags to be proposed? I can work on some if desired.
20:27:26 <ttx> we can block the tag application anyway, tag definition is not the end of the road
20:27:28 <dtroyer> the object-store kit should be easy to write
20:27:51 * ttx will proceed with approval if gerrit ever answers
20:27:54 <flaper87> dtroyer: +1
20:28:09 <Rockyg> ?me thinks dtroyer stole my idea...;)
20:28:09 * flaper87 has that in his to-write things
20:28:10 <ttx> ok, moving on while I wait for Gerrit to reply
20:28:18 <ttx> #topic Ansible playbooks and roles to deploy OpenStack
20:28:18 <annegentle> dtroyer: low hanging fruit :)
20:28:28 <ttx> #link https://review.openstack.org/191105
20:28:39 <ttx> This one looks pretty straightforward to me, no need to spend too much time on it
20:28:48 <ttx> last time Gerrit was nice enough to answer it was pretty close
20:28:54 * russellb waiting on gerrit too
20:28:54 <cloudnull> hi ttx commited that review and am happy to answer any questions.
20:29:07 * sigmavirus24 is around too
20:29:22 <ttx> any objection, or should I just approve it once it passes 7 yes ?
20:30:02 <dhellmann> ttx: gerrit isn't loading, so maybe we should wait to give everyone time to vote
20:30:03 * flaper87 has no objections
20:30:04 <annegentle> is gerrit wearing its slowpants today?
20:30:12 <sdague> gerrit has been sad all week
20:30:14 <ttx> been a few days
20:30:25 * sigmavirus24 expected flaper87 to object on the basis of my involvement =P
20:30:25 <palendae> Finally loading for me
20:30:27 <ttx> ok it has 7 yes already
20:30:28 <flaper87> gertty ftw
20:30:33 <cloudnull> yea its not been happy today at all.
20:30:41 <flaper87> sigmavirus24: did it in my mind :P
20:30:45 <ttx> so I'll give you extra time to push your +1 on it and approve at end of meeting
20:30:48 <sdague> the ansible stuff was all straight forward
20:30:49 <sigmavirus24> silly gerrit thinking it can have feelings and such
20:30:57 <ttx> #topic Add Cue Message Broker Service to Openstack
20:31:01 <flaper87> should we take this as a sign?
20:31:03 <flaper87> :P
20:31:06 <ttx> #link https://review.openstack.org/191173
20:31:07 <annegentle> cloudnull: is the only repo a specs repo?
20:31:17 <vipuls> i'm here if there are any Cue questions
20:31:20 <sigmavirus24> flaper87: might take it as a cue for zaqar though
20:31:24 <ttx> For this one I was mostly wondering about the "where it makes sense, the project cooperates with existing projects rather than gratuitously competing or reinventing the wheel" requirement
20:31:33 <cloudnull> annegentle: we have https://github.com/stackforge/os-ansible-deployment and https://github.com/stackforge/os-ansible-deployment-specs
20:31:35 <ttx> so whether Cue was not accidentally duplicating a lot of the work already done within Trove to handle clusters of data things
20:31:56 <ttx> i.e. are the Cue first-class resources sufficently different from Trove's to make a separate project worth it
20:32:01 <annegentle> cloudnull: ok I'm not seeing the os-ansible-deployement rep in the proposed patch
20:32:13 <sdague> ttx: would Sahara be considered a duplication of Trove?
20:32:19 <mordred> well, as a person who has used trove apis in anger - I can say that if I could ALSO get a rabbit from it it would be very strange
20:32:28 <flaper87> ttx: I think they are very different
20:32:39 <russellb> mordred: "in anger" ?  heh
20:32:41 <ttx> sdague: well, a map/reduce cluster has significantly different properties from a queue or a DB
20:32:43 <sdague> this feels very much like Trova and Sahara except with a different base resource
20:32:44 <mordred> and also - I'd love to be abl to request a rabbit and not know anything about how it works
20:32:50 <ttx> a queue and DB are about storing and retrieving data
20:32:58 <ttx> and backup and users
20:33:02 <palendae> annegentle: Line 1177? https://review.openstack.org/#/c/191105/2/reference/projects.yaml
20:33:15 <mordred> sure - but to me the "don't duplicate" woudl be if this was another dbaas service
20:33:17 <russellb> i think they're different enough
20:33:20 <flaper87> ttx: queue's are not always about storing data
20:33:27 <vipuls> I think the semantics of provisioning, management may be shared across all of these projects, but the API is definitely radically different
20:33:33 <flaper87> s/queues/messaging systems/
20:33:33 <cloudnull> annegentle:  i added into the change set but its not in the body of the commit message . i can update it if you'd like to see it there.
20:33:37 <sdague> honestly, things went really wrong when we said "everything that is metadata must go in glance" and "everything that touches a network must go in neutron"
20:33:38 <ttx> flaper87: sure but cue doesn't do data plane
20:33:50 <sdague> so I don't know why we'd start doing that again
20:34:01 <flaper87> I believe it'd be fair that it could even deploy other messaging systems that are not broker based
20:34:03 <sdague> especially as it's a thing, with a team, doing a thing
20:34:07 <ttx> I just want to avoid Trove and Cue copy-pasting 90% of their code
20:34:23 <flaper87> ttx: I believe they can collaborate in some areas
20:34:25 <ttx> or reinventing what the other already wrote
20:34:27 <jeblair> sdague: agreed; i wonder if there is similarity around the deployment mechanisms in these projects that could be factored out, but the end product is different enough to warrant separate projects
20:34:29 <flaper87> but I don't think the use-case is the same
20:34:41 <flaper87> jeblair: I believe there is
20:34:42 <jeblair> ttx, flaper87: ^ to that point
20:34:47 <flaper87> :D
20:34:52 * flaper87 beat jeblair
20:34:55 <flaper87> w000t
20:35:06 <jeblair> flaper87: you win this round!
20:35:07 <vipuls> flaper87: +1
20:35:08 <ttx> I'm fine with it if everyone else thinks it's different for a purpose other than just being different
20:35:17 <lifeless> so
20:35:22 <lifeless> I don't understand that argument
20:35:39 <lifeless> if we've *truely* moved from saying 'X is openstack' to asking 'are you openstack'
20:35:47 <sdague> lifeless: ++
20:35:49 <lifeless> then being different shouldn't matter
20:35:57 <lifeless> Someone might want to try to do it better
20:36:03 <lifeless> whatever
20:36:04 <ttx> Well, being openstack is also about collaborating where possible
20:36:06 <ttx> lifeless: I hate gratuitous duplication of effort
20:36:09 <lifeless> sure
20:36:20 <lifeless> but we just set up a governance structure designed to bring in effort
20:36:21 <ttx> i just want to make sure this is not one of those cases
20:36:27 <lifeless> we're going to get overlap
20:36:29 <sdague> yeh, but we're going to get some of it. And it's not like the Trove team showed up and said "don't do that"
20:36:30 <flaper87> I think the point of collaboration where possible is fair and I believe there are areas where these projects can collaborate
20:36:31 <lifeless> because the world isn't neat.
20:36:33 <ttx> and that it's not "gratuitous"
20:36:40 <flaper87> it's a good thing that vipuls used to be part of trove as well
20:36:44 <lifeless> right
20:36:47 <flaper87> so, that makes it even easier
20:36:48 <sdague> if the Trove team was strongly objecting here, I think that would be a different thing
20:36:53 <lifeless> right
20:37:00 <lifeless> I think we should be letting concerns like that bubble up
20:37:02 <jeblair> lifeless: i think in the future we may choose to allow _real_ duplication, and even then, i think it's worth discussing and being deliberate about.  i don't think we are even that far down the line with this project.
20:37:06 <lifeless> not impose them ourselves
20:37:08 <flaper87> FWIW, vipuls is (used to) be a trove core
20:37:16 <ttx> I guess you know better since it's a HP thing
20:37:17 <lifeless> jeblair: agreed
20:37:18 <flaper87> vipuls: amiright ?
20:37:23 <vipuls> flaper87: correct :D
20:37:27 <vipuls> used to be ;)
20:37:31 <flaper87> there
20:38:11 <lifeless> ttx: so, the HP angle isn't where I'm coming from here. I mean - yes, initiated by HP, because what they felt the HP cloud users wanted and needed didn't exist
20:38:12 <sdague> I also think I remember people asking for a thing like this during the very long zaqar integration debate, so it's kind of cool someone showed up and filled that hole.
20:38:30 <mordred> sdague: ++
20:38:32 <lifeless> ttx: but my main thing is I want us to really actually truely get out of the way
20:38:53 <lifeless> ttx: and let folk already in the tent come to us with concerns about new entrants
20:38:54 <mordred> that's actually why I thnk it's good - it's what a bunch of people thought zaqar was and those peopel were happy about that idea
20:38:57 <flaper87> sdague: yeah, I believe it was born close (or right after) Zaqar's second grad attempt
20:39:00 <sdague> I do think it's another project that warrants the diverity:danger flag, and we should probably take it up.
20:39:05 <ttx> lifeless: you'll note I'm not opposing it at all, not even voting -1. Just want to put that dead fish on the table
20:39:09 <lifeless> sure
20:39:18 <lifeless> let me slice it up some more, I like sashimi
20:39:31 <flaper87> I think there's value behind Cue, especially if it'll take the pain of maintaining rabbitmq away from me
20:39:33 * jeblair just ate sushi during the last meeting
20:39:33 <flaper87> :P
20:39:37 * jeblair doesn't feel so well
20:39:44 <ttx> if you're all comfortable wityh it, I am too
20:39:48 <flaper87> jeblair: I *just* ate sushi
20:39:51 <flaper87> :P
20:39:58 <ttx> we ahve 8 yes, I can approve it now
20:40:11 <ttx> jaypipes voted -1 though :)
20:40:42 <jaypipes> ttx: yeah, sorry, I don't really see much point to this, and have the same concerns jogo did.
20:40:42 <vipuls> jaypipes: didn't leave much of a reason :|
20:41:10 <ttx> well, "not much point" is not a valid objection, I think
20:41:41 <ttx> we are out of the business of judging if there is a point. Still in the business of judging if it will hurt a lot more than it helps, but that's about it
20:41:41 <annegentle> I haven't looked at Cue til now, so haven't voted.
20:42:06 <jaypipes> vipuls: IMHO, the Cue project is trying to put a REST API around stuff that should be in Puppet manifests or Murano app manifests, and Pacemaker OCF resource agents, and I don't agree with it.
20:42:07 <ttx> ok, Looks like Gerrit is back, so I'll proceed in approvals
20:42:28 <russellb> jaypipes: yeah, i honestly feel the same way
20:42:38 <russellb> i just don't care enough to -1 it, i guess
20:42:38 <ttx> last call for votes on the previously-discussed changes
20:42:48 <russellb> i see projects in this category as questionably useful
20:43:02 <jogo> jaypipes: s/Trove/Cue/ or s/Trove/Murano and that is still valid
20:43:05 <russellb> other people seem to think it's helpful, so wfm ...
20:43:22 <vipuls> jaypipes: If you read some of my comments back to jogo i don't think it's that simple.  It's all about presenting an API that is user-friendly and not shoving everything into a one-fits-all
20:43:23 <jaypipes> vipuls: I would vote the same way if someone proposed an OpenStack project that reimplemented Puppet in an OpenStack RESTful API.
20:43:32 <ttx> approving starterkit at 7 votes, ansible at 8 votes and cue at 9
20:43:48 <sdague> yeh, I feel like "can be done with Puppet" means we throw out trove, heat, sahara, murano, and a whole bunch of other stuff
20:43:49 <jaypipes> vipuls: users don't want to deal with MQ clusters via a REST API.
20:43:59 <mordred> jaypipes: some might
20:44:00 <vipuls> sdague: +1
20:44:02 <jaypipes> s/MQ clusters/MQ cluster management/
20:44:16 <flaper87> My agreement with this comes from the fact that DBs and Messaging systems are things you *need* to put your app in the cloud
20:44:21 <mordred> jaypipes: I'd rather get an HA rabbit from my cloud than deploy one with puppet
20:44:31 <vipuls> jaypipes: could you not say the same thing by s/MQ Clusters/databases?
20:44:37 <flaper87> I don't think we are going to approve all projects willing to deploy something and take care of the lifecycle
20:44:41 <lifeless> jaypipes: isn't that zaqar?
20:44:43 <vipuls> i think we've seen the opposite is true
20:44:44 <mordred> jaypipes: so, count me in the set of users who run things in clouds who would use this for his rabbit needs
20:44:50 <lifeless> ah, s/ helps ;)
20:44:57 <flaper87> lifeless: I could see Zaqar being deployed by Cue
20:45:03 <ttx> flaper87++
20:45:04 <jaypipes> mordred: I'd rather not reimplement Puppet and Pacemaker in a REST API.
20:45:06 <flaper87> but it doesn't necessarily has to be Zaqar
20:45:08 <lifeless> flaper87: right,I was replying to an abbreviated comment
20:45:12 <ttx> Im fine with REST APIs to set up Dbs and Queues
20:45:16 <lifeless> you could also say the same thing about nova
20:45:17 <mordred> jaypipes: I understand that you would not use it. please undertand that I would
20:45:29 <lifeless> users don't want to interact with VM cluster management via a REST api... but they do
20:45:33 <mordred> lifeless: ++
20:45:40 <flaper87> I don't think we'll have a REST API to deploy.... PUT_THE_SERVICE_RUNNING_IN_YOUR_HOME_SERVER_HERE
20:45:41 <jaypipes> mordred: sure, fair enough. and I would just point you at Murano and say "hmm, that is already done."
20:45:42 <ttx> Alright, this has enough votes to pass, approving now
20:45:52 <flaper87> at some point we gotta stop
20:46:10 <flaper87> but queues and dbs? You ain't going to deploy a distributed app without those
20:46:11 <sdague> flaper87: honestly, why. If people do a thing, find their audience, it's fine
20:46:11 <mordred> jaypipes: possibly so - I think murano is a fine solution to the problem space as well
20:46:20 <jaypipes> vipuls: yes, you absolutely can say the same about trove.
20:46:34 <ttx> Let's move on... lots to cover still
20:46:37 <ttx> #topic Add Solum to OpenStack Projects List
20:46:43 <flaper87> sdague: mmh, would you have a service that deployes apache ?
20:46:44 <vipuls> thanks folks!
20:46:46 <ttx> #link https://review.openstack.org/190949
20:46:47 <flaper87> deploys
20:46:47 <mordred> aw. but I ahven't  had a good argument with jaypipes in years. :)
20:46:52 <flaper87> fuck english
20:46:52 <jaypipes> lol
20:46:54 <ttx> We discussed this one last week but couldn't gather enough votes for it to pass
20:47:08 <ttx> it now has... 5
20:47:33 <ttx> Questions on that that may or may not make you vote ?
20:47:36 <jaypipes> vipuls, mordred: bottom line, I recognize there is a fine line here...
20:47:58 <jaypipes> vipuls, mordred: and I'm just logging my general feeling about duplication of purpose, that's all.
20:48:01 <mordred> jaypipes: ++
20:48:17 <markmcclain> ttx: sorry missed this one earlier... added my +1
20:48:28 <ttx> arh, merge conflict fun
20:48:34 <mordred> I think solum is clearly a set of people who are us
20:48:35 <vipuls> jaypipes: yep agreed, appreciate the feedback
20:48:36 <adrian_otto> I can post a revision
20:48:40 <ttx> adrian_otto: please do
20:48:49 <adrian_otto> now, or after more votes?
20:48:55 <annegentle> I got my questions answered just a few minutes ago
20:48:58 <ttx> it may reset the votes, so now
20:48:58 <devkulkarni> +1 mordred
20:49:07 <adrian_otto> ok, will do
20:49:23 <sdague> jaypipes: I also don't feel like "well, we let Murano in so now it owns the entire space of all service deploys" because if I knew that was a thing, I'd have voted against that. I felt that was a way we were enabling users, not excluding other ways.
20:49:32 <ttx> adrian_otto: ping us when done
20:49:51 <ttx> In the mean time I'll cover something else
20:49:54 <ttx> #topic Add type:library and type:service tags
20:49:57 <ttx> #link https://review.openstack.org/191891
20:50:00 <ttx> #link https://review.openstack.org/191892
20:50:13 <ttx> Those are release-related tags, but I think type:* is more relevant for what we describe here
20:50:18 <ttx> We could have type:doc one day for example
20:50:21 <jaypipes> sdague: fair enough.
20:50:43 <ttx> merge conflicts there too, added too many new projects
20:50:56 <flaper87> there are merge conflicts everywhere
20:50:58 <dhellmann> yes, these new tags are meant to be used by a query tool we have in the release repository so we can find a list of all of the things of a type where we manage the release
20:51:17 <flaper87> oh noes
20:51:19 <dhellmann> let's just vote, and we can rebase patches as needed after we're done and let ttx merge them -- we've done that many times before
20:51:22 <flaper87> I'll cast my vote after the rebase
20:51:23 <ttx> If there are no questions about them I can merge those when they reach 7 yes during the week
20:51:23 <sdague> my only question on the service thing was horizon being in there, because it's not a service per say, so the wording is a bit confusing
20:51:40 <sdague> not that I know if there are any better words
20:51:43 <ttx> some libs are not libs per se either :)
20:51:43 <dhellmann> why is horizon not a service?
20:51:55 <sdague> it's not an endpoint?
20:51:57 <mordred> dhellmann: no rest api?
20:52:06 <dhellmann> service != rest service
20:52:15 <dhellmann> service == long running thing
20:52:38 <dhellmann> to differentiate it from command line tool, library, docs, etc.
20:52:40 <sdague> ok, that's fine.
20:52:52 <mordred> I think with keystone having a "service catalog" ... I hear service and I think "something that registers with keystone"
20:53:00 <dtroyer> dhellmann: would it also be correct for service == !library?  for things that might have either of these tags?
20:53:01 <mordred> which I know flys in the face of the meaning of the actual word
20:53:03 <dhellmann> yeah
20:53:03 <mordred> but this is cloud
20:53:07 <mordred> where we redefine everything
20:53:09 <lifeless> maybe we should say daemon
20:53:11 <lifeless> but meh
20:53:19 <dhellmann> dtroyer: the intent is for the type tags to be mutually exclusive, so that each repo only has one type
20:53:22 <mordred> say daemon if we mean something other than "something we register with keystone"
20:53:25 <ttx> dtroyer: except there are things there that are not service and not library
20:53:29 <ttx> like a -specs repo
20:53:31 <jeblair> it's either that or 'project'
20:53:36 <mordred> jeblair: or 'tenant'
20:53:37 <sdague> or policy
20:53:37 <ttx> or tenant
20:53:41 <dtroyer> ttx: right, that's what I'm curious about
20:53:44 * Rockyg is pretty sure it's a UI
20:53:47 <flaper87> kk
20:53:50 <fungi> s/service/daemon/?
20:53:58 * fungi ducks back into the bikeshed
20:54:02 <sdague> yeh, it's fine, I'm sorry I openned the peanut gallery
20:54:03 <ttx> ok, let's see what can still be merged in this rebase mess
20:54:10 <ttx> #topic CLA / DCO workplan on Board Agenda
20:54:17 <ttx> #link http://lists.openstack.org/pipermail/foundation-board/2015-June/000074.html
20:54:22 <ttx> That email did not exactly trigger a massive thread of board responses
20:54:34 <dhellmann> alan did reply, though
20:54:42 <ttx> oh, recently ?
20:54:49 <dhellmann> http://lists.openstack.org/pipermail/foundation-board/2015-June/000080.html
20:54:58 <sdague> well, there was a reply that yes, someone was going to discuss it
20:55:08 <ttx> err.. I missed that reply
20:55:19 <sdague> however, it was really light on details
20:55:32 <sdague> I tried to write up what I remembered we'd kind of agreed to - http://lists.openstack.org/pipermail/foundation/2015-June/001984.html
20:55:33 <ttx> sdague: you posted that agenda topic, what do you want from it ?
20:55:36 <russellb> yeah, basically we need the written version that alan refers to
20:55:47 <jeblair> i think we were hoping for the board to formally vote on something to make sure we are really on the same page
20:55:49 <sdague> because I can't post to foundation-board, it's board folks only
20:56:05 <sdague> the foundation ML post has not gotten any board member responses on it
20:56:05 <mordred> yah - and I think the board is waiting on eileen to write something up, is my takeaway from that email from alan
20:56:10 <ttx> maybe one of our resident board members could forward that
20:56:33 <russellb> i sure hope board members see the foundation list too ...
20:56:38 <mordred> and there is a time frame associated with alan's expectations on receiving that
20:56:40 <russellb> but i'm not sure there's much more we can do at the moment
20:56:45 <sdague> I hope that http://lists.openstack.org/pipermail/foundation/2015-June/001984.html  represents what others remember from that meeting, if not, corrections welcomed
20:56:49 * dhellmann wonders if anyone not on the board can subscribe to the foundation-board list
20:56:54 <russellb> dhellmann: yes
20:57:02 <russellb> actually i don't know
20:57:03 <sdague> dhellmann: but they can't post
20:57:06 <russellb> archives are open at least
20:57:07 <mordred> sdague: it looked good to me
20:57:09 <ttx> like openstack-tc really
20:57:13 <sdague> right
20:57:14 <russellb> mordred: sdague ack, looked good to me too
20:57:16 <dhellmann> russellb: ok. I thought I had found all lists like this and subscribed, but I guess I missed one
20:57:26 <russellb> dhellmann: it's relatively new
20:57:34 <dhellmann> russellb: thanks, I'll use that as an excuse ;-)
20:57:38 <Rockyg> dhellmann: russellb:  No.
20:57:48 <ttx> ok, looks like it triggered the expected surge in caring about this
20:58:04 <sdague> anyway, the board meeting is coming up soon enough, that I assume there are procedural issues with having a resolution in a state early enough to vote on
20:58:11 <russellb> sdague: thanks for writing it up, like i said, it did reflect my interpretation as well
20:58:16 <sdague> and I don't want the results to be "oh... that wasn't soon enough, punt to fall"
20:58:20 <fungi> the old (private) foundatin-board ml was renamed to make it less attractive for board members to arbitrarily post to, and this new public ml was created to take its place
20:58:34 <ttx> sdague: ok, I don't think there is much more to discuss at this point ?
20:58:43 <dhellmann> fungi: thanks
20:58:45 <sdague> ttx: probably not
20:58:50 <adrian_otto> revision 3 of https://review.openstack.org/190949 available for votes
20:58:56 <fungi> i migrated the subscribers from the private list to the new one, but anyone else who wants so subscribe should be able
20:59:01 <russellb> sdague: it's in eileen's court to prepare.  i think you should feel free to reach out to her.  she represents your company :)
20:59:10 <ttx> alright, please reapply votes and I'll approve when it reaches 7 (if it does)
20:59:16 <ttx> #topic Workgroup reports
20:59:17 <adrian_otto> tx, ttx
20:59:21 <sdague> russellb: will do :) I wanted to do open channels first though
20:59:24 <ttx> * Project Team guide workgroup
20:59:28 <ttx> I'm happy to announce that the virtual sprint last week was a success, with most chapters having an initial version now
20:59:31 <ttx> Now we need to publish it somewhere
20:59:36 <ttx> * Communications workgroup
20:59:39 <ttx> annegentle, flaper87: o/
20:59:40 <russellb> sdague: cool, hopefully we keep it moving
20:59:45 <ttx> you have one minute
21:00:35 <ttx> or not
21:00:57 <ttx> annegentle: I suspect a new blog post is coming ?
21:01:09 <annegentle> heh
21:01:18 <annegentle> I think we'll need one this week, yep. I'll start a draft flaper87
21:01:30 <dhellmann> lots approved today to talk about :-)
21:01:31 <ttx> oh and everyone, Cue was rebased at https://review.openstack.org/#/c/191173/ so please reapply votes there too
21:01:46 <ttx> I'll pick them up tomorrow
21:01:58 <ttx> And that closes it
21:02:00 <ttx> sorry for the dropped items, my agenda was based on a less eventful road on the first item on the agenda
21:02:08 <ttx> #endmeeting