20:01:42 <ttx> #startmeeting tc
20:01:43 <openstack> Meeting started Tue Oct 23 20:01:42 2012 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:01:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:01:45 <openstack> The meeting name has been set to 'tc'
20:01:52 <ttx> The agenda for the meeting is at:
20:01:57 <ttx> #link http://wiki.openstack.org/Governance/TechnicalCommittee
20:02:06 <ttx> We have a bit of ground to cover today so let's start
20:02:14 <ttx> #topic Motion: Nomination of Ryan Lane to the User committee
20:02:27 <ttx> So this is just a formal confirmation that we nominated Ryan Lane to set up the user committee together with Tim Bell (nominated by the BoD)
20:02:35 <jaypipes> o/
20:02:35 * heckj seconds
20:02:40 <ttx> I went to all of you last week to get your agreement, so this should just be a matter of making it part of our first meeting minutes...
20:02:49 <ttx> Anyone with a last-minute objection ?
20:02:56 <jaypipes> nope
20:03:01 <russellb> sounds good to me.
20:03:04 <jgriffith> none here
20:03:09 <gabrielhurley> no objections
20:03:11 <annegentle-nz> sounds great
20:03:19 <ttx> #agreed Ryan Lane nominated to the original self-bootstrapping user committee
20:03:35 <ttx> Ryan_Lane: you just missed your coronation
20:03:38 <ttx> #topic Motion: Ceilometer application for incubation
20:03:39 <Ryan_Lane> :D
20:03:44 * nijaba waves
20:03:46 <ttx> #link http://lists.openstack.org/pipermail/openstack-tc/2012-October/000016.html
20:03:51 * dhellmann o/
20:03:58 <ttx> A few preliminary remarks on Incubation before we start the discussion...
20:04:08 <ttx> There is an upcoming discussion to have on the Incubation / Core promotion process, together with the Board of Directors
20:04:16 <ttx> They should file a request to see the topic discussed soon
20:04:33 <ttx> In particular, we'd like to avoid that projects follow the full incubation track only to be vetoed by the BoD at the very end of the process
20:04:44 <ttx> That said I see no reason to delay the decision on Ceilometer incubation
20:04:49 <russellb> they can veto it?
20:04:55 <ttx> Incubation is about pushing common resources to a project that we think is promising
20:05:11 <ttx> russellb: they can veto a project that we recommend for core yes. They can't veto Incubation per se
20:05:18 <russellb> ok.
20:05:25 <notmyname> ttx: it's more than a nursery, though
20:05:30 <ttx> So Incubation is about asking CI, QA and release management to work together with the incubated project
20:05:39 <ttx> so that it can be ready to become a core project for the next cycle
20:05:43 * bcwaldon and vishy join the party
20:05:46 <vishy> o/
20:05:50 <ttx> So it's necessary to become a core project, but it's not sufficient
20:05:50 * nijaba notes that they have been very helpful already
20:05:51 <mordred> we missed bcwaldon and vishy
20:06:12 <ttx> We'll have to clarify this with the BoD, but if the project is deemed out of the scope of OpenStack then it might just drop off Incubation status
20:06:21 <ttx> ...and if that happens I'd rather have it happen early rather than late
20:06:22 <mordred> or is it possible that a project stays in an incubated state indefinitely?
20:06:34 <notmyname> mordred: I hope not
20:06:39 <ttx> mordred: well then the drain on common resources is unwarranted
20:06:43 <ttx> With that in mind, let's open the discussion on this application
20:06:48 <gabrielhurley> My impression is that the incubation period is also somewhat about holding the project accountable to a higher standard, e.g. they're ready to play nice with the ecosystem... right?
20:06:51 <mordred> ok. just clarifying
20:06:56 <ttx> How about discussing Technical qualities and readiness first, then Project management, then Core scope
20:07:01 <ttx> gabrielhurley: yes
20:07:12 <ttx> it's about proving you can align, given the help
20:07:30 <ttx> On the technical qualities, the design and code looks generally good to me...
20:07:32 <jgriffith> From my perspective they have demonstrated that pretty well already
20:07:49 <ttx> Opinions on the technical side ?
20:08:08 <gabrielhurley> They're pushing in the right directions in terms of their integration with other core projects and helping standardize things, which is a big + for me.
20:08:16 <russellb> no objections here.
20:08:33 <vishy> I don't have any complaints about the technical choices or direction
20:08:41 <russellb> interfacing at the right level, working hard to help move openstack-common forward to help address their use cases, ... good stuff.
20:08:48 <vishy> for me it is whether or not metering fits in with core iaas components
20:08:49 <gabrielhurley> the only thing I'd like to see them focus on technically is fleshing out their API a bit more
20:09:06 <ttx> OK, let's switch to project management then, if it makes sense technically for everyone
20:09:22 <ttx> From a project organization perspective, I think Ceilometer was a good example of how it should be done "the openstack way". Starting from scratch...
20:09:26 <mordred> same as above, project management they've been responsive and interactive
20:09:35 <ttx> looking for integration points, using common, etc
20:09:39 <gabrielhurley> no objections on project management
20:09:43 <danwent> agreed
20:09:45 <russellb> yep, seem to have been working hard to do things the openstack way
20:09:54 <russellb> good openness, communication
20:10:03 <jaypipes> ++
20:10:06 <annegentle-nz> Technically they are sound for devs to contribute and in interacting with common, but I haven't seen much about interaction with operators or a roadmap for H? Is that forthcoming?
20:10:24 <gabrielhurley> I heard some informal roadmap talk from them at the summit
20:10:48 <gabrielhurley> I think if prompted it would be forthcoming in a more formal way
20:10:52 <ttx> nijaba: care to expand on that ?
20:10:59 <dhellmann> annegentle-nz: we had a lot of conversations with potential users during the summit, and are working on our roadmap
20:11:05 <nijaba> annegentle-nz: our roadmap was at http://wiki.openstack.org/EfficientMetering/RoadMap but we exepanded quite a bit our scope at the summit, so we'll have to update it soon
20:11:25 <nijaba> New objective since the Grizzly summit: The project aims to become the infrastructure for all measurements within OpenStack.
20:11:35 <annegentle-nz> nijaba: Awesome. The goals for the project are highly desired in operations as far as I can tell from doc search data.
20:11:40 <nijaba> and lots of good discussions have happened that way
20:11:53 <ttx> OK, any more comment on the project management/integration side before we discuss Core scope ?
20:12:07 <koolhead17> annegentle-nz, i see a good document in place already :)
20:12:24 <markmc> sorry I'm late
20:12:36 * markmc very happy with ceilometer technically and project management wise
20:12:37 <russellb> hey markmc
20:12:44 <ttx> OK then the less obvious part, core scope
20:12:58 <markmc> imho, you can't run a cloud without billing
20:13:00 <ttx> Personally, with the extended scope of the project (metering and monitoring), having a central place to collect metrics about your running cloud infra sounds like a good addition to any cloud
20:13:02 <markmc> seems pretty essential
20:13:06 <mordred> same here
20:13:11 <russellb> so, one way i think about this part is, how many people operating openstack need it?
20:13:13 <russellb> (most of them, IMO)
20:13:19 <ttx> It's definitely a supporting service...
20:13:29 <gabrielhurley> In my mind the objective of "measuring" is much more aligned with Core than "metering" and having been looking at what it currently takes to measure things in any one project let alone all of them I think it's very valuable. As Horizon PTL I can say that having another project in core that experiences the pain of consuming *all* the projects is a plus to me.
20:13:35 <ttx> Even if it doesn't fall in to the "necessary" category of supporting services (like Keystone), it seems to fall into the "best practice" category (like Horizon)
20:13:53 <ttx> And since it's more of a collection service than an action service, it doesn't stretch the definition of openstack core that much
20:13:59 <ttx> (for most definitions of it :)
20:14:12 <ttx> Other opinions on that ?
20:14:16 <russellb> well most people using openstack probably have to invent their own version of this right now
20:14:38 * russellb didn't read any objections ...
20:14:40 <bcwaldon> russellb: multi-tenant clouds, yes, what about private clouds?
20:14:43 <jd__> russellb: this is the case from what we heard and was one of our initial motivation, indeed
20:14:51 <ttx> Or let me know if you're all ready to vote
20:14:53 <russellb> i think private clouds too, for doing chargeback
20:15:00 <nijaba> bcwaldon: Ryan_Lanecould advocate the need for metering without billing
20:15:00 <mordred> I think the horizon example is a good one
20:15:01 <annegentle-nz> I think it's a good project to scope to enable adoption without having everyone re-invent the wheel
20:15:03 <markmc> bcwaldon, billing/metering is pretty essential for private clouds too
20:15:07 <russellb> holding groups accountable for the resources they consume
20:15:10 <ttx> or have more questions for the Ceilometer crowd first
20:15:20 <koolhead17> markmc, +1
20:15:25 <bcwaldon> ok, just wanted to hear the thinking
20:15:34 <mordred> in terms of it being 'best-practice' but not required
20:15:37 <russellb> cool
20:15:41 <vishy> one other thing we should consider
20:15:46 <gabrielhurley> yeah, "showback" even if not "chargeback" is definitely a want for private clouds
20:15:55 <russellb> good way to look at it
20:15:56 <annegentle-nz> Just heard that you're also working on Operators docs? It's seriously the most searched for topic so the demand for docs is high.
20:16:02 <vishy> we have to be careful with moving projects to core in the case that it will kill the ecosystem
20:16:05 <ttx> .. and good measurement is key to healtg monitoring as well
20:16:22 <jgriffith> vishy: can you explain a bit for me?
20:16:36 <vishy> so if there are competing projects for example we need to be careful about giving a stamp of approval to one
20:16:38 <ttx> vishy: that's a good argument, but I don't think that's the case here. It actually enables an ecosystem in my view
20:16:42 <markmc> people might be upset if ceilometer is blessed but their billing project isn't
20:16:44 <vishy> before it has been fought out in the market.
20:16:47 <jgriffith> vishy: ahhh
20:16:58 <markmc> how many other billing projects are are as mature and openstack-like?
20:17:00 <russellb> that's an interesting point.
20:17:01 <gabrielhurley> given the pain involved in extracting measurements right now, the only way an ecosystem could form to fill this gap is if all the projects uniformly adopt much better mechanisms for exposing data that needs measuring.
20:17:04 <mordred> that is an interesting point - although I am not currently aware of any competing projects
20:17:15 <ttx> markmc: ceilometer doesn't do billing though.
20:17:21 <dhellmann> markmc: we've been very careful to limit ourselves to *measuring* things without actually billing for them, because there are a lot of billing tools
20:17:21 <nijaba> but since we do not do billing, only measurment, that shold be help for them, not threat
20:17:21 <mordred> I think it's a good thing to keep in mind in general though
20:17:23 <vishy> considering there goal of being pluggable to billing systems I think we are ok in that department
20:17:24 <markmc> s/billing/metering/
20:17:29 <mordred> ++
20:17:29 <gabrielhurley> I'd see a "billing" project sitting on top of ceilometer
20:17:33 <russellb> so what else exists that is comparable then?
20:17:43 <vishy> but there is definitely some overlap with synapse and heat
20:17:49 <markmc> there was a nova-billing thing
20:17:54 <markmc> there are proprietary solutions
20:17:54 <koolhead17> gabrielhurley, +1
20:17:57 <markmc> no overlap with heat, for sure
20:18:03 <dhellmann> vishy: we're talking with the heat folks about sharing code, and are looking at synaps now, too
20:18:20 <ttx> well synaps overlaps with heat quite a bit, that's for sure
20:18:21 <notmyname> markmc: but proprietary systems are part of the ecosystem too
20:18:21 <russellb> is there code out for synaps yet?
20:18:22 <vishy> markmc: cloudwatch and ceilometer monitoring overlaps doesn't it?
20:18:23 <russellb> if not, it doesn't exist IMO.
20:18:27 <nijaba> markmc: indeed, heat even triggered a very heathly discusison and change of scope
20:18:32 <ttx> russellb: now yes
20:18:33 <vishy> russellb: yes the code is out
20:18:38 <russellb> ok cool.
20:18:46 <markmc> notmyname, as are proprietary object stores :)
20:18:50 <nijaba> jd__: did a good analysis of the synaps code
20:18:55 <jaypipes> vishy: not really... heat and cloudwatch overlap, IIRC
20:18:56 <mordred> notmyname: totally - but I think if it's something that needs interfaces with things - having an open source bit that fills the spot enables the proprietary systems
20:18:57 <ttx> anyway, that doesn't seem to be an objection, mpore of a concern to add to our checklist
20:19:02 <vishy> I actually don't see any reasonable conflicts, I just want to make sure that we consider all of these things
20:19:14 <vishy> it should be something that we consider whenever we are promoting
20:19:16 <jaypipes> understood
20:19:17 <ttx> Ready to vote ? More comments or questions ?
20:19:19 <mordred> vishy: ++
20:19:23 <russellb> definitely a good point for when heat comes up, more overlap there right now
20:19:25 <markmc> vishy, ok, yeah - cloudwatch is an extension of ceilometer's current scope
20:19:47 <markmc> vishy, I'm pretty happy that the heat and ceilometer guys have been working well together on monitoring
20:19:48 <jd__> FYI http://julien.danjou.info/blog/2012/openstack-synaps-exploration talks about the overlaps
20:19:55 <vishy> markmc: ++
20:19:56 <markmc> vishy, and monitoring makes more sense in ceilometer than heat
20:20:32 * russellb is ready to vote ...
20:20:43 <annegentle-nz> I think ceilometer's limited scope is their proof they'll make OpenStack stronger
20:20:56 <gabrielhurley> agreed
20:21:02 <ttx> annegentle: interesting way to look at it, but quite true
20:21:21 <ttx> Starting the vote in 30 seconds unless someone objects
20:21:29 <ttx> Note that according to our charter we need strictly more "yes" than "no" for approving
20:21:39 <ttx> and at least 5 "yes" (or "no") to come to a permanent approval/rejection
20:21:48 <danwent> do we have a final statement on scope?
20:21:51 <annegentle-nz> ttx do you have instructions for voting for newbies? :)
20:22:04 <gabrielhurley> ^^^that
20:22:04 <uvirtbot> gabrielhurley: Error: "^^that" is not a valid command.
20:22:18 <jaypipes> lol
20:22:18 <jgriffith> danwent: good question... ?
20:22:25 <markmc> danwent makes a good point
20:22:32 <danwent> just that it seems like many people running openstack might also use this?  I think we're setting a standard that will be used to judge other projects as well.
20:22:39 <markmc> how do we ensure projects don't grow unlimited in scope?
20:22:46 <danwent> so i'd like to be a bit more crisp if possible.
20:22:51 <ttx> danwent: it's in the incubation application. "The project aims to become the infrastructure for all measurements within OpenStack."
20:22:55 <markmc> do we say "come back to us if you want to grow your scope dramatically?"
20:23:09 <notmyname> so if "many people running openstack" use something, does it get to be in core? is that the guideline now?
20:23:10 <ttx> well, any change of scope should be submitted to the TC
20:23:24 <ttx> dropping large amounts of functionality is also not ok
20:23:28 <russellb> ttx: is that formalized anywhere?
20:23:42 <mordred> also, I thnk if someone else thinks that they (or anyone) are exceeding their mandate, that can also always be raised ...
20:23:42 <ttx> russellb: except in PPB pre-history ? Not really
20:23:44 <markmc> "measurements" seems like an overly broad scope, at first glance
20:24:00 <gabrielhurley> "dropping large amounts of functionality"... so Nova should be dropped from Core for excising the volumes code, right? ;-)
20:24:01 <danwent> sorry, I thought we were going to talk about the scope of what should or should not be a core project.  or ttx, did I misunderstand your earlier comment?
20:24:12 <markmc> e.g. precluding other services for monitoring or performance analysis
20:24:13 <bcwaldon> I'm actually curious about the stated vs implemented scope of the existing projects - does that exist somewhere?
20:24:19 <ttx> danwent: we've been doing that for the last 10 minutes ?
20:24:47 <ttx> starting at: <ttx> OK then the less obvious part, core scope
20:24:48 <danwent> yes, but I'd like to see an actual statement summarizing what we decided.
20:24:50 <nijaba> Previous mission statement: The project aims to deliver a unique point of contact for billing systems to aquire all meters they need to establish customer billing, across all current and future OpenStack core components.  <-- this is what we are more or less covering at the moment
20:24:52 <dhellmann> markmc: We don't do a lot of analysis of the things we're measuring now. We leave that up to the consumers.
20:25:11 <markmc> dhellmann, right, but even collecting performance measurements
20:25:25 <ttx> danwent: a definitive answer on what should or should not be a core project is out of scope (haha) for this meeting
20:25:29 <dhellmann> markmc: I see
20:25:32 <markmc> dhellmann, current statement of scope would make it sounds we won't allow other new projects to do such things, that ceilometer should do all that
20:25:35 <danwent> i.e., is our measuring stick "it seems like many openstack clouds would need this", how we measure if something should become a core project?
20:25:41 <ttx> danwent: we can work on that but I expect it will take a few meetings ;)
20:25:46 <markmc> dhellmann, why 'measurements' and not 'metering' as the project's scope?
20:26:17 <danwent> ttx: ok
20:26:19 <russellb> metering implies usage data, right?  measurements much more broad, includes anything and everything?
20:26:33 <nijaba> markmc: because of the extension we discussed with heat and other project to allow for a generic infrastructure for monitoring and alerting
20:26:52 <dhellmann> markmc: Based on our conversations at the summit with the Heat and StackTach folks, we thought it made sense to collaborate beyond metering for billing and cover measuring things for other purposes, too. We discovered areas we could reuse code, data, etc.
20:26:53 <danwent> i'm personally very happy with the ceilometer stuff, just concerned about approving it without a more clear statement that would give us guidence on any other project.
20:26:58 <notmyname> danwent: there is no formalized "scope of openstack" doc anywhere
20:27:09 <ttx> danwent: that's work in progress
20:27:22 <markmc> nijaba, that conversation to extend the scope seems to be in progress though, vs ceilometer being well proven for metering
20:27:23 <ttx> nijaba: so would you call your official name.. OpenStack Metering ? Measuring ?
20:27:26 <russellb> right now it's gut feeling?  heh.
20:27:34 <nijaba> markmc: true indeed
20:27:36 <mordred> although I agree with danwent that having such a scope doc would be nice
20:27:42 <ttx> russellb: it's always been that way so far :P
20:27:50 <gabrielhurley> +1 to eventually getting a clear definition of scope, but not today
20:27:54 <russellb> gotta start somewhere, it's all good.
20:27:58 * mordred also interested in ttx's 'official name' question
20:28:05 <nijaba> ttx: at the moment metering, if all goes well for grizzly, measurement
20:28:10 <notmyname> likewise, I think the project is solving a real need, but I don't know that it's good as a core project
20:28:23 <danwent> my gut feeling is that the ceilometer team is doing a good job, and that it will be useful to many deployments, so I guess i'll go with that for now :)
20:28:24 <ttx> or maybe "OpenStack Metrics"
20:28:35 * annegentle-nz likes metrics service
20:28:39 <nijaba> ttx: nice
20:28:44 * jaypipes notes that when he hears "metering", he thinks of rate limiting
20:28:45 <dhellmann> +1
20:28:52 <russellb> metrics implies analysis though
20:28:57 <russellb> measurements does not
20:28:58 <markmc> metrics precludes another service doing performance or monitoring metrics
20:29:07 <mordred> OpenStack numbers collection and stuff?
20:29:13 <nijaba> lol
20:29:13 <ttx> mordred++
20:29:13 <annegentle-nz> mordred: nice
20:29:15 <russellb> mordred: awesome.
20:29:18 <jaypipes> how about "metric collection and aggregation"
20:29:35 <ttx> yay bikeshedding
20:29:36 <markmc> why do we not like 'metering'?
20:29:44 <markmc> extend the scope later if it works out
20:29:53 <annegentle-nz> if the project is voted for core today, is it grizzly they'll first be in?
20:29:59 <ttx> MarkAtwood: no need to come up with final name before core inclusion request anyway
20:30:03 <annegentle-nz> if so we can just go to measurement
20:30:05 <russellb> annegentle: maybe or maybe not, that's another step
20:30:06 <ttx> annegentle: no
20:30:13 <ttx> won't be core until H anyway
20:30:15 <nijaba> our hope is that our future agent model shold precludes having to rewrite agents for collecting metrics in other projects
20:30:21 <annegentle-nz> ttx: ok
20:30:22 <russellb> ah right..
20:30:24 <ttx> has to go through the whole dev cycle
20:30:40 <ttx> ok, ready to vote for Incubation ? Not core.
20:30:52 * heckj ready
20:30:55 * jgriffith has been ready
20:30:59 <mordred> so ready
20:31:01 * annegentle-nz ready
20:31:03 <gabrielhurley> let's do this
20:31:06 <russellb> go go go
20:31:15 <ttx> Ok Dope, let's do this
20:31:17 <ttx> #startvote Approve Ceilometer application for incubation? yes, no, abstain
20:31:18 <gabrielhurley> ha
20:31:18 <openstack> Begin voting on: Approve Ceilometer application for incubation? Valid vote options are yes, no, abstain.
20:31:19 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:31:25 <markmc> #vote yes
20:31:26 <mordred> #vote yes
20:31:27 <gabrielhurley> #vote yes
20:31:30 <ttx> #vote yes
20:31:31 <heckj> #vote yes
20:31:32 <russellb> #vote yes
20:31:33 <danwent> #vote yes
20:31:36 <annegentle-nz> #vote yes
20:31:37 <jgriffith> #vote yes
20:31:47 <jaypipes> #vote abstain
20:31:53 <notmyname> #vote abstain
20:32:13 <ttx> vishy, bcwaldon...
20:32:14 <bcwaldon> #vote abstain
20:32:28 <vishy> #vote yes
20:32:47 * ttx wonders if he missed anyone
20:32:48 <notmyname> actually
20:32:50 <notmyname> #vote no
20:32:55 <ttx> closing in 30 seconds
20:33:34 <ttx> #endvote
20:33:35 <openstack> Voted on "Approve Ceilometer application for incubation?" Results are
20:33:36 <openstack> yes (10): markmc, ttx, vishy, annegentle-nz, heckj, russellb, jgriffith, mordred, gabrielhurley, danwent
20:33:37 <openstack> abstain (2): bcwaldon, jaypipes
20:33:38 <openstack> no (1): notmyname
20:33:59 <ttx> bcwaldon, jaypipes, notmyname: care to expand ? Could be useful for ceilometer folks to improve in the future ?
20:34:08 <ttx> not clear from previous discussion why
20:34:10 <dhellmann> or for future applicants
20:34:43 <ttx> though "lack of clear definition of core and good separation of power with BoD" certainly qualifies IMHO
20:35:04 <russellb> i'd like to see the scope solidified during incubation
20:35:05 <russellb> of Ceilometer that is
20:35:07 <danwent> I for one would like to see more clarity on what we think belongs in core.
20:35:08 <ttx> Both we should address in the next months
20:35:10 <notmyname> I don't think we should be adding new projects before we have a good definition of what openstack core is. we are in a huge danger of scope creep (not to mention the raised issues of ecosystem development). I think they are working on solving a very real need, but I can vote +1 on that alone
20:35:27 <ttx> notmyname: fair enough
20:35:40 <russellb> i guess i was banking on the fact that incubation doesn't mean they'll become core
20:35:49 <notmyname> russellb: it always has in the past
20:35:52 <russellb> and i sure hope we clarify that before anything else becomes core
20:35:52 * markmc thinks we need to discuss the meaning of incubation/core/core etc. outside of the context of any particular application
20:35:54 <ttx> russellb: same here, that's why I did that long intro
20:35:58 <danwent> I voted yes in that I didn't want to slow down the process of them eventually becoming core, assuming the definition of core puts ceilometer in scope
20:36:15 <annegentle-nz> danwent: good summary
20:36:18 <russellb> ttx: *nod*
20:36:18 <danwent> markmc: +1
20:36:23 <ttx> markmc +1
20:36:29 <ttx> OK, next topic
20:36:38 <ttx> #topic Discussion: Third-party APIs
20:36:40 <nijaba> thanks guys
20:36:40 <gabrielhurley> yep, incubation very well may *not* mean core if we clarify what "core" means before the incubation period is up.
20:36:45 <ttx> vishy: want to kick this one?
20:37:02 <dhellmann> thanks, everyone!
20:37:03 <vishy> sure
20:37:07 <vishy> so way back in the day
20:37:18 <vishy> we voted that 3rd party apis did not belong in the core projects
20:37:20 <russellb> dhellmann: nijaba etc, nice work, guys
20:37:30 <jd__> thanks
20:37:42 <vishy> but that the projects should attempt to enable 3rd party apis
20:38:15 <vishy> so we have made steps in nova towards the end of eventually being able to split out ec2
20:38:26 <vishy> awsome seems to be totally dead
20:38:32 <mordred> (and agpl)
20:38:50 <vishy> and now there is a new api ready to be proposed for nova (google compute engine)
20:39:04 <ttx> Please note that no formal decision can be made today on this, per our charter -- but the discussion will help vishy draft a proper motion
20:39:08 <russellb> at least one, if not one or two others ...
20:39:15 <ttx> Motion = push it to openstack-dev + openstack-tc for community discussion 4 business days before the next meeting
20:39:22 <vishy> during the summit we had a discussion about whether it was worth it to continue to block apis
20:39:34 <vishy> considering the greater cost of testing and integration if we split them out
20:39:49 <vishy> and the consensus in the meeting was that it would be much easier to just leave them in
20:39:58 <jaypipes> OCCI...
20:40:07 <vishy> so the question is, should we revisit the decision
20:40:09 <russellb> CIMI...
20:40:17 <bcwaldon> I'm more interested in doing it *right* rather than fast, especially when it means we're blessing more APIs
20:40:33 <bcwaldon> and throwing everything in the repo lets us get sloppy
20:40:38 <vishy> bcwaldon: but what is right? forcing them to talk through the public api?
20:40:50 <vishy> and adding a bunch of extensions for extra functionality?
20:40:55 <markmc> there were two benefits to keeping internal - performance and not needing to make a stable public performant API
20:41:00 * jaypipes really not a fan of adding these things to Nova... they below as extensions/middleware IMHO
20:41:10 <jaypipes> s/below/belong
20:41:13 <markmc> there's the ideal theory, and the reality of what work folks are actually showing up with
20:41:19 <bcwaldon> vishy: I'm not specifying implementation
20:41:19 <russellb> i'm assuming the burden to keep them up to date is on the submitter/maintainer of the API
20:41:29 <ttx> IIRC Swift used the current decision to separate some parts out -- would reversing the decision mean it could be put back in ?
20:41:41 <bcwaldon> vishy: just assuming we will have more solid internal APIs if we don't throw everything into the repo
20:41:45 <jgriffith> Personally I feel the Openstack API should be the first class citizen, others should be outside of core
20:41:48 <markmc> e.g. folks showing up with internally implemented gce code, no-one showing up with a public stable performant api for building other apis on
20:41:52 <vishy> i don't think we'd be asking for a revert, just the option of either way
20:42:16 <gabrielhurley> I like solid APIs, and I'm not a fan of them being in nova, but I'm also not a fan of letting each 3rd=party API project halfass their own implementations externally. neither option seems great.
20:42:20 <bcwaldon> I also don't want third-party APIs driving us to implement orthogonal things
20:42:27 <gabrielhurley> though I suppose bitrot in core is as likely as outside
20:42:30 <bcwaldon> like file injection or passwords
20:42:37 <jaypipes> ++
20:42:42 <russellb> and if it bitrots, we rip it out (like hyper-v)
20:43:02 <vishy> I think if we decide that outside is the right way to go, the only way we can prove that architecture works is putting ec2 outside and making it talk through the openstack api and ensuring it works
20:43:02 <notmyname> the cost to swift of implementing additional APIs comes mostly at the cost of additional developer and review time (and the mismatch of one api for a different implementation). I'm still opposed to adding things like CDMI and S3 into swift itself
20:43:20 <bcwaldon> +1 to both vishy and notmyname
20:43:28 <vishy> essentially I think we have 3 paths forward in nova
20:44:01 <vishy> 1) make a stable internal version ov compute.api and provide a way for 3rd parties to talk to it (via rpc?) and make ec2 use that
20:44:16 <markmc> notmyname, that assumes the developers of that api don't become part of the project's developer team
20:44:18 <vishy> 2) make 3rd parties speak through the rest api and port ec2 to use that
20:44:34 <vishy> 3) allow 3rd party apis into core
20:44:34 <russellb> markmc: i'm thinking that's a requirement to have a new API in
20:44:51 <vishy> all 3 of those are painful, so the question is which is the least painful.
20:44:54 <ttx> (3) is clearly the path of least resist=ance, but not a big fan of it
20:44:57 <mordred> I like 2 the best, but I'm not doing any of the work
20:44:58 <annegentle-nz> vishy: what does "port ec2 to use that" entail?
20:45:01 <notmyname> vishy: what's the difference in 1 and 2?
20:45:18 <vishy> 1 is a stable api that already exists
20:45:21 * markmc thinks (3) gives a nice new feature, new developers, no additional work with no volunteers, ...
20:45:32 <vishy> all of the existing api consumers use the internal implementation though
20:45:33 <lifeless> win 62
20:45:49 <vishy> so there is a lot more work to port things in 2
20:45:53 <markmc> compute.api is not a stable api
20:45:58 <bcwaldon> markmc: should it be?
20:45:59 <russellb> vishy: and i'm not really comfortable signing up for all of that to be considered a stable public API
20:46:17 <markmc> bcwaldon, yes, if we're telling external projects to build on it
20:46:29 <jog0> how do options 1,2 handle metadata services?
20:46:29 <gabrielhurley> I'm a fan of #1 because it doesn't proliferate HTTP calls all over the place.
20:46:57 <markmc> jog0, annoying little details aren't welcome here :)
20:46:57 <bcwaldon> making compute.api stable has several benefits
20:46:58 <russellb> but i don't know how practical it is
20:47:05 <notmyname> gabrielhurley: that's an implementation detail that may not apply to all projects
20:47:08 <vishy> jog0: that is a solvable problem i think but yes it is a little tricky
20:47:43 <vishy> notmyname: note that I'm not suggesting in any of the options that we require 3rd party apis be allowed in
20:48:13 <vishy> notmyname: 3rd party apis remaining outside makes perfect sense for swift
20:49:12 <notmyname> vishy: no, the arguments can be made both ways. seems that a good argument to include a 3rd party API is a good argument because it can be applied to all projects
20:49:31 <jgriffith> At some point I think the notion of a *stable* api is going to have to be addressed
20:49:42 <jgriffith> The only question for me given the options is if now is the right time
20:50:29 <ttx> jgriffith: if that's where we are heading anyway, implementing another option in the mean time sounds like wasted effort ?
20:50:42 * ttx doesn't like when there is no good solution
20:50:42 <vishy> so can we get a quick show of hands on whether a proposal to revert the ppb decision is worth it?
20:50:47 <annegentle-nz> vishy: can your proposal include a draft roadmap?
20:50:59 <annegentle-nz> vishy: I think a proposal will help
20:51:04 <vishy> annegentle-nz: for what as the goal?
20:51:12 <annegentle-nz> vishy: to help clarify timing
20:51:15 <vishy> I don't want to temporarily move these things into core
20:51:30 <annegentle-nz> vishy: right, but wondering if it's a G thing or an H thing, that sort of timing
20:51:36 <vishy> if they are coming in then I don't think there will be a good reason to remove them.
20:51:49 <markmc> vishy, perhaps the proposal should be to add 'nuance' to the previous decisions :)
20:51:53 <vishy> annegentle-nz: well number 3 which i'm proposing doesn't take any time at all
20:52:15 <vishy> I can't do number 3 without violating the ppb edict
20:52:15 <annegentle-nz> vishy: heh, true that
20:52:17 <markmc> vishy, e.g. the previous decision said that projects should aim to provide a public stable performant api for 3rd party apis to build on
20:52:18 <ttx> it just adds technical debt in a more obvious way than the others
20:52:39 <markmc> vishy, we're IMHO really saying that if no-one shows up to do that work, we shouldn't reject new 3rd party apis
20:52:58 <notmyname> the choice between 1 and 2 should be made internal to nova. the question of [(1 || 2) || 3] should be made by the TC, IMO
20:53:32 <ttx> Looks like this is not crystallizing into a clear choice yet
20:53:46 <mordred> notmyname: ++
20:53:49 <jaypipes> ttx: does it ever? :)
20:53:58 <vishy> notmyname: well the question of wether to allow 1&2 or 3 is tc
20:54:11 <vishy> so far it has decided only 1||2 not 3
20:54:21 <notmyname> vishy: right
20:55:15 <ttx> time is running out, I propose we continue that discussion in next meeting
20:55:16 <vishy> notmyname: ok I will put together a real proposal for this, although I'm still wondering if it is worth the time
20:55:26 <ttx> or decide on a motion if it's proposed by then
20:55:29 * russellb thinks it is
20:55:36 <vishy> k
20:55:45 <ttx> vishy: there definitely is a need, there just isn't lazy consensus around any particular solution
20:56:02 <markmc> IMHO discussion should be on openstack-dev
20:56:10 <ttx> Other topics are postponed to next meeting as well, which brings us to the next topic
20:56:12 <markmc> and folks with strong opinions should bring them up there
20:56:19 <russellb> markmc: +1
20:56:24 <ttx> markmc: yeah, hasting the discussion there should definitely give us more input
20:56:29 <gabrielhurley> +1
20:56:34 <markmc> rather than just vote against any motion rather than taking part in the discussion
20:57:04 <ttx> markmc: well motions need to be discussed on openstack-dev, but in this case, it sounds useful to gather input even before proposing motion
20:57:06 <ttx> #topic Date/time for next meeting
20:57:18 <ttx> So... I won't be around for next week meeting
20:57:19 <russellb> same time next week works for me.
20:57:19 <markmc> ttx, yep
20:57:22 <ttx> Leaving us with 3 options:
20:57:24 <russellb> burn.
20:57:27 <ttx> 1/ Skip it and have the next one on November 6
20:57:31 <ttx> 2/ Have it at the regular time, without me (volunteer chair ?)
20:57:35 <ttx> 3/ Have it next week, but on a different day (suggestion: Wed at 2100 UTC)
20:57:51 <ttx> (on another note, Europe abandons DST next Sunday, so we enter confusion zone)
20:57:56 <markmc> all 3 work for me
20:58:04 <mordred> 3 is halloween, just for people who  care
20:58:04 <russellb> same
20:58:06 <ttx> would prefer 1 or 3
20:58:08 <gabrielhurley> 1 or 2
20:58:17 <annegentle-nz> 2 or 3 for me
20:58:23 <gabrielhurley> :-(
20:58:33 <annegentle-nz> spooky TC meeting?
20:58:34 <heckj> 1 or 2 better for me
20:58:36 <mordred> ooo
20:58:37 <ttx> mordred: how fast do you need discussion on your topics ? Can wait Nov 6 ?
20:58:48 <mordred> I cannot be here nov 6 at 2100 UTC
20:58:56 <ttx> that simplifies
20:59:05 <vishy> 2
20:59:08 <ttx> so 2 or 3
20:59:13 <mordred> so if we don't do it next week, we'll do it nov 13
20:59:16 <ttx> I prefer 3
20:59:26 <mordred> I mean, we could wait until nov 13
20:59:39 <ttx> mordred: that would create a bit of backlog
20:59:42 <mordred> it just means we're going to be not changing anything about build slaves until then
20:59:52 <ttx> anyone that says 2 needs to volunteer for chairing :)
21:00:07 <mordred> I can chair, since I've got the contentious issue?
21:00:07 <ttx> [I'll still organize the agenda]
21:00:21 * jgriffith will vote for 2 now :)
21:00:23 <ttx> ok then - 2 with mordred chairing. Objections ?
21:00:30 <annegentle-nz> mordred: ttx: I can chair since mordred has to discuss? If needed.
21:00:41 <heckj> works for me
21:00:44 <mordred> cool by me
21:00:46 <gabrielhurley> +1
21:00:54 <jaypipes> +1
21:01:00 <russellb> +0
21:01:01 <ttx> mordred: that's 21:00 local time for you
21:01:12 <ttx> (where you'll be)
21:01:18 <ttx> #endmeeting