20:03:02 <ttx> #startmeeting tc
20:03:02 <openstack> Meeting started Tue Jul  7 20:03:02 2015 UTC and is due to finish in 60 minutes.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:03:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:03:05 <openstack> The meeting name has been set to 'tc'
20:03:10 <ttx> Alright! Our agenda today:
20:03:13 <jgriffith> o/
20:03:15 <ttx> #link https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
20:03:15 * edleafe is also lurking
20:03:29 <maishsk> o/
20:03:38 <ttx> And now for something completely different... a non-consensual topic
20:03:41 <jeblair> o/
20:03:44 <ttx> #topic Add neutron to starter-kit:compute
20:03:52 <ttx> #link https://review.openstack.org/196438
20:03:57 <ttx> I'll timebox this one to 30min so that we have time left to cover other items
20:04:09 <ttx> I summarized my view on this issue in a comment on the review this morning.
20:04:13 * jaypipes requests that we put this particular vote off for 2 weeks.
20:04:22 <ttx> Basically I think the only viable option is to accept this, or consider that the situation is so broken that we can't even recommend a "starter kit" that is not a dead end
20:04:27 <russellb> not sure what else to add other than what i've said on the review
20:04:32 <ttx> jaypipes: what will 2 weeks give us ?
20:04:49 <jaypipes> ttx: a chance to get the updated networking guide docs done.
20:04:49 <annegentle> so my sense is this question is one docs has wrestled with for years now.
20:04:54 <dtroyer> my problem is just the timing…it feels bad to add a dangling pointer to something that isn't there (or finished?)
20:04:57 <russellb> IMO, a tag like this should be guiding doc work, not be gated on it
20:05:05 <mestery> huh?
20:05:06 <ttx> jaypipes: in the mean time we recommend a dead end though
20:05:08 <mordred> I agree with russel
20:05:10 <dougwig> jaypipes: the content is done.  the install guide tweak is behind their conversion to RST.
20:05:11 <mordred> gah
20:05:12 <sdague> I do think there is a timing issue, because if we're recommending the 4b from the network guide
20:05:13 <mordred> I agree with russellb
20:05:15 <markmcclain> russellb: ++
20:05:18 <mestery> +1000 russelb
20:05:18 <lifeless> ttx: o/
20:05:18 <annegentle> And, even in the Ops Guide, we made decisions about what architectures we documented.
20:05:21 <flaper87> russellb: ++
20:05:23 <lifeless> sorry for late - this is ECHILD time
20:05:28 <dhellmann> russellb: ++
20:05:32 <annegentle> and I agree, we need to ensure we know when the tag will be applied.
20:05:36 <annegentle> heh on ECHILD
20:05:41 <sdague> then we get people pointed at the install guide, and it's radically different from that, it causes pain and tears
20:05:42 <annegentle> they are very error prone
20:05:52 <annegentle> no tears
20:06:03 <dhellmann> sdague: one of the justifications given for even having a tag like this was to drive changes elsewhere, including documentation
20:06:05 <annegentle> there's no crying in OpenStack
20:06:15 <russellb> i don't see the tag itself as something people are consuming, it's guiding work that people consume, like docs
20:06:17 <dougwig> annegentle: lol
20:06:22 <maishsk> annegentle: depends on who you ask ;)
20:06:26 <edleafe> annegentle: oh, no - there's lots of crying!
20:06:27 <jgriffith> I have a question... I thought one of the proposals regarding Big-Tent wsa competing projects?
20:06:28 <russellb> and this sends a clear signal about what should be documented in starter docs
20:06:32 <mordred> I think it's important for us to show leadership and intent. people have been asking for clarity from that from us for a while - and saying clearly "neutron is what we expect" should not be particularly controversial
20:06:42 <russellb> mordred: +1
20:06:42 <mestery> mordred: well said sir
20:06:43 <jgriffith> IMHO nova-net wins that competition in many cases
20:06:44 <sdague> dhellmann: ok, so then there should be an updated patch to the tag doc right?
20:06:48 <maishsk> mordred +1
20:06:54 <sdague> because right now all this is is an add of a project
20:06:58 <mordred> jgriffith: we need to be clear taht this is not a competition between nova-net and neutron
20:07:01 <zaneb> russellb++
20:07:10 <flaper87> As others have also said in the review, one of the points of this tag is to not only show where to start from but also be the bases for something bigger
20:07:16 <sdague> with no background information, no additional context of "we mean in this kind of configuration", etc.
20:07:16 <flaper87> it also shows where we are headed
20:07:17 <mordred> jgriffith: nova-net is not what we want going forward, it just happens to still exist because $reasons
20:07:20 <dhellmann> sdague: are you objecting to adding the project, or that the patch to the governance repo is somehow incomplete?
20:07:20 <jgriffith> mordred: well, I kinda think for some it's become exactly that
20:07:30 <sdague> dhellmann: incompleteness
20:07:30 <mordred> jgriffith: right. we need to be much clearer about that
20:07:40 <jgriffith> mordred: well, maybe the collective "we" in the room, but not myself
20:07:47 <dhellmann> sdague: ok, I may be able to support that
20:07:48 <jgriffith> I'd be thrilled to see nova-net live on forever
20:07:55 <mordred> jgriffith: yes where we == the TC
20:08:00 <jgriffith> mordred: but I see you're point
20:08:12 <markmcclain> I'm still trying figure out what incompleteness there is? do we really thing there are folks waiting around just for us to pass this tag?
20:08:17 <ttx> flaper87: I agree starter kit is about growing after. Pointing people to an evolutionary dead end sounds counter productive at best
20:08:17 <mordred> jgriffith: I totally respect you on that ... and honestly, i do not think the TC needs to say "nova-net should be deleted"
20:08:18 <sdague> because I actually think that recommending http://docs.openstack.org/networking-guide/deploy_scenario4b.html as the starter kit is a good idea
20:08:27 <sdague> but this patch doesn't do that
20:08:30 <mordred> I think the TC needs to say "neutron is the focus and the future"
20:08:46 <mordred> sdague: I think the tag doesn't get that specific
20:08:49 <flaper87> mordred: ++
20:08:49 <jgriffith> mordred: yeah, so I'm cool with moving forward, but what would be interesting is going back to the idea of the neutron-on-training-wheels
20:08:55 <sdague> mordred: however, the background document did
20:09:00 <dtroyer> mordred: ++  but there might also need to be a Neutron starter kit…it's that big
20:09:01 <jgriffith> ie helper script to just let you set it up EZ/PZ
20:09:02 <mordred> sdague: I also think the starter guide should say "floating ips are a bad idea" - but the tag isn't quite that fine-grained :)
20:09:07 <sdague> like it called out nova multihost
20:09:12 <dougwig> jgriffith: have you read 4b from the deploy guide?
20:09:28 <mordred> sdague: I'd be more than happy to amend the patch to put more info into the backgroudn doc
20:09:30 <jgriffith> dougwig: I'll look at it again now... sorry, I have not
20:09:41 <dougwig> jgriffith: it's intended to be ez mode.
20:09:43 <mordred> sdague: because there isa  very clear "this is what you should look at to get started" part of this
20:09:58 <sdague> mordred: I'd be happy with +1ing this with the more specific background and guidance with the configuration
20:09:59 <mordred> annegentle: do we ahvea  new name for 4b yet? :)
20:10:01 <annegentle> dougwig: one Q I wanted to ask you is whether you saw a docs spec that says the install guide will document "provider networks with Linux bridge" I haven't seen that yet.
20:10:02 <mordred> sdague: awesome
20:10:04 <jgriffith> dougwig: intedend or is :)
20:10:13 * mordred will take on that as a task for next week if everybody is good with that?
20:10:15 <dougwig> annegentle: https://review.openstack.org/#/c/191077
20:10:16 <russellb> jgriffith: is
20:10:20 <annegentle> mordred: 4b = provider networks with Linux bridge
20:10:22 <flaper87> lets just be careful not to turn the tag in documentation
20:10:27 <flaper87> just saying
20:10:28 <annegentle> dougwig: ah it hasn't landed yet
20:10:30 <mordred> flaper87: totally
20:10:36 <russellb> 4b is just provider networks
20:10:43 <annegentle> russellb: 4a is OVS
20:10:50 <russellb> right.
20:11:02 <jaypipes> OK, so I thought starter-kit:compute was all about having a *simple* way to get compute resources up and running. One of the suggestions that I think sdague had on the review was to have TC members (preferably not Neutron devs) go and follow the install guide with neutron and see whether that "simple to install and get up and running for compute" objective was actually the case. This is the reason I was asking for a
20:11:03 <jaypipes> dditional time. So I could go do that.
20:11:08 <sdague> and I'd be even happier if the install guide lead with the 4b scenario
20:11:13 <dougwig> annegentle: right, but based on conversations with the docs folks, i'm not expecting any surprises there.
20:11:18 <mordred> sdague: ++
20:11:19 <edleafe> Is the intent for "starter kit" to be a base to grow from? If so, then it should include Neutron
20:11:20 <dhellmann> hmm, I don't see anything in the tag doc that refers to specific parts of the install guide.
20:11:28 <ttx> I like the idea of pointing people to ez-neutron (a.k.a. 4b) which is not as much of an evolutionary dead end
20:11:28 <annegentle> the way we handled it in the Ops guide was "these features are supported by the example arch but are optional"
20:11:30 <annegentle> #link http://docs.openstack.org/openstack-ops/content/example_architecture.html#example_architecture-nova
20:11:40 <mordred> edleafe: I would hate for the starter kit to get you to a thing we want you to delete
20:11:41 <maishsk> jaypipes: that is an awesome idea!
20:11:43 <dhellmann> it seems like any changes outside of the governance repo should follow from this change
20:11:45 <mestery> jaypipes: With regards to simple, I believe sdague also followed the guide and indicated cinder shoudl be removed if that was the case
20:11:51 <mestery> given simplicity and all
20:11:52 <annegentle> so even there, a dashboard is optional
20:11:56 <ttx> edleafe: yes it is a starter kit, not an endgame
20:12:01 <mordred> ttx: ++
20:12:02 <edleafe> mordred: well, yeah
20:12:06 <jaypipes> mestery: perhaps that would indeed be the case.
20:12:15 <mestery> jaypipes: Yup, that's my point
20:12:15 <jgriffith> mestery: really?
20:12:16 <dougwig> arguably we can point ALL people at 4b, since adding OVS or tenant networking later is straightforward.
20:12:17 <mestery> Why stop with neutron?
20:12:18 <jgriffith> mestery: hmm... ok
20:12:21 <jaypipes> mestery: I'm not bashing Neutron, BTW. I'm asking for a little time to do some research.
20:12:22 <mestery> Surely other things are complex
20:12:25 <edleafe> ttx: precisely. That's why neutron should be included
20:12:26 <lifeless> so yeah I'm totally confused here
20:12:30 <mestery> jgriffith: Really
20:12:35 <sdague> dhellmann: well, there was in the initial patch
20:12:45 <dhellmann> sdague: but we didn't approve that one, right?
20:12:47 <jgriffith> mestery: I hardly see the comparison but that's fair enough
20:12:49 <sdague> https://github.com/openstack/governance/commit/c3200862f5132f8154c5a5091d500f38a663f50c#diff-11bfc18e33f512c24fbd900652229c4dR186
20:12:50 <annegentle> and I don't know if it's still true, but for a while you couldn't install swift + dashboard only, you had to have identity, compute, and images iirc
20:12:55 <lifeless> AIUI start-kit was -explicitly- 'not a scaled-down poc but a platform for learning'
20:12:56 <jgriffith> mestery: if vgcreate is too difficult remove it
20:12:57 <sdague> yes, we did, it apparently was changed
20:13:06 <edleafe> mestery: because nova-network is a dead-end
20:13:07 <mestery> jgriffith: lol, it's all about perspetive my friend
20:13:09 <annegentle> so we also need to ensure the technical feasibility of this use case
20:13:20 <jgriffith> mestery: indeed
20:13:27 <mordred> sdague: I don't really see where to put a mention of 4b in the tag doc - can we connect after the meeting and kibitz on that?
20:13:51 <russellb> technical feasibility - this is very commonly used
20:13:53 <lifeless> So IMO it still should be 'the minimum needed to get compute', not 'the recommended components everywhere'
20:13:55 <mordred> lifeless: right - but we don't want to teach someone one set of skills, then have those be totally unapplicable to a bigger deployment
20:13:59 <markmcclain> I'm still not certain why we need to document 4b specifically?
20:14:04 <lifeless> mordred: but we know we're going to do that
20:14:13 <markmcclain> seems that the tag and the specifics of the starter should be decoupled
20:14:18 <lifeless> mordred: sql auth skills are not applicable to SAML federation
20:14:20 <flaper87> lifeless: it's the minimum needed to get compute and grow from there
20:14:21 <annegentle> markmcclain: as an api-compat way forward (I think)
20:14:30 <markmcclain> we don't prescribe that nova should kvm
20:14:36 <lifeless> flaper87: it was *explicitly* framed as *not-that* last I read it.
20:14:38 <dougwig> can we dial back the rhetoric.  nova-net, if useful for you, is not a dead end as long as someone wants to maintain it.  and dissing one team vs another is also not productive.   does 4b make things easy enough for everyone?  if so, it's has many more branching out possibilities than nova-net.
20:14:38 <markmcclain> the docs just point you that direction
20:14:43 <zaneb> lifeless: it's supposed to be a starting point that people can expand from
20:14:47 <mordred> lifeless: that's a bit different than "the conceptual model of nova-net and neutorn are completely different"
20:14:53 <ttx> lifeless: it's name "starter" though
20:15:06 <ttx> so it's as explicit as it gets
20:15:15 <flaper87> lifeless: mmh, I actually remember it differently. I remember we saying this is a gate to compute with openstack
20:15:17 <mordred> dougwig: I agree - I do not think we need to ditch anything or delete anything or make anyone feel bad about what they want
20:15:22 <sdague> right, and I agree the growth path from nova-net to neutron is not very clear, I think there are a lot of comments in there about that in the review
20:15:46 <zaneb> lifeless: "[W]e'd like this to be a solid bit of 'seed corn' from which a larger and richer OpenStack deployment can be built out over time." <- doesn't get more explicit than that
20:15:51 <flaper87> with nova-net it'd be: "This is how you can get an openstack playground that you'll likely trash"
20:16:04 <jaypipes> Again, I ask... can we please just give this vote another week so some of us can do some research?
20:16:04 <sdague> so I'm happier with a simple neutron scenario that a user could expand more naturally, which I think we now kind of figured out with 4b
20:16:11 <mestery> flaper87: When you put it that way
20:16:24 <lifeless> zaneb: ok,  I missed that getting in
20:16:30 <flaper87> mestery: :D
20:16:43 <mordred> jaypipes: ++
20:16:50 <ttx> jaypipes: I'm fine with deferring. I just don't want us to be stuck too long
20:16:50 <mordred> jaypipes: I believe the patch wants a rev as well
20:16:56 <flaper87> jaypipes: I'm good with deferring too
20:17:01 <lifeless> but its internally inconsistent
20:17:02 <jaypipes> just one week...
20:17:05 <flaper87> and the patch needs to be updated anyay
20:17:07 <lifeless> 'All projects must be a required to put a persistent VM on the network.'
20:17:10 <lifeless> and
20:17:11 <mordred> ttx: I'm going to work with sdague on seeing if we can get his converns met in the patch
20:17:11 <sdague> delay is fine as well, it might even mean that we can have the install guide docs going forward
20:17:11 <flaper87> anyway*
20:17:17 <lifeless> 'The projects in this tag should make it easy to add new OpenStack projects into such a deployment over time.'
20:17:23 <lifeless> we can't have both, today.
20:17:26 <Daviey> Will there be a starter-kit:neutron?
20:17:28 <lifeless> if nova-net dies we can.
20:17:28 <jgriffith> I'm with jaypipes if even "I" can get it setup and actually working this time I'll gladly upvote
20:17:41 <sdague> annegentle: any idea what the timeline is for the install guide conversion to rst?
20:17:44 <annegentle> what if for this release it's nova-net, and next release it's neutron, is that acceptable as long as the provider network scenario will offer API compat
20:17:45 <markmcclain> jaypipes: I don't see what a week will yield?  The other services don't have a prescriptive formula... we just save you need them in a starter
20:17:57 <sdague> annegentle: they aren't API compat
20:17:58 <jgriffith> 1 week... or even 1 day to convince myself
20:18:04 <annegentle> sdague: by release date, Install Guide is not relevant until release. So for now we have the Install Guides we have.
20:18:05 <mordred> ttx: fun story - I can't WIP this patch :)
20:18:06 <mestery> markmcclain: +1000
20:18:06 <sdague> that is part of the challenge
20:18:08 <zaneb> lifeless: if you considered nova-net a separate project to Nova, there'd be no conflict
20:18:22 <lifeless> zaneb: indeed!
20:18:22 <ttx> mordred: fun heh. You ened to prefix title with [WIP]
20:18:22 <annegentle> sdague: ohh.
20:18:28 <annegentle> sdague: is there any API compat?
20:18:33 <russellb> i'm surprised it's taking this for people to actually go try to use neutron
20:18:34 <russellb> but ok
20:18:34 <mordred> annegentle, sdague: they aren't even conceptually compatible. the way you use them is very different
20:18:39 <dougwig> annegentle: the upgrade is *not fun*.  the sooner we can stop leading people that way, the better.  IMO.
20:18:40 <annegentle> sdague: because, what if "seed corn" for some is "give me an interop cloud"
20:18:40 <lifeless> zaneb: if Nova considered nova-net a separate project we'd have had very different discussions over the last 18 months
20:18:42 * mestery shrugges
20:18:53 <mordred> annegentle: the differences in nova-net and neutron are giant
20:18:57 * flaper87 helps mestery shrug
20:19:01 <mordred> annegentle: MUCH bigger than the other interop differences
20:19:02 <russellb> a week isn't harmful
20:19:03 <jgriffith> mordred: +1
20:19:08 <lifeless> FWIW I'm a huge fan of getting folk on Neutron from the start
20:19:09 <lifeless> but
20:19:11 <jaypipes> markmcclain: it will ease my mind, that's all.
20:19:16 <jaypipes> I don't want to vote no on this.
20:19:23 <lifeless> I also want to deliver the thing sdague reports the operators meetup asked for
20:19:36 <zaneb> lifeless: I submit that you are arguing semantics at this point ;)
20:19:48 <lifeless> zaneb: aren't all arguments semantics?
20:19:52 <lifeless> zaneb: :)
20:20:13 <ttx> Alright, so mordred will work on a new patch, Jay will spend some time convincing himself, and we plan to have that back in two weeks
20:20:15 <zaneb> yes, but not all arguments are _only_ semantics ;)
20:20:16 <Daviey> mordred: Has a gap analysis been drafted?
20:20:25 <ttx> although I'll likely not be around in two weeks thanks to OSCON
20:20:27 <jaypipes> tteggel: one week is fine.
20:20:29 <mestery> A gap analysis?
20:20:31 <mestery> YEs
20:20:32 <russellb> Daviey: several of them
20:20:33 <mestery> Last year
20:20:33 <russellb> ffs
20:20:34 <jaypipes> oops... ttx.
20:20:35 <mestery> Many times
20:20:38 <mestery> many many times
20:20:40 <mestery> But
20:20:49 <dougwig> a gap analysis is necessary for a nova-net vs neutron deprecation discussion.  the starter-kit is not that.
20:20:56 <mordred> ++
20:20:59 <ttx> Is my summary ok with everyone ?
20:20:59 <markmcclain> jaypipes: ok.. I just don't see the state of world shifting in meaningful way
20:21:00 <jaypipes> ttx: I think one week is fine.
20:21:02 <sdague> right, the starter kit is a different thing
20:21:03 <mordred> ttx: ++
20:21:08 <flaper87> there seems to be consensus that we should defer to next week
20:21:11 <ttx> jaypipes: one week it is
20:21:14 <flaper87> lets do it
20:21:14 <mestery> If we can't agree on the starter kit thing here, deprecation seems pretty unlikely
20:21:18 <flaper87> ttx: it does
20:21:19 <russellb> works for me
20:21:23 <ttx> #agreed mordred will work on a new patch, Jay will spend some time convincing himself, and we plan to have that back in one week
20:21:25 <mordred> mestery: yah man
20:21:38 <jaypipes> markmcclain: the state of my world can change with an afternoon of me digging into a couple things. thanks for your understanding. :)
20:21:38 <sdague> annegentle: so, is there no way to update the kilo guide to include this scenario?
20:21:41 <ttx> didn't expect us to come to a conclusion this week anyway
20:21:56 <dougwig> for anyone non-neutron that digs into 4b and has issues, PLEASE get that feedback to us somehow.
20:22:00 <annegentle> sdague: nor all the prior install guides and Ops Guide that have nova-net
20:22:13 <sdague> annegentle: why?
20:22:15 <annegentle> sdague: I mean, of course anything is a matter of code. But wow man. That's a lot to ask.
20:22:30 <mordred> I'm fine with it being forward looking patches for the future
20:22:58 <sdague> ok, I just get concerned with "hey, this is the starting point you should check out" and then no install guide support to get them there
20:23:01 <annegentle> sdague: let's rewrite all the code releases so that nova-net isn't even possible to install and config?
20:23:05 <annegentle> sdague: I mean come on.
20:23:13 <russellb> sdague: right, i think this is the clear signal about what the docs should cover though ..
20:23:19 <russellb> just a different way of looking at what the purpose is here
20:23:23 <sdague> russellb: sure
20:23:36 <annegentle> sdague: you could add a third path of course, we have ways to back port and publish
20:23:47 <russellb> us playing in our governance repo doesn't automatically get people using our prescribed set
20:23:50 <sdague> annegentle: right, that's what I mean, a 3rd path through the install guide
20:23:51 <annegentle> sdague: but that would take away from other work and seems a bit disruptive for little gain when we can just wait another release
20:23:51 <russellb> has to be "implemented"
20:23:59 <sdague> annegentle: ok
20:24:06 <ttx> Alright, I propose we move on
20:24:21 <sdague> btw, if TC members haven't recently, I'd highly recommend actually walking a manual install through the install guide
20:24:27 <annegentle> sdague: ++
20:24:31 <mordred> sdague: ++
20:24:32 <ttx> feel free to continue that discussion over the week, irc ML review etc
20:24:39 <sdague> it's pretty eye openning what we ask of folks
20:24:59 <flaper87> +1
20:25:02 <ttx> I bet it is.
20:25:02 <Rockyg> sdague: ++
20:25:09 <lifeless> sdague: clockwork orange eye opening style
20:25:14 <lifeless> sdague: to be precise
20:25:19 <annegentle> imagine testing it with packages that aren't quite done. across 3-4 distros
20:25:22 <annegentle> on deadline
20:25:26 <russellb> recommending manual install is a bit of fail on our part, anyway, but that's probably another discussion
20:25:26 <jgriffith> sdague: I sadly go through this at least a couple of times each release cycle
20:25:27 <sdague> yep
20:25:33 <annegentle> russellb: heh. had that discussion many times
20:25:38 <zaneb> sdague: as I understood it, the original purpose of this tag was for the TC to endorse what it thought should be front and center in the install guide. so I agree with russellb that there is no need to wait until after the fact
20:25:41 <ttx> there is a reason why those automatic installers are so pretty
20:25:50 <ttx> whi is a nice segway to our next topic
20:26:07 <sdague> zaneb: yep, like I said, I'm +1 with the specific guidance, and will be more happy when the docs catch up
20:26:11 <ttx> #topic Add Compass to OpenStack Projects
20:26:20 <ttx> #link https://review.openstack.org/196973
20:26:30 <ttx> I think Jay and Sean summarized my concerns about this one well
20:26:44 <ttx> First there is the question of being a generic deployment framework -- this is not limited to OpenStack, in fact one could argue that there is nothing OpenStacky about it
20:26:53 <wshao> Hi, I did reply to Sean and Jay's comments.
20:26:55 <ttx> doesn't use any Oslo lib, uses Flask, duplicates recipes...
20:27:08 <ttx> Second, I'm not sure we can consider Compass to follow the 4 opens, or at least not yet
20:27:16 <ttx> They only had one IRC meeting, and that was last week
20:27:22 <wshao> ttx: could you see my comments
20:27:25 <ttx> There is not a single thread on the dev ML, beyond Rocky's announcement of the project in 2013
20:27:36 <ttx> reading
20:27:43 <Rockyg> Wow, time flies!
20:27:47 <ttx> heh
20:28:05 <Rockyg> So, when compass started, there weren't recipes they could use.
20:28:06 <ttx> that said, it *is* shiny :)
20:28:20 <ttx> while it feels like an interesting project, I just have trouble seeing the OpenStack in it.
20:28:26 <Rockyg> maybe, it could now use ones in the openstack repo
20:28:26 <lifeless> so there seem to be two concern in the reviews
20:28:29 <lifeless> one - overlap
20:28:31 <wshao> It is openstack centric even though I point out the extensibility part of it
20:28:32 <lifeless> two - four opens
20:28:45 <lifeless> I think the four opens is a concern. That needs fixing
20:28:54 <wshao> lifeless: overlap with TripleO?
20:28:59 <Rockyg> So, working on the 4 opens
20:29:02 <lifeless> The overlap one though - we opened the door. We don't get to complain that folk want to walk through.
20:29:17 <Rockyg> and there are projects accepted that don't seem to have a team yet.
20:29:27 <sdague> Rockyg: which examples are those?
20:29:28 <ttx> lifeless: the project setill needs to be connected to our mission though ?
20:29:44 <ttx> lifeless: but yeah, I see what you mean
20:29:45 <mordred> ttx: it seems to be connected to our mission
20:29:48 <lifeless> ttx: it is no less connected than pbr :)
20:29:55 <Rockyg> Hey, you just said you want easier to install openstack ;-)
20:29:58 <ttx> mordred, lifeless: fair enough
20:30:13 <mordred> I agree with lifeless, I dont' think that can be a "go away" - but the four opens is a real important thing
20:30:19 <Rockyg> sdague: looking for projects...
20:30:23 <sdague> yeh, my concern is about the openness
20:30:33 <mordred> sdague: ++
20:30:42 <dhellmann> yeah, that's much more important to me than overlap -- allowing overlap was supposed to be one of the points of the big tent change
20:30:49 <sdague> dhellmann: ++
20:30:56 <wshao> It is good to have an alternative install approach (e.g, image-based vs script-based deployment). TripleO is the former, Compass is the latter.
20:31:04 <ttx> mordred: for example, absence of reuse of any oslo lib falls into lack of cooperation / open development part
20:31:15 <jaypipes> lifeless: we *do* absolutely get to consider overlap of RESTful APIs.
20:31:26 <ttx> mordred: and will make up a poorer operational experience ?
20:31:32 <zaneb> trademark search: 1769 Records(s) found
20:31:32 <lifeless> jaypipes: why?
20:31:43 * jaypipes also mutters something about including static artifacts in a source repo like https://github.com/stackforge/compass-core/tree/master/mibs
20:32:02 <jaypipes> lifeless: because if you have two OpenStack Compute APIs, you're done for.
20:32:02 <ttx> jaypipes: and more commits than reviews: more commits than reviews: http://stackalytics.com/report/contribution/compass-core/90
20:32:14 <ttx> and a pretty weird tree of versions: http://git.openstack.org/cgit/stackforge/compass-web/tree/
20:32:19 <wshao> ttx: we allow installers to use  openstack community chef cookbooks, and there is plan to use Ironic for OS provisioning phase of deployment
20:32:44 <lifeless> jaypipes: I understood allowing competition to be one of the main enablers of the big tent
20:32:45 <ttx> wshao: do you have plans to use cookbooks from the chef-openstack project ? Or keep your forked ones ?
20:32:52 <russellb> jaypipes: yeah, the "lower" in the stack, the more sensitive i am to that kind of overlap
20:32:54 <lifeless> jaypipes: so that the TC no longer has to pick the Right One.
20:33:06 <ttx> lifeless: forking the cookbooks falls into my "useless diplication" doctrine
20:33:06 <mestery> russellb: ++
20:33:09 <lifeless> jaypipes: I'm not saying we can't decide to care
20:33:15 <ttx> duplication*
20:33:16 <flaper87> (back)
20:33:20 <wshao> note on the commit/review stattisic:  we were developing on dev/experimental branch and moved to master recently.
20:33:21 <jaypipes> lifeless: APIs were *never* intended to have duplication.
20:33:33 <ttx> wshao: oh, that explains it. Thanks
20:33:36 <russellb> we should definitely care.
20:33:52 <jaypipes> lifeless: in fact I remember specifically saying that API duplication was a major concern, much more than competing implementations of an API.
20:33:57 <flaper87> I'm really worried about the community aspect here. We may want to wait until the project is more integrated w/ openstack
20:34:19 <flaper87> jaypipes: ++
20:34:24 <ttx> wshao: do you have any plans for more cooperation with openstack projects (think horizon, oslo, chef-cookbooks, etc.) once you are in ?
20:34:27 <wshao> ttx: we plan to use community ones.
20:34:29 <dhellmann> jaypipes: is there specific API duplication you're worried about here?
20:34:33 <lifeless> jaypipes: ah ok
20:34:46 <lifeless> jaypipes: I was talking competing implementations of same API
20:34:48 <ttx> wshao: if yes, I don't see anything blocking, it may just be too soon
20:34:52 <lifeless> jaypipes: not variants of the API
20:34:54 * dhellmann wonders who the "root" reviewer is on http://stackalytics.com/report/contribution/compass-core/90
20:34:56 <Rockyg> We're hoping that moving it to OpenStack gets more people interested.  But that also means we *have* to use dev to get people to know it's out there.
20:35:00 <wshao> the forked ones will be phased out. recently, we added support for Ansible based install
20:35:02 <lifeless> jaypipes: [though its hard to decouple those]
20:35:12 <jaypipes> dhellmann: ehm, yep. Things like GET /users is a pretty clear overlap ;)
20:35:19 <jaypipes> dhellmann: https://github.com/stackforge/compass-core/blob/master/compass/api/v1/api.py#L63
20:35:30 <dhellmann> jaypipes: is it the same name doing something different, or is it reproducing keystone?
20:35:32 <Daviey> The wikipage is unclear to me, is it currently Cobbler centric - or is there a strong desire to switch to Ironic as the bare metal provisioning tool?
20:35:38 <wshao> ttx: one we are in, we will work with chef-cookbooks, and Ironic for the near term
20:35:40 <jaypipes> dhellmann: doing something different.
20:35:42 <flaper87> Rockyg: to me, that needs to happen asap (integration with the rest of the community)
20:35:43 <lifeless> dhellmann: for installers there's a bootstrap problem
20:35:47 <dhellmann> jaypipes: ok, so what's the problem?
20:35:55 <lifeless> dhellmann: if you depend on keystone, you have to install it first, but how do you do that?
20:36:07 <dhellmann> lifeless: yes, I've installed software before, thanks
20:36:16 <Rockyg> flaper87: agreed.  It's a matter of beatin^^^^^training them to sue the mailing list
20:36:16 <lifeless> dhellmann: so I think you'll find that the world splits into two categories - those that do what tripleo did
20:36:24 <lifeless> dhellmann: and everyone else.
20:36:39 <jaypipes> dhellmann: so you're saying you want Keystone's GET /users API to return one thing and Compass' GET /users API to return a completely different set of data?
20:36:41 <wshao> jaypipes: our current auth model is primitive, keystone integration not done yet, due to resource constraints
20:36:42 <ttx> My take on this is they should engage more with our community and behave more like an openstack project before they can apply. This may just be too soon.
20:36:44 <Rockyg> One of the reasons we did stackforge as soon as possible was to get the team using the OpenStack ci process
20:36:48 <sdague> Rockyg: so, I think that needs to happen before coming into openstack, not a promiss to do it once they do
20:36:58 <dhellmann> jaypipes: the urls will be different, no?
20:37:03 <flaper87> Rockyg: lol, you'd be surprised to know that's a problem even in "old" OpenStack projects
20:37:11 <ttx> for example, openstack projects do not have a directory per version. We use git tags.
20:37:11 <lifeless> dhellmann: and AIUI fuel and uhm thingy from dell have their own user dbs
20:37:22 <mordred> lifeless: and neither are in openstack
20:37:23 <lifeless> dhellmann: so - snark aside - my point is that this is not unusual for an installer
20:37:28 <wshao> hi everyone, I want to point out that we have worked with Plumgrid, Intel , Orange, etc. they will be more interested in this project if it is moved to Big Tent.
20:37:54 <jaypipes> dhellmann: but it's the same *intent* of the API call... GET /users in both systems is intended to return the system's user information. That is the overlap I am referring to.
20:37:59 <dhellmann> lifeless: I wouldn't expect it to be. That's my point with jaypipes. I'm confused as to why he thinks keystone is the only project with rights to the path /users
20:38:08 <Rockyg> uh, last I heard, they weren't really interested in being "in" openstack?  Just associated?
20:38:13 <lifeless> dhellmann: gotchya
20:38:14 <jaypipes> dhellmann: other overlaps at the API functionality level include overlap with Tuskar's modeling of cluster resources.
20:38:15 <dhellmann> but they are different systems, with different user databases, right?
20:38:22 <sdague> and the fact that there is only a single person +2ing +Aing patches - http://stackalytics.com/?project_type=all&module=compass-core seems worrisome from the open perspective as well
20:38:42 <dhellmann> jaypipes: that sounds like competition to me, isn't that what we wanted?
20:38:47 <dhellmann> sdague: yes, that's a big concern
20:39:04 <flaper87> wshao: Rockyg FWIW, people interested in being part of OpenStack should work towards that and not sit there waiting for things to happen.
20:39:10 <jaypipes> dhellmann: if Compass used GET /accounts to refer to the *exact same functionality* that Keystone's GET /users API call, it would still be overlapping API functionality, and not something we want to encourage.
20:39:16 <mordred> Rockyg, sdague: yes. my concern is the open process parts
20:39:30 <flaper87> wshao: Rockyg not talking about you two, obviously
20:39:37 <flaper87> mordred: same here
20:39:40 <dhellmann> jaypipes: ok, I think I'm missing something, so maybe we should talk about this outside of the meeting
20:39:41 <mordred> Rockyg, wshao: there are a few key things that need to change before I think we can safely say "yes, you are clearly part of the family"
20:39:47 <flaper87> but I've yet to dive more into the projects
20:39:49 <Rockyg> Agreed on open process is extremely important.
20:39:49 <jaypipes> dhellmann: sure, sounds good.
20:39:56 <mordred> they're not terribly hard to change, and I'd personally be thrilled to see you back here when they're taken care of
20:40:03 <mordred> I can't speak for the rest of the tc of course
20:40:05 <ttx> OK, looks like this one needs to be further discussed on the review. Personally I think it's a bit early to be accepted, needs to behave like an openstack project for a bit
20:40:12 <mordred> ttx: ++
20:40:13 <sdague> ttx: ++
20:40:24 <ttx> I see lots of positive steps
20:40:28 <flaper87> Rockyg: wshao mordred FWIW, I'm more than happy to help with guidance (if needed) on how to get there
20:40:29 <ttx> like an IRC meeting being set up
20:40:40 <jaypipes> dhellmann: FTR, this same point is being brought up in Fuel's application to the openstack/ code namespace, and I specifically asked Dmitry to mention it in the commit message: https://review.openstack.org/#/c/199232/
20:40:41 <ttx> and I think it's good to enagge with us early
20:40:49 <Rockyg> Can we WIP and give the current team a couple of months to "practice" the open stuff that's not happening?  Let's get them working on Dev and meetings happening in IRC
20:40:53 <wshao> flaper87: mordred: ok, will talk to you on the details
20:40:59 <ttx> I expect us to come up with recommendations as you further engage with us
20:41:19 <dhellmann> jaypipes: ok, I'll review that, too
20:41:24 <jaypipes> cheers
20:41:24 <ttx> for example drop those version directories from http://git.openstack.org/cgit/stackforge/compass-web/tree/ that make my release eyes bleed
20:41:35 <sdague> Rockyg: that sounds like a good plan
20:41:37 <flaper87> wshao: Rockyg and remember, one of the best ways to get answers is the m-l
20:41:38 <mordred> Rockyg: totally! sounds great
20:41:44 <flaper87> ;)
20:41:57 <lifeless> I haven't checked the dependencies yet either
20:42:00 <wshao> ok cool.
20:42:04 <ttx> #agreed Let's WIP this one and engage with Compass folks to help them behave more like an openstack project and reduce duplication where possible
20:42:09 <Rockyg> Fantastic!  I think this will provide more incentive to make it happen.
20:42:14 <lifeless> I'm happy to provide guidance too
20:42:30 <ttx> OK next topic (we'll skip next topic since proposer agreed to rework her proposal)
20:42:41 <Rockyg> Thanks lifeless and flaper87!
20:42:44 <ttx> #topic Apply tc-approved-release tag
20:42:46 <wshao> Thanks everyone!
20:42:51 <ttx> #link https://review.openstack.org/198295
20:43:00 <ttx> I realized that we actually never applied the tc-approved-release tag after we defined it.
20:43:06 <Rockyg> one more question....IRC for group....should it be 3openstack-compass?
20:43:15 <ttx> We just said that it would initially apply to projects that had the "integrated-release" tag
20:43:28 <lifeless> Rockyg: we see both, but #openstack-compass would be the most common pattern
20:43:31 <ttx> So I proposed such a change, the amended it following mark's remark
20:43:32 <flaper87> Rockyg: anytime
20:43:38 <ttx> then*
20:43:40 <Rockyg> Cool Thanks!
20:43:49 <ttx> please reapply votes
20:44:03 <ttx> happy to answer questions if any
20:44:10 <flaper87> I've a side question on this topic. I read the tag page again and I was a bit confused on how we get other projects tagged as `tc-approved-release`. Does the request need to come from DefCore?
20:44:21 <lifeless> flaper87: from the board yes
20:44:24 <dhellmann> flaper87: yes
20:44:36 <lifeless> its all a bit terrible :)
20:44:37 <dhellmann> lifeless: I think we worded it specifically the defcore committee, not just the board
20:44:44 <russellb> we could do it ourselves if we wanted to
20:44:46 <flaper87> Can it come from other members of the tc ?
20:44:46 <flaper87> Asking because I think there are other projects that could also be tagged :)
20:44:47 <ttx> flaper87: we kept that intentionally vague. The tag is defined by the TC. We hinted that defcore would definitely be a good source
20:44:47 <russellb> we just said that's when we'll care
20:44:57 <lifeless> dhellmann: yes, but thats a subcommittee so effectively identical
20:44:59 <russellb> it doesn't really matter much unless they care to make use of capabilities in a given project
20:45:14 <mordred> yah
20:45:16 <ttx> it's really just a process tag to solve a bylwas conundrum
20:45:19 <flaper87> dhellmann: it's worded "DefCore", yes
20:45:23 <maishsk> just as a side note was LBaaS also not deemed as not ready for production - or has that changed?
20:45:24 <flaper87> lifeless: ^
20:45:24 <russellb> otherwise tagging a project doesn't do anything useful
20:45:28 <flaper87> yup
20:45:36 <sdague> flaper87: it was basically just lazy evaluation on the tag
20:45:36 <flaper87> ok
20:45:38 <ttx> markmcclain: what about lbaas ?
20:45:39 <mordred> flaper87: basically, the intent was "at some point, someone in the user community, ops or end users, is going to step up and request something be in"
20:45:42 <dhellmann> lifeless: sort of, but yeah, since defcore wouldn't use the thing just because we said so, going through them means there's actual interest
20:45:42 <jeblair> lifeless, Rockyg: (yes, #openstack-* is the preferred form for freenode technical/policy reasons)
20:45:57 <markmcclain> seems like the ttx: lbaas v2 is ready
20:46:05 <sdague> there is so much in there that's not getting any defcore specification yet anyway, they have a ton of headroom before other things need to be added
20:46:09 <markmcclain> s/seems that the//
20:46:19 <sdague> and let it be demand driven for the trademark
20:46:20 <ttx> ok, got 9 yes, will approve now
20:46:23 <mordred> sdague: ++
20:46:43 <flaper87> mordred: but in order for that to be in, I guess we also need to check on DefCore b/w, right?
20:46:53 <flaper87> sdague: exactly my understanding
20:46:54 <russellb> flaper87: for what to be in
20:46:55 <ttx> approved, thx
20:47:03 <ttx> #topic Remove the 'integrated-release' tag
20:47:14 <ttx> So, now that we actually applied the tc-approved-release tag we should be able to get rid of the legacy "integrated-release" tag
20:47:18 <ttx> I proposed that in:
20:47:20 <flaper87> russellb: sorry, for projects to be tagged as 'tc-approved-release'
20:47:21 <ttx> #link https://review.openstack.org/198302
20:47:22 <Rockyg> Uh, wasn't defcore's tag interop?
20:47:37 <ttx> If you think we can't do that yet, I'd like to get a feel of what is missing, so that I can work toward that before the end of the cycle
20:47:38 <mordred> flaper87: yah. I mean, right now the general vibe is not "zomg need more things"  ... it's "please stop adding more things" ... at some point that may chage
20:47:47 <sdague> Rockyg: this is the super set from which defcore can select
20:47:58 <ttx> Rockyg: as specified in the bylaws
20:48:06 <zaneb> I'd like to see more of the criteria that the TC evaluated when adding projects to the integrated release split out into their own tags
20:48:16 <russellb> bylaws use the name "TC approved release" - tag is named that way to clarify what it's implementing
20:48:20 <flaper87> mordred: roger, that was my feeling too.
20:48:36 <Rockyg> Ah.  I don't think Defcore is too concerned, then.  they only require the interop.  The integrated is kind of a warning flag of "maybe sometime soon"
20:48:39 <russellb> zaneb: same here, but i don't really see a need to keep the legacy tag anymore
20:48:51 <sdague> russellb: ++
20:48:56 <zaneb> yeah, I don't see a reason not to kill it
20:49:02 <ttx> zaneb: any suggestion ?
20:49:03 <russellb> it's basically a dead tag, but i'm totally with you
20:49:09 <zaneb> just seemed like an appropriate time to mention
20:49:16 <zaneb> that replacements would be nice :)
20:49:17 <russellb> takes more work than it seems at first to drive a tag to consensus though
20:49:31 <ttx> russellb: ok, I have an idea of a tag WG to aggressively research and propose that, next topic
20:49:32 <russellb> zaneb: feel free to pick something and push it :)
20:49:39 <flaper87> russellb: zaneb ++
20:49:41 <russellb> ttx: nice
20:49:44 <zaneb> ENOTIME :(
20:49:48 <Rockyg> From a defcore perspective, that's good.  It adds some aging to it ;-)
20:49:58 <sdague> yeh, honestly API contract guaruntee levels, Upgrade models would be good ones
20:50:02 <ttx> ok, one more vote and we can kill the beast
20:50:09 <mordred> KILL THE BEAST
20:50:19 <russellb> it was a friendly beast though
20:50:19 <sdague> I'm mostly tagged out for this cycle though
20:50:23 <russellb> retire it with kindness
20:50:29 <ttx> took us a year to kill it approximately
20:50:30 <russellb> sdague: heh
20:50:37 <ttx> that's a tough beast
20:50:50 <ttx> alright approving in 30 sec
20:50:58 <Rockyg> nobody want to see the process of making tags or sausages
20:51:12 <jeblair> i like that release's mission is now to serve "various components" and horizon's mission is now to serve "all openstack projects"
20:51:24 <david-lyle> jeblair: will rework soon
20:51:43 <ttx> #topic Workgroup reports
20:51:43 <jeblair> david-lyle: something about a framework, i imagine? :)
20:51:45 <david-lyle> exactly
20:52:00 <ttx> Thx everyone, those horizontal patches in projects.yaml are a bit of a pain to pass, so good to be quick :)
20:52:06 <ttx> * Project team guide
20:52:12 <jeblair> i still need to make publish jobs, sorry
20:52:12 <ttx> Doug and I pushed a number of edits, I will continue to do so this week. So please review:
20:52:16 <ttx> #link https://review.openstack.org/#/q/project:openstack/project-team-guide+is:open,n,z
20:52:25 <ttx> flaper87: do you plan to finish the open development chapter, or should someone take it over ?
20:52:39 <ttx> (I think once those are in we can start publishing it and iterate from that.)
20:53:37 <lifeless> markmcclain and I *still* haven't synced.
20:53:45 <lifeless> OTOH the constraints stuff is now into cleanup phase
20:53:46 <ttx> flaper87: ?
20:53:51 <flaper87> ttx: I plan to finish, sorry, this is my pre-holidays week
20:53:51 <flaper87> finish it*
20:54:03 <lifeless> so that huge time committment is shrinking rapidly
20:54:10 <flaper87> I'll try to complete my work there tomorrow (or the  day after)
20:54:10 <dhellmann> lifeless: \o/
20:54:19 <ttx> flaper87: col thx
20:54:23 <johnthetubaguy> so I should share that I have been trying to write up some why behind the process (right now its nova specific), but I should maybe try push that into a more cross project form: https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule
20:54:23 <ttx> * Communications
20:54:39 <flaper87> (having a huge lag right now)
20:54:56 <ttx> johnthetubaguy: I'll read that and see if anything is generally applicable
20:55:03 <flaper87> I think we have enough material for another post but I won't have much b/w this week. annegentle ?
20:55:36 <johnthetubaguy> ttx: cool, its a brain dump right now, I can help with splitting that in two at a later point
20:55:43 * dhellmann has to drop off early
20:56:05 <ttx> * Other workgroups
20:56:20 <ttx> So as I said earlier once I'm done with overhauling the release tags I might form a workgroup to proactively define other tags
20:56:32 <jeblair> johnthetubaguy: i like the nova-specific narrative referencing other sources of info; nice way to make it accessible without duplicating
20:56:37 <ttx> Like find nice questions we should provide answers for, or things we exprtessed in integrated-release that we don't communicate anymore
20:56:46 <ttx> if interested let me know
20:57:10 <johnthetubaguy> jeblair: thanks, yeah, trying to reference general topics where possible
20:57:47 <ttx> annegentle: anything on the comms side ? will you have bw for a post this week ?
20:57:53 <ttx> #topic Open discussion
20:58:02 <ttx> There was a recent thread on Kolla plans for using GPLv3'd Ansible modules
20:58:03 <mestery> johnthetubaguy: It's awesome work for sure, and defintely interested in seeing it more cross project. Thanks for that!
20:58:03 <annegentle> I can do a post this week, sure.
20:58:12 <ttx> #link http://lists.openstack.org/pipermail/openstack-dev/2015-July/068612.html
20:58:23 <markmcclain> ttx: we're running low on chairs for the cross-project meeting chairs
20:58:26 <markmcclain> #link https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Proposed_agenda
20:58:47 <markmcclain> oops.. https://wiki.openstack.org/wiki/Meetings/CrossProjectMeeting#Chair_rotation
20:58:56 <ttx> markmcclain: indeed. especially with me on holiday next week theoretically and traveling the week after
20:59:12 <ttx> I'm fine doing the TC meeting on holiday, but not the cross-project one
20:59:28 <ttx> so please add yourselves to the rotation there !
20:59:34 <ttx> PTLs welcome too.
20:59:34 <markmcclain> ttx: I guess we know where the line is drawn :)
21:00:14 <jeblair> ttx: just to be clear, are we welcome to chair the meeting or join you on holiday?
21:00:18 <ttx> If you have a strong opinion on the GPLv3 kolla issue, please chime on thread. Apparently mordred was involved in that discussion somewhere
21:00:26 <ttx> jeblair: both
21:00:30 <russellb> ttx: count me in for the tags group
21:00:33 <jeblair> aww, shucks
21:00:34 <flaper87> jeblair: the later
21:00:40 <ttx> In other news, the CFP for Tokyo Summit is closing next week. Remember there is full overlap with the Design Summit this time, so any talk you give is likely to generate painful conflicts for you
21:00:52 <ttx> Last words, anyone ?
21:00:57 <fungi> people give talks at that thing? ;)
21:01:01 <flaper87> tahnks ? :)
21:01:08 <flaper87> or thanks
21:01:25 <ttx> alright...
21:01:27 <ttx> #endmeeting