20:02:47 <ttx> #startmeeting tc
20:02:48 <openstack> Meeting started Tue Nov  6 20:02:47 2012 UTC.  The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:02:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:02:50 <openstack> The meeting name has been set to 'tc'
20:02:52 <bcwaldon> hello!
20:02:55 <ttx> The agenda for the meeting is at:
20:03:01 <ttx> #link http://wiki.openstack.org/Governance/TechnicalCommittee
20:03:11 <ttx> We'll probably have to defer some of those to next week any way
20:03:21 <heckj> o/
20:03:23 <ttx> #topic Motion: Heat application for incubation
20:03:30 <ttx> #link http://lists.openstack.org/pipermail/openstack-tc/2012-October/000039.html
20:03:45 <ttx> We need to decide if we grant Heat the additional resources and focus that come with the Incubated status
20:03:56 <ttx> Like for Ceilometer I'd like to organize the discussion of this in 3 parts
20:04:10 <ttx> Technical quality / code maturity, Project management / openness / collaboration, and core scope / OpenStack feature complementarity
20:04:22 <ttx> Let's talk Technical quality / code maturity first
20:04:33 <ttx> do we have the Heat people around ?
20:04:37 <shardy> yup
20:04:39 <stevebake> o?
20:04:40 <zaneb> yep
20:04:40 <ttx> yay
20:04:42 <stevebake> o/
20:04:51 <bcwaldon> ttx: I did want to ask if we should hit the last topic in your agenda before this
20:04:55 <gabrielhurley> not to digress but wouldn't this discussion be better *after* we resolve what incubation means (as per the Board's request)?
20:05:06 <ttx> ah.
20:05:12 <notmyname> ttx: doesn't this depend on a large part about the BoD request to refine the incubator process (and the points raised last week on a lack of definition for overall openstack core goals)?
20:05:32 <ttx> I fear we may not go to the bottom of their request soon enough though
20:05:44 <ttx> but ok, let's discuss that first
20:05:48 <notmyname> soon enough for what?
20:06:05 <gabrielhurley> I was wondering the same thing
20:06:09 <ttx> well, they want us to start discussing it in a joint committee starting November 26
20:06:37 <ttx> if you want to wait for the result of that, it delays the Heat incubation process accordingly
20:06:47 <annegentle___> the heat original request was in July http://www.mail-archive.com/openstack@lists.launchpad.net/msg14506.html
20:06:52 <markmc> and Heat gave us plenty of notice
20:06:54 <ttx> right
20:06:55 <markmc> right, July
20:07:11 <ttx> but I'm ok to discuss what we should do of the BoD request first, if tat makes more sense
20:07:24 * markmc can't find a link to the mail now
20:07:31 <ttx> #topic Preliminary discussion: Incubator process update
20:07:42 <ttx> That topic is a formal request from the BoD
20:07:47 <ttx> #link http://lists.openstack.org/pipermail/openstack-tc/2012-November/000072.html
20:07:57 <ttx> In summary they want to form a joint committee to discuss the future of the Incubation process
20:07:58 <markmc> thanks
20:08:04 <ttx> keyword is "future".
20:08:15 <ttx> Some of it is about setting better expectations, some of it is about creating new long-lasting classes of non-Core OpenStack projects
20:08:35 <ttx> A reduced number of TC members interested to discuss that would join that committee, with a deadline for selection on November 26
20:08:45 <ttx> Personally I see a number of issues with that
20:08:55 <ttx> First, unless we define a common position on that topic first, it will be hard for a subset of the TC to "represent" the TC's view
20:08:58 <markmc> it seems to be about making incubator more inclusive than just "makes sense for core" ?
20:09:24 <ttx> markmc: that seems t obe their intent yes
20:09:29 <ttx> Second, I think a lot of TC members feel strongly on the issue so we might end up dispatching a too-large group to that joint committee (they mentioned "select 2" to me)
20:09:45 <ttx> Third, I'm not sure a committee (text/voice) meeting is the right way to build consensus around this, I would prefer to flesh out the idea on mailing-lists first.
20:09:55 <ttx> Thoughts ?
20:09:59 <markmc> agree on mailing list discussion
20:10:03 <russellb> +1 to that
20:10:05 <vishy> o/ (btw)
20:10:14 <markmc> kind of thing I'd like to mull over as the discussion goes on
20:10:17 <ttx> (I also think that in the mean time we can make a provisional decision on Heat)
20:10:18 <notmyname> based on the bylaws, isn't it a TC decision? seems that what the BoD is asking for is some clarification and to be kept abreast of the discussions
20:10:55 <markmc> notmyname, certainly an important part of the discussion
20:11:05 <ttx> notmyname: the idea is to avoid the case of an incubation process where the BoD applies veto on the core project promotion at the very end
20:11:20 <ttx> which is I think bad for all
20:11:42 <ttx> but they also want the notion of "Incubation" to be revisited apparently
20:11:47 <markmc> veto against "core project promotion" as distinct from "promoted to being a part of openstack"
20:12:23 <ttx> the email hints at a new class of project that would not be core, too
20:12:32 <gabrielhurley> "being a part of openstack" is very amorphous in that context
20:12:42 <ttx> We could call the whole joint committee idea a bad idea, but that's how the BoD does things...
20:12:47 <notmyname> ttx: sure, that makes sense. and I agree that we need to actually define the stages. since they are approving what we decide, I'm glad they are giving some direction on what they want to see. but the decision is something we make, right? not something a subcommitee makes (for the reasons you gave)
20:12:50 <ttx> Alternatively we /could/ start the ML discussion (where ?) and try to converge to a common position and then select a reduced number of TC members to represent it on that joint committee.
20:12:51 <jaypipes> ttx: like what? we already have library, supporting, core and incubated, right?
20:13:40 <russellb> sounds like "core, but not as core as core"
20:13:50 <ttx> jaypipes: I suspec they want to use "core" to mean not just "important", but "necessary" for smoe definition of what an openstack cloud is
20:13:50 <jaypipes> wtfdtm? :)
20:13:54 <russellb> (i don't really get it)
20:13:59 <notmyname> russellb: all projects are equal but some are more equal than others? ;-)
20:14:09 <markmc> russellb, agree, but core has a specific definition in the bylaws
20:14:17 <ttx> in which case you would have the "openstack projects, a subset of which would be core
20:14:19 <markmc> russellb, a definition that folks seem to want to be precious about
20:14:21 <russellb> around trademark usage?
20:14:23 <jaypipes> I continue to define core in terms of "infrastructure vs. platform".
20:14:38 <bcwaldon> jaypipes: +1, it seems like thats what this discussion is really about, drawing the line there
20:14:46 <russellb> jaypipes: that's an interesting way to put it
20:15:02 <bcwaldon> openstack is essential infrastructure
20:15:03 <jaypipes> I also very much like the language notmyname used when differentiating between "product" and the underlying project when talking about Cloud Files vs. Swift, etc
20:15:17 <markmc> see http://wiki.openstack.org/Governance/Foundation/Bylaws#ARTICLE_IV._BOARD_OF_DIRECTORS
20:15:21 <markmc> 4.1 (b)
20:15:29 <markmc> so the bylaws are quite specific about all this stuff
20:15:42 <ttx> notmyname: the TC defines what it cares about... what "core" or "openstack" or "official" exactly means is the BoD decision
20:15:43 <markmc> what classes of project apart from core make up the OpenStack release etc.
20:16:13 <ttx> i.e. they get to choose the label, we get to choose the stuff we work on as a community
20:16:20 <jaypipes> markmc: right, but the bylaws also say that the TC decides what is core and what isn't..
20:16:26 <ttx> or a tleast that's my understqanding of it
20:16:52 <markmc> "The Technical Committee shall have the authority to determine the modules for addition, combination, split or deletion from the OpenStack Project except for modules of the Core OpenStack Project"
20:16:54 <markmc> ah, yes
20:16:54 <ttx> in all cases I don't think that affects our ability to decide if Heat is a good candidate and ready for Incubation
20:17:08 <markmc> ttx, agree
20:17:20 <ttx> it may affect which label may be attached to it in the end
20:17:23 <bcwaldon> ttx: don't we need to decide if Heat should be core? It doesnt make sense to incubate without that plan in mind, yes?
20:17:34 <bcwaldon> I was assuming incubated was solely a path to core
20:17:54 <ttx> bcwaldon: that's the core (eh) of the BoD request. Make incubation not be linked to the concept of core
20:17:58 <markmc> bcwaldon, how do non-core projects get added then?
20:18:08 <ttx> i.e. you need to be inclubated to be core
20:18:15 <ttx> but you could be incubated and become something else
20:18:23 <russellb> what is something else?
20:18:35 <bcwaldon> we don't need to go through an incubation process for non-core
20:18:41 <bcwaldon> we dont need to control it so closely
20:18:44 <markmc> russellb, at the moment "library projects, gating projects and supporting projects"
20:18:45 <russellb> other than library, supporting, and gating
20:18:46 <ttx> russellb: their emali wouldn't say. Up to tha tjoint committtee to define I guess
20:18:49 <annegentle___> currently incubation is required to become core (or get a split-off-core-one-time-fastpass)
20:18:53 <markmc> russellb, but I think the assumption is we add more classes
20:19:00 <russellb> ok.
20:19:15 <annegentle___> or discover/study whether incubation is valuable
20:19:21 <markmc> bcwaldon, we still need to evaluate them, similar criteria for incubation acceptance I thinik
20:19:23 <jaypipes> markmc: I'd prefer NOT to add more classes, frankly...
20:19:36 <bcwaldon> markmc: yes, I agree that, I just want to be clear about what class of project we're evaluating for
20:19:38 <ttx> If I had to guess I'd say they want a "core" and "main" class of openstack projects
20:19:41 <russellb> we either need another class, or need to make core not so precious
20:19:58 <markmc> russellb, that's my take
20:20:06 <russellb> ttx: that makes sense
20:20:15 <bcwaldon> core has to stay precious - it partially defines what an openstack cloud is
20:20:16 <jaypipes> markmc: because as soon as we do, we end up in the "so is this a 'recommended OpenStack project' ... " arena and the product guys start seeing monetization.
20:20:21 <ttx> both would receive attention, but they would place requirements like "an openstack cloud" is one that implements all core and any main
20:20:30 <annegentle___> core also requires the most resources
20:20:55 <markmc> bcwaldon, assuming core and trademark usage are linked
20:21:08 <markmc> annegentle___, why?
20:21:08 <ttx> So I'd like to propose we start the discussion on the ML (-dev ?)
20:21:11 <gabrielhurley> I'm definitely not a fan of "curated but not core"... I've seen that go wrong in lots of projects. they turn into ghettos and/or stifle community becuase people think something's blessed when it's not really. Better to just foster the ecosystem and let natural selection take its course.
20:21:12 <notmyname> markmc: which they are in the bylaws
20:21:14 <bcwaldon> markmc: I don't really want to care about trademark usage right now, this is a technical committee ;)
20:21:16 <jaypipes> markmc: they are linked... per 4.1 above.
20:21:25 <ttx> and keep on considering incubation old-style in the mean time
20:21:37 <annegentle___> markmc: does "requires the most non-dev resources" clarify? Core has certain expectations of release, test, doc, etc.
20:21:40 <markmc> notmyname, bcwaldon, yep
20:21:43 <jaypipes> "The other modules which are part of the OpenStack Project, but not the Core OpenStack Project may not be identified using the OpenStack trademark except when distributed with the Core OpenStack Project"
20:21:53 <ttx> with e caveat that the game rules may well change soon
20:22:03 <bcwaldon> jaypipes: we might want to disconnect that relationship
20:22:06 <notmyname> according to the bylaws, core == can use the trademark and is part of the combined release.
20:22:20 <jaypipes> notmyname: precisely.
20:22:28 <jaypipes> bcwaldon: we don't have the ability to do that... :(
20:22:31 <Daviey> .win 265
20:22:32 <bcwaldon> why do *we* need to care about trademark usage?
20:22:33 <notmyname> but that's not a very good guide to use to determine if something should be core
20:22:49 <markmc> bcwaldon, because we care about "core" and they're currently linked :)
20:23:06 <jaypipes> notmyname: agreed... just pointing out the boundaries of this discussion. :)
20:23:17 * ttx reposts his suggestion
20:23:21 <ttx> <ttx> So I'd like to propose we start the discussion on the ML (-dev ?)
20:23:25 <ttx> <ttx> and keep on considering incubation old-style in the mean time
20:23:26 <markmc> ttx, agree
20:23:29 <bcwaldon> ttx: yes
20:23:30 <jaypipes> lol, agreed.
20:23:31 <russellb> agree
20:23:34 <ttx> <ttx> with thee caveat that the game rules may well change soon
20:24:00 <jaypipes> ttx: all fine and good but I still think this needs to be resolved before any decision on Heat would be applied.
20:24:04 <markmc> so, part of this will be considering whether we think it's a candidate for core
20:24:15 <bcwaldon> let's Move On™
20:25:03 <russellb> but it could also be, is it worth additional resources right now understanding that could be core, or some other new class of project, pending the result of this (probably lengthy) discussion
20:25:03 <ttx> jaypipes: that's a valid remark... maybe we can cover it in the Heat discussion ?
20:25:35 <ttx> But if you see incubation as a resorce investment to support a promising project, more than a pre-stamp for core...
20:25:45 <ttx> I think we can decide now
20:25:57 <ttx> nothing prevents us from removing a project from incubation basically
20:26:07 <markmc> yeah
20:26:16 <ttx> #agreed Start discussion on BoD request on -dev ML
20:26:34 <ttx> Back to Heat
20:26:39 <ttx> #topic Motion: Heat application for incubation
20:26:52 <ttx> So.. Technical quality / code maturity first
20:26:53 <jaypipes> so what is the difference between a project we think has promise to become a non-core supporting OpenStack project and an incubated project that we think has promise to become a non-core supporting OpenStack project!? ...
20:27:26 <ttx> I need to read that a few times now
20:27:28 <notmyname> jaypipes: I think eventlet is a promising project that supports openstack ;-)
20:27:46 <russellb> ttx: i think the ? was, what does incubation mean.
20:27:52 <jaypipes> notmyname: I think swift is a promising project that supports glance. :)
20:28:00 <jaypipes> russellb: precisely.
20:28:07 <markmc> jaypipes, it means we hope it will be officially included as a supporting project in the H release
20:28:09 <ttx> Incubation is: do we care e nough about Heat to give it extra attention
20:28:17 <heckj> #link http://stackmeat.org <-- open community of openstack-related projects that *just* started this past week
20:28:20 <creiht> jaypipes: isn't glance infrastructure then? ;)
20:28:28 <notmyname> jaypipes: and linux is promising too!
20:28:28 <creiht> erm not infrastructure :)
20:28:43 <ttx> notmyname: yeah, I like linux too
20:28:43 <jaypipes> markmc: and what does the incubation actually entail then vs. just people thinking it's got promise? access to CI team and other stuff?
20:28:49 <russellb> btw, eventlet is *not* promising.
20:28:55 <jaypipes> hehe
20:28:59 <markmc> jaypipes, what does it mean for potential core projects?
20:28:59 <ttx> jaypipes: CI, release management
20:29:05 <jaypipes> creiht: :)
20:29:35 <jaypipes> ttx: ok, that's fine then. just wanted some clarification on what incubation means if it doesn't mean "will likely become core
20:29:39 <annegentle___> jaypipes: ttx: docs and test too?
20:29:41 <ttx> jaypipes: it's perfectly valid to abstain to the Heat thing saying it's not the right time
20:29:41 * markmc hopes the heat guys are "enjoying" this
20:29:57 <russellb> markmc: i was thinking that too :)
20:29:58 <ttx> markmc: yeah a bit of bad timing for them
20:30:01 <annegentle___> traditionally incubation doesn't give you extra docs resources
20:30:03 <stevebake> :)
20:30:06 <jaypipes> ttx: well, no, I'll be voting against Heat because I don't think it's infrastructure, not because it's not the right time ;)
20:30:13 <creiht> markmc: doesn't every incubation request always start with a spirited discussion about what core should be? :)
20:30:18 <ttx> jaypipes: twice as many reasons, awesome
20:30:20 <bcwaldon> jaypipes: same
20:30:23 * jaypipes would like to point out he really likes HEAT.
20:30:28 <markmc> creiht, you'd hope we'd be over that by now
20:30:33 <jaypipes> just not as core IaaS
20:30:40 <ttx> Arh, technical discussion on the merits of Heat firs tplace
20:30:47 <ttx> core scope will be discussed last
20:30:50 <jaypipes> ttx: k, sorry
20:30:53 <ttx> Had a question about the choice of CloudFormation template format (probably showing the extent of my ignorance of it)
20:31:00 <ttx> Does that restrict us in terms of resources that we can effect ? For example, would it support Quantum-like resources ? Or do you embrace/extend it ?
20:31:18 <danwent> ttx: stevebake says they already added native quantum type resources to heat
20:31:26 <jaypipes> right.
20:31:31 <danwent> so I think the answer is that they are not limited in this fashion
20:31:37 <ttx> jaypipes: should we read your "I really like HEAT" as no opposition on technical grounds ?
20:31:49 <stevebake> I've just implemented a full set of Quantum resources, announcement will be going out to os-dev list today
20:31:52 <jaypipes> ttx: that is correct. no opposition at all on technical grounds.
20:32:09 <zaneb> ttx: we can add whatever resources we like
20:32:14 <ttx> stevebake: so the template format is extensible, cool
20:32:19 <zaneb> just put them in a separate namespace
20:32:28 <zaneb> amazon ones start with AWS::
20:32:28 <shardy> ttx: intention is to move to openstack-native resource names, which will be a superset of AWS named resources
20:32:29 <ttx> then no issue on the technical side for me
20:32:32 <stevebake> CloudFormation format is just json. We're considering an additional native format like YAML as an alternative
20:32:46 <ttx> any other question on the technical side ?
20:33:14 <ttx> OK, let's talk Project management / openness / collaboration then
20:33:20 <ttx> A few random remarks on that...
20:33:33 <ttx> The gap to cover is slightly bigger than with Ceilometer, which was already using launchpad / openstack meetings / mailing-lists etc... which means this incubation is slightly more costly
20:33:49 <ttx> but nothing impossible
20:33:56 <zaneb> heat has moved to launchpad and the os mailing list already
20:34:10 <ttx> Oh, recently ?
20:34:13 <markmc> e.g. https://bugs.launchpad.net/heat
20:34:28 <ttx> saw github issues being referenced, was confused
20:34:31 <zaneb> launchpad move happened last week I think
20:34:32 <shardy> We've discussed moving meetings here too last week
20:34:42 <russellb> have been doing openstack-style meetings, at least, too.  i've seen meeting notes on the list in the past
20:34:43 <ttx> looks like you read my mind
20:34:47 <zaneb> we've been on openstack-dev for ages
20:34:51 <jaypipes> ++
20:34:52 <ttx> Also I'm a bit worried by the lack of external contributions. The team is AFAICT all-RedHat and almost all new contributors
20:35:01 <ttx> I hope that's more a visibility issue than an interest issue...
20:35:02 <shardy> ttx: github issue tracker now removed
20:35:34 <ttx> otherwise collaboration wit hother core projects seems to be going well... no other remark from me
20:35:42 <jaypipes> ttx: I'm less concerned about that after seeing the openness with which communication has occurred.
20:35:44 <zaneb> yes, meetings are all on IRC in #heat, but we could move easily here
20:36:14 <markmc> some openstack-common contribs have come from heat guys, which is cool
20:36:14 <ttx> anything else before we move to core scope ?
20:36:42 <ttx> OK, then lets' talk core scope / OpenStack feature complementarity
20:37:00 <ttx> wanted to make sure the ohter bases were covered before we go on the most problematic point
20:37:02 <jaypipes> ttx: I'm more concerned about disambiguating some of the apparent cross-project code between Ceilo, Synaps, and HEAT, and ensuring each of those projects has a clear path to sharing of common code.
20:37:24 <markmc> I think it's a really solid addition - ties together all of OpenStack APIs
20:37:31 <ttx> On that topic I would have preferred if we moved up the stack a bit more slowly...
20:37:37 <ttx> ...though I recognize that there is a need for a one-stop shop for orchestration of several openstack services
20:37:56 <russellb> i don't really think it moves up the stack that much..
20:38:02 <shardy> So to be clear, we've been working with ceilometer guys (asalkeld primarily) such that we can use their metric collection infrastructure
20:38:12 <markmc> even a simple "launch instance, assign floating IP" thing is possible through Heat
20:38:13 <shardy> we have no intention of long-term overlap
20:38:14 <jaypipes> shardy: ++
20:38:37 <jaypipes> shardy: good to hear. (more concerned re: Synaps, but that's a different discussion ;)
20:38:56 <shardy> jaypipes: IMO synaps is not really relevant to this discussion
20:39:10 <jaypipes> shardy: because of its implementation or something else?
20:39:26 <zaneb> synaps is a tricky one because it has not been developed in the open with involvement from the community
20:39:28 <stevebake> we'll use whatever monitoring solution emerges, we just need it to support autoscaling etc
20:39:29 <ttx> so fro mprevious mentions in the meeting some (bcwaldon, jaypipes) have reservations based on Heat not being IaaSy enough ?
20:39:30 <shardy> ie perhaps the CW api might end up in ceilometer or somewhere else, it's not a core part of our orchestration
20:39:51 <jaypipes> k, gotcha.
20:39:55 <ttx> would like them to voice them more clearly now, since I think tat's the heart of the decision we have to take
20:40:05 <jaypipes> shardy: HEAT is more the CF part, less the CW part...
20:40:08 <shardy> Yep, we just need a monitoring service, it can be whatever ends up working
20:40:12 <jaypipes> k
20:40:23 <shardy> jaypipes: exactly, we just need metrics for HA/autoscaling decisions
20:40:36 <shardy> I just bolted on a partial CW api for easier testing really
20:40:43 <danwent> I personally like the idea of an orchestration service like heat, otherwise people try to shove orchestration into indvidual services (where it makes less sense, in my opinion).
20:40:47 <shardy> and becuse I thought it might be useful
20:41:00 <jaypipes> right. well, you saying you're working with the other folks to align towards a common codebase for collection/monitoring is good enough for me.
20:41:09 <ttx> danwent: in tha tsense it could be seen as up the stack as Horizon
20:41:12 <markmc> jaypipes, they could have chosen not to implement auto-scaling because OpenStack doesn't have an API for it
20:41:19 <jaypipes> danwent: totally agreed.
20:41:26 <markmc> jaypipes, but they saw it as pretty essential
20:41:32 <jaypipes> sure, understood
20:42:07 <zaneb> jaypipes: http://julien.danjou.info/blog/2012/openstack-synaps-exploration see conclusion
20:42:18 <jaypipes> markmc: it's my duty to bring up these kinds of things, that's all :)
20:42:24 <shardy> markmc: there are several places where we've done our own impementations, but longer term would like to use external aaS implementations (e.g LBaaS)
20:42:28 <danwent> ttx: yes
20:42:37 <jaypipes> zaneb: ah, cheers, thx for that link. very helpful.
20:42:37 <markmc> jaypipes, sure, I wondered too - but it's all good
20:42:43 <ttx> jaypipes, bcwaldon: so is it seufficiently off your vision of what "openstack core" should be to be denied incubation ?
20:43:09 <jaypipes> ttx: I believe that totally is dependent on the outcome of our previously discussed topic for the ML about what is core, no?
20:43:13 <bcwaldon> ttx: I'm becoming increasingly concerned with what 'incubation' and 'core' mean
20:43:41 <bcwaldon> ttx: so I would say 'no' until I understand that better
20:43:45 <jaypipes> ttx: I've stated this opinion before.. I believe core == infrastructure. and infrastructure == <crap won't run without it>
20:43:53 <ttx> Personally I think we could grant it, with the clear caveat that the rules of the game are in the process of changing so this may be reverted soon in another meeting once those rules are defined
20:43:57 <jaypipes> ttx: this is why I voted no on Horizon being in core originally.
20:44:06 <ttx> jaypipes: agreed, that's consistent
20:44:18 <ttx> but would you support a motion to REMOVE horizon from core now ?
20:44:19 <jaypipes> ttx: it's a great project, it just didn't meet the "won't run without it" factor.
20:44:21 <gabrielhurley> I agree with the comparison to Horizon and the question to me is does it add enough value
20:44:32 <gabrielhurley> there's a clear uptick in adoption based on Horizon's inclusion
20:44:40 <jaypipes> ttx: no, I would NOT support that. just saying what the basis of my opinion is.
20:44:40 <ttx> gabrielhurley: do you see Horizon making use of Heat if it ever becomes a core project ?
20:44:46 <gabrielhurley> would the same be true of HEAT?maybe
20:45:01 <gabrielhurley> Horizon-Heat integration would absolutely happen
20:45:12 <jaypipes> gabrielhurley: good point re: the addition of value vs. infrastructure over platform.
20:45:14 <gabrielhurley> although amusingly you could also use Heat to deploy Horizon
20:45:15 <stevebake> FYI an external contributor is working on a Horizon Heat ui
20:45:24 <jaypipes> gabrielhurley: I guess it all boils down to what is core...
20:45:28 <gabrielhurley> yeah
20:45:31 <gabrielhurley> I'm still undecided, FWIW
20:45:33 <shardy> ttx: heat plugin for horizon in-progress
20:45:33 <markmc> stevebake, got the link?
20:45:41 <markmc> it's on github
20:45:43 * markmc can't find it
20:45:47 <gabrielhurley> I've seen it
20:45:51 <gabrielhurley> it's very nascent, but does exist
20:45:59 <shardy> https://github.com/heat-api/heat-horizon
20:46:12 <jaypipes> shardy: shouldn't that be "mirage"? :)
20:46:16 <gabrielhurley> heh
20:46:19 <gabrielhurley> +1
20:46:26 <notmyname> I agree with bcwaldon and jaypipes (except I would support removing current core non-IaaS projects)
20:46:28 <stevebake> I think this is an older screencast http://radez.fedorapeople.org/thermal1.ogv
20:46:28 <shardy> there is also a screencast demo from radez around somewhere, not got the link to hand
20:46:33 <ttx> Does anyone need extra information before deciding ? Note that the decision needs 5 "yes" or 5 "no"... so if enough people abstain the decision is pushed back (vote "abstain" if you want to delay decision)
20:46:58 <stevebake> https://github.com/heat-api/heat-horizon
20:47:03 <markmc> gabrielhurley, part of heat templates are almost a UI description - i.e. the list of parameters to prompt a user for, including defaults, lists to select from, etc.
20:47:09 <gabrielhurley> yep
20:47:18 <gabrielhurley> I'm familiar with cloudformation and how it's all supposed to work
20:47:21 <gabrielhurley> it's an interesting challenge
20:47:28 <gabrielhurley> what Amazon ended up with is awful
20:47:34 <gabrielhurley> we'd have to do better ;-)
20:47:38 <markmc> heh
20:47:53 <zaneb> gabrielhurley: we'd love to hear your input about that on the ML :)
20:47:57 <gabrielhurley> for sure
20:48:01 <stevebake> lots of potential for autogenerated ui
20:48:07 <gabrielhurley> definitely
20:48:27 * ttx repeats: <ttx> Does anyone need extra information before deciding
20:48:33 <bcwaldon> nope
20:48:36 <jaypipes> no
20:48:40 <markmc> not me
20:48:40 <danwent> no
20:48:41 <ttx> or can we move on to vote (abstain being an option)
20:49:38 <ttx> ok then, let's vote, for the decision to be final at least 5 yes or 5 no need to be obtained
20:49:47 <ttx> #startvote Approve Heat application for incubation? yes, no, abstain
20:49:48 <openstack> Begin voting on: Approve Heat application for incubation? Valid vote options are yes, no, abstain.
20:49:49 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
20:49:54 <jaypipes> #vote abstain
20:49:55 <markmc> #vote yes
20:49:56 <gabrielhurley> #vote abstain
20:49:57 <notmyname> #vote no
20:49:59 <russellb> #vote yes
20:50:08 <vishy> #vote abstain
20:50:08 <danwent> #vote yes
20:50:13 <bcwaldon> #vote abstain
20:50:13 <ttx> #vote yes
20:50:23 <annegentle___> #vote yes
20:50:30 <heckj> #vote abstain
20:50:31 <ttx> ouch, that's close
20:50:35 <gabrielhurley> wow
20:51:07 <ttx> 30 more seconds, unlikely to chnag ethe results anyway
20:51:11 <heckj> I think we're sending a poor message approving for incubation and what it implies
20:51:14 <jaypipes> notmyname: just curious, you voted no instead of abstain because you aren't concerned about the outcome of the discussion on "what is core" or you think you know what the decision will be?
20:51:16 <ttx> note that you can change your vote.
20:51:35 * annegentle___ is only voting for incubation, core is in the future
20:52:02 <ttx> heckj: if most abstain switch to "no" then they beat the "yes" (you need more "yes" than there is "no")
20:52:25 * ttx is only voting for incubtaion with the caveat that we may revisit the decision soon
20:52:30 <markmc> that's a long 30 seconds :)
20:52:33 <jaypipes> notmyname: or because you are saying that core is for infrastructure and incubation is for going into core and HEAT isn't infrastructure and so shouldn't be incubated? :)
20:52:34 <bcwaldon> I don't know how we can reasonably vote for this without understanding what this means
20:52:34 <russellb> annegentle___: that was my thought.  incubation now, the rest is obviously up in the air
20:52:50 <ttx> basically, start pushing the resources but be ready to pull them out
20:52:52 <notmyname> jaypipes: yes that (the "old" or "current" definition)
20:52:57 <jaypipes> :) k
20:53:09 <heckj> ttx: understood, but I'm abstaining because I think it's important to nail down what incubation means first.
20:53:11 <ttx> markmc: as long as people discuss...
20:53:23 <ttx> heckj: I respect that, almost abstained myself
20:53:27 * markmc basically thinks "if this isn't the kind of project we want to welcome into OpenStack, what is?"
20:53:31 <ttx> ok then 20 seconds
20:53:40 <gabrielhurley> On the plus side, giving them some resources for now will help them build a better project either way so we've done a good deed.
20:53:41 <markmc> talk about sending a bad message ...
20:53:50 <bcwaldon> markmc: we need to define what it means to 'welcome into openstack'
20:53:58 <ttx> #endvote
20:53:59 <openstack> Voted on "Approve Heat application for incubation?" Results are
20:53:59 <bcwaldon> markmc: I'm more than happy for the project to exist and be associated
20:53:59 <russellb> gabrielhurley: +1 to that
20:54:00 <markmc> rejecting would be an awful message of exclusivity IMHO
20:54:01 <openstack> yes (5): markmc, ttx, russellb, danwent, annegentle___
20:54:02 <openstack> abstain (5): heckj, gabrielhurley, jaypipes, bcwaldon, vishy
20:54:03 <openstack> no (1): notmyname
20:54:07 <jaypipes> markmc: only if you assume that not going into incubation is somehow bad (which it isn't)
20:54:09 <markmc> bcwaldon, yeah, we suck we don't know what that means yet
20:54:09 <heckj> bcwaldon: +1
20:54:21 <creiht> lol
20:54:26 <bcwaldon> markmc: we need to be exclusive - we can't just accept anybody
20:54:32 <markmc> bcwaldon, we're not
20:54:40 <bcwaldon> markmc: I wrote a project that spins up vms based on a script, should that be OpenStack™
20:54:48 <danwent> it seems like the logic being applied here is not consistent with the ceilometer vote last time
20:55:00 <markmc> bcwaldon, I thought we weren't talking about trademarks :)
20:55:03 <notmyname> danwent: FWIW, I voted the same way :-)
20:55:06 <danwent> I voted yes for the same reason I voted yes for ceilometer
20:55:12 <danwent> notmyname: fair :)
20:55:12 <bcwaldon> markmc: I've had to come down to your level ;)
20:55:16 <bcwaldon> damn trademarks
20:55:23 <jaypipes> danwent: would I be inconsistent
20:55:26 <jaypipes> dansmith: ?
20:55:27 <markmc> bcwaldon, trademarks are the last thing I want to talk about!
20:55:31 <jaypipes> gah. danwent ...
20:55:39 <bcwaldon> markmc: me too! blah
20:55:49 <russellb> i think voting yes to ceilometer and abstain to heat is inconsistent.
20:55:57 <danwent> jaypipes: :)  to me there was uncertaintly about the definition of "core" and "incubation" in both cases
20:55:59 <jaypipes> russellb: is that what I did?
20:56:14 <russellb> i don't know, just making a general statement, we had almost all yes to ceilometer
20:56:21 <jaypipes> russellb: if so, yes, I was inconsistent and should not have been.
20:56:26 <gabrielhurley> I think they ceilometer/heat land at somewhat different levels in the stack... also ecosystem competition and level of integration are very different between the two.
20:56:31 <ttx> bcwaldon++
20:56:31 * ttx lags
20:56:31 <danwent> I don't remember individual votes, but the end result is certainly different.  I was just curious if people saw a major difference that I was missing
20:56:53 <ttx> err, just was off network for a bit
20:57:05 <ttx> did the bot record the results and my #endvote ?
20:57:10 <jaypipes> yes
20:57:22 <ttx> ok, I guess I'll read the log
20:57:32 <ttx> #topic Preliminary discussion: Third-party APIs
20:57:32 <notmyname> ttx: 5-5-1
20:57:45 <markmc> shardy, stevebake, zaneb, welcome :)
20:57:45 <heckj> ttx: with 3 minutes remaining?
20:57:46 <russellb> what does 5-5-1 mean, basically abstain?
20:57:52 <russellb> or what?
20:57:53 <ttx> The thread is in full swing on the mailing-list... Would be good if it could distill down into a clear motion to be discussed and proposed at the next meeting
20:57:57 <ttx> russellb: it means yes
20:57:58 <Daviey> a user sevice orchestration tool and a metering/billing centralised project is very differnet.. I can see how one is infra, and the other is an end user tool
20:58:03 <russellb> ttx: ok, thanks.
20:58:06 <ttx> russellb: more yes than no, and at least 5 yes or no
20:58:11 <markmc> heckj, this is an easy conversation :)
20:58:24 <markmc> ttx, I can summarise the motion
20:58:44 <ttx> NB: Motions to be voted on need to be posted for public discussion before the end of day on Wednesday the week before
20:58:59 <markmc> vishy, you agree that it's just a "we agree with the apis-should-be-external-aspiration, but we're not ready for that in Nova yet" motion?
20:59:02 <ttx> #action markmc to summarize and propose a clear motion by EOD tomorrow
20:59:12 <ttx> for next meeting
20:59:35 <ttx> #action ttx to start discussion on the incubation/core process on -dev ML
20:59:39 <vishy> markmc: yes
20:59:44 <markmc> vishy, thanks
21:00:02 <ttx> ok, no time for more today, see you all next week ?
21:00:19 <bcwaldon> yep, thanks ttx
21:00:28 <annegentle___> thanks ttx
21:00:34 <ttx> #endmeeting