20:02:47 #startmeeting tc 20:02:48 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:50 The meeting name has been set to 'tc' 20:02:52 hello! 20:02:55 The agenda for the meeting is at: 20:03:01 #link http://wiki.openstack.org/Governance/TechnicalCommittee 20:03:11 We'll probably have to defer some of those to next week any way 20:03:21 o/ 20:03:23 #topic Motion: Heat application for incubation 20:03:30 #link http://lists.openstack.org/pipermail/openstack-tc/2012-October/000039.html 20:03:45 We need to decide if we grant Heat the additional resources and focus that come with the Incubated status 20:03:56 Like for Ceilometer I'd like to organize the discussion of this in 3 parts 20:04:10 Technical quality / code maturity, Project management / openness / collaboration, and core scope / OpenStack feature complementarity 20:04:22 Let's talk Technical quality / code maturity first 20:04:33 do we have the Heat people around ? 20:04:37 yup 20:04:39 o? 20:04:40 yep 20:04:40 yay 20:04:42 o/ 20:04:51 ttx: I did want to ask if we should hit the last topic in your agenda before this 20:04:55 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 ah. 20:05:12 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 I fear we may not go to the bottom of their request soon enough though 20:05:44 but ok, let's discuss that first 20:05:48 soon enough for what? 20:06:05 I was wondering the same thing 20:06:09 well, they want us to start discussing it in a joint committee starting November 26 20:06:37 if you want to wait for the result of that, it delays the Heat incubation process accordingly 20:06:47 the heat original request was in July http://www.mail-archive.com/openstack@lists.launchpad.net/msg14506.html 20:06:52 and Heat gave us plenty of notice 20:06:54 right 20:06:55 right, July 20:07:11 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 #topic Preliminary discussion: Incubator process update 20:07:42 That topic is a formal request from the BoD 20:07:47 #link http://lists.openstack.org/pipermail/openstack-tc/2012-November/000072.html 20:07:57 In summary they want to form a joint committee to discuss the future of the Incubation process 20:07:58 thanks 20:08:04 keyword is "future". 20:08:15 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 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 Personally I see a number of issues with that 20:08:55 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 it seems to be about making incubator more inclusive than just "makes sense for core" ? 20:09:24 markmc: that seems t obe their intent yes 20:09:29 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 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 Thoughts ? 20:09:59 agree on mailing list discussion 20:10:03 +1 to that 20:10:05 o/ (btw) 20:10:14 kind of thing I'd like to mull over as the discussion goes on 20:10:17 (I also think that in the mean time we can make a provisional decision on Heat) 20:10:18 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 notmyname, certainly an important part of the discussion 20:11:05 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 which is I think bad for all 20:11:42 but they also want the notion of "Incubation" to be revisited apparently 20:11:47 veto against "core project promotion" as distinct from "promoted to being a part of openstack" 20:12:23 the email hints at a new class of project that would not be core, too 20:12:32 "being a part of openstack" is very amorphous in that context 20:12:42 We could call the whole joint committee idea a bad idea, but that's how the BoD does things... 20:12:47 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 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 ttx: like what? we already have library, supporting, core and incubated, right? 20:13:40 sounds like "core, but not as core as core" 20:13:50 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 wtfdtm? :) 20:13:54 (i don't really get it) 20:13:59 russellb: all projects are equal but some are more equal than others? ;-) 20:14:09 russellb, agree, but core has a specific definition in the bylaws 20:14:17 in which case you would have the "openstack projects, a subset of which would be core 20:14:19 russellb, a definition that folks seem to want to be precious about 20:14:21 around trademark usage? 20:14:23 I continue to define core in terms of "infrastructure vs. platform". 20:14:38 jaypipes: +1, it seems like thats what this discussion is really about, drawing the line there 20:14:46 jaypipes: that's an interesting way to put it 20:15:02 openstack is essential infrastructure 20:15:03 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 see http://wiki.openstack.org/Governance/Foundation/Bylaws#ARTICLE_IV._BOARD_OF_DIRECTORS 20:15:21 4.1 (b) 20:15:29 so the bylaws are quite specific about all this stuff 20:15:42 notmyname: the TC defines what it cares about... what "core" or "openstack" or "official" exactly means is the BoD decision 20:15:43 what classes of project apart from core make up the OpenStack release etc. 20:16:13 i.e. they get to choose the label, we get to choose the stuff we work on as a community 20:16:20 markmc: right, but the bylaws also say that the TC decides what is core and what isn't.. 20:16:26 or a tleast that's my understqanding of it 20:16:52 "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 ah, yes 20:16:54 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 ttx, agree 20:17:20 it may affect which label may be attached to it in the end 20:17:23 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 I was assuming incubated was solely a path to core 20:17:54 bcwaldon: that's the core (eh) of the BoD request. Make incubation not be linked to the concept of core 20:17:58 bcwaldon, how do non-core projects get added then? 20:18:08 i.e. you need to be inclubated to be core 20:18:15 but you could be incubated and become something else 20:18:23 what is something else? 20:18:35 we don't need to go through an incubation process for non-core 20:18:41 we dont need to control it so closely 20:18:44 russellb, at the moment "library projects, gating projects and supporting projects" 20:18:45 other than library, supporting, and gating 20:18:46 russellb: their emali wouldn't say. Up to tha tjoint committtee to define I guess 20:18:49 currently incubation is required to become core (or get a split-off-core-one-time-fastpass) 20:18:53 russellb, but I think the assumption is we add more classes 20:19:00 ok. 20:19:15 or discover/study whether incubation is valuable 20:19:21 bcwaldon, we still need to evaluate them, similar criteria for incubation acceptance I thinik 20:19:23 markmc: I'd prefer NOT to add more classes, frankly... 20:19:36 markmc: yes, I agree that, I just want to be clear about what class of project we're evaluating for 20:19:38 If I had to guess I'd say they want a "core" and "main" class of openstack projects 20:19:41 we either need another class, or need to make core not so precious 20:19:58 russellb, that's my take 20:20:06 ttx: that makes sense 20:20:15 core has to stay precious - it partially defines what an openstack cloud is 20:20:16 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 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 core also requires the most resources 20:20:55 bcwaldon, assuming core and trademark usage are linked 20:21:08 annegentle___, why? 20:21:08 So I'd like to propose we start the discussion on the ML (-dev ?) 20:21:11 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 markmc: which they are in the bylaws 20:21:14 markmc: I don't really want to care about trademark usage right now, this is a technical committee ;) 20:21:16 markmc: they are linked... per 4.1 above. 20:21:25 and keep on considering incubation old-style in the mean time 20:21:37 markmc: does "requires the most non-dev resources" clarify? Core has certain expectations of release, test, doc, etc. 20:21:40 notmyname, bcwaldon, yep 20:21:43 "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 with e caveat that the game rules may well change soon 20:22:03 jaypipes: we might want to disconnect that relationship 20:22:06 according to the bylaws, core == can use the trademark and is part of the combined release. 20:22:20 notmyname: precisely. 20:22:28 bcwaldon: we don't have the ability to do that... :( 20:22:31 .win 265 20:22:32 why do *we* need to care about trademark usage? 20:22:33 but that's not a very good guide to use to determine if something should be core 20:22:49 bcwaldon, because we care about "core" and they're currently linked :) 20:23:06 notmyname: agreed... just pointing out the boundaries of this discussion. :) 20:23:17 * ttx reposts his suggestion 20:23:21 So I'd like to propose we start the discussion on the ML (-dev ?) 20:23:25 and keep on considering incubation old-style in the mean time 20:23:26 ttx, agree 20:23:29 ttx: yes 20:23:30 lol, agreed. 20:23:31 agree 20:23:34 with thee caveat that the game rules may well change soon 20:24:00 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 so, part of this will be considering whether we think it's a candidate for core 20:24:15 let's Move On™ 20:25:03 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 jaypipes: that's a valid remark... maybe we can cover it in the Heat discussion ? 20:25:35 But if you see incubation as a resorce investment to support a promising project, more than a pre-stamp for core... 20:25:45 I think we can decide now 20:25:57 nothing prevents us from removing a project from incubation basically 20:26:07 yeah 20:26:16 #agreed Start discussion on BoD request on -dev ML 20:26:34 Back to Heat 20:26:39 #topic Motion: Heat application for incubation 20:26:52 So.. Technical quality / code maturity first 20:26:53 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 I need to read that a few times now 20:27:28 jaypipes: I think eventlet is a promising project that supports openstack ;-) 20:27:46 ttx: i think the ? was, what does incubation mean. 20:27:52 notmyname: I think swift is a promising project that supports glance. :) 20:28:00 russellb: precisely. 20:28:07 jaypipes, it means we hope it will be officially included as a supporting project in the H release 20:28:09 Incubation is: do we care e nough about Heat to give it extra attention 20:28:17 #link http://stackmeat.org <-- open community of openstack-related projects that *just* started this past week 20:28:20 jaypipes: isn't glance infrastructure then? ;) 20:28:28 jaypipes: and linux is promising too! 20:28:28 erm not infrastructure :) 20:28:43 notmyname: yeah, I like linux too 20:28:43 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 btw, eventlet is *not* promising. 20:28:55 hehe 20:28:59 jaypipes, what does it mean for potential core projects? 20:28:59 jaypipes: CI, release management 20:29:05 creiht: :) 20:29:35 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 jaypipes: ttx: docs and test too? 20:29:41 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 markmc: i was thinking that too :) 20:29:58 markmc: yeah a bit of bad timing for them 20:30:01 traditionally incubation doesn't give you extra docs resources 20:30:03 :) 20:30:06 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 markmc: doesn't every incubation request always start with a spirited discussion about what core should be? :) 20:30:18 jaypipes: twice as many reasons, awesome 20:30:20 jaypipes: same 20:30:23 * jaypipes would like to point out he really likes HEAT. 20:30:28 creiht, you'd hope we'd be over that by now 20:30:33 just not as core IaaS 20:30:40 Arh, technical discussion on the merits of Heat firs tplace 20:30:47 core scope will be discussed last 20:30:50 ttx: k, sorry 20:30:53 Had a question about the choice of CloudFormation template format (probably showing the extent of my ignorance of it) 20:31:00 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 ttx: stevebake says they already added native quantum type resources to heat 20:31:26 right. 20:31:31 so I think the answer is that they are not limited in this fashion 20:31:37 jaypipes: should we read your "I really like HEAT" as no opposition on technical grounds ? 20:31:49 I've just implemented a full set of Quantum resources, announcement will be going out to os-dev list today 20:31:52 ttx: that is correct. no opposition at all on technical grounds. 20:32:09 ttx: we can add whatever resources we like 20:32:14 stevebake: so the template format is extensible, cool 20:32:19 just put them in a separate namespace 20:32:28 amazon ones start with AWS:: 20:32:28 ttx: intention is to move to openstack-native resource names, which will be a superset of AWS named resources 20:32:29 then no issue on the technical side for me 20:32:32 CloudFormation format is just json. We're considering an additional native format like YAML as an alternative 20:32:46 any other question on the technical side ? 20:33:14 OK, let's talk Project management / openness / collaboration then 20:33:20 A few random remarks on that... 20:33:33 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 but nothing impossible 20:33:56 heat has moved to launchpad and the os mailing list already 20:34:10 Oh, recently ? 20:34:13 e.g. https://bugs.launchpad.net/heat 20:34:28 saw github issues being referenced, was confused 20:34:31 launchpad move happened last week I think 20:34:32 We've discussed moving meetings here too last week 20:34:42 have been doing openstack-style meetings, at least, too. i've seen meeting notes on the list in the past 20:34:43 looks like you read my mind 20:34:47 we've been on openstack-dev for ages 20:34:51 ++ 20:34:52 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 I hope that's more a visibility issue than an interest issue... 20:35:02 ttx: github issue tracker now removed 20:35:34 otherwise collaboration wit hother core projects seems to be going well... no other remark from me 20:35:42 ttx: I'm less concerned about that after seeing the openness with which communication has occurred. 20:35:44 yes, meetings are all on IRC in #heat, but we could move easily here 20:36:14 some openstack-common contribs have come from heat guys, which is cool 20:36:14 anything else before we move to core scope ? 20:36:42 OK, then lets' talk core scope / OpenStack feature complementarity 20:37:00 wanted to make sure the ohter bases were covered before we go on the most problematic point 20:37:02 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 I think it's a really solid addition - ties together all of OpenStack APIs 20:37:31 On that topic I would have preferred if we moved up the stack a bit more slowly... 20:37:37 ...though I recognize that there is a need for a one-stop shop for orchestration of several openstack services 20:37:56 i don't really think it moves up the stack that much.. 20:38:02 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 even a simple "launch instance, assign floating IP" thing is possible through Heat 20:38:13 we have no intention of long-term overlap 20:38:14 shardy: ++ 20:38:37 shardy: good to hear. (more concerned re: Synaps, but that's a different discussion ;) 20:38:56 jaypipes: IMO synaps is not really relevant to this discussion 20:39:10 shardy: because of its implementation or something else? 20:39:26 synaps is a tricky one because it has not been developed in the open with involvement from the community 20:39:28 we'll use whatever monitoring solution emerges, we just need it to support autoscaling etc 20:39:29 so fro mprevious mentions in the meeting some (bcwaldon, jaypipes) have reservations based on Heat not being IaaSy enough ? 20:39:30 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 k, gotcha. 20:39:55 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 shardy: HEAT is more the CF part, less the CW part... 20:40:08 Yep, we just need a monitoring service, it can be whatever ends up working 20:40:12 k 20:40:23 jaypipes: exactly, we just need metrics for HA/autoscaling decisions 20:40:36 I just bolted on a partial CW api for easier testing really 20:40:43 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 and becuse I thought it might be useful 20:41:00 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 danwent: in tha tsense it could be seen as up the stack as Horizon 20:41:12 jaypipes, they could have chosen not to implement auto-scaling because OpenStack doesn't have an API for it 20:41:19 danwent: totally agreed. 20:41:26 jaypipes, but they saw it as pretty essential 20:41:32 sure, understood 20:42:07 jaypipes: http://julien.danjou.info/blog/2012/openstack-synaps-exploration see conclusion 20:42:18 markmc: it's my duty to bring up these kinds of things, that's all :) 20:42:24 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 ttx: yes 20:42:37 zaneb: ah, cheers, thx for that link. very helpful. 20:42:37 jaypipes, sure, I wondered too - but it's all good 20:42:43 jaypipes, bcwaldon: so is it seufficiently off your vision of what "openstack core" should be to be denied incubation ? 20:43:09 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 ttx: I'm becoming increasingly concerned with what 'incubation' and 'core' mean 20:43:41 ttx: so I would say 'no' until I understand that better 20:43:45 ttx: I've stated this opinion before.. I believe core == infrastructure. and infrastructure == 20:43:53 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 ttx: this is why I voted no on Horizon being in core originally. 20:44:06 jaypipes: agreed, that's consistent 20:44:18 but would you support a motion to REMOVE horizon from core now ? 20:44:19 ttx: it's a great project, it just didn't meet the "won't run without it" factor. 20:44:21 I agree with the comparison to Horizon and the question to me is does it add enough value 20:44:32 there's a clear uptick in adoption based on Horizon's inclusion 20:44:40 ttx: no, I would NOT support that. just saying what the basis of my opinion is. 20:44:40 gabrielhurley: do you see Horizon making use of Heat if it ever becomes a core project ? 20:44:46 would the same be true of HEAT?maybe 20:45:01 Horizon-Heat integration would absolutely happen 20:45:12 gabrielhurley: good point re: the addition of value vs. infrastructure over platform. 20:45:14 although amusingly you could also use Heat to deploy Horizon 20:45:15 FYI an external contributor is working on a Horizon Heat ui 20:45:24 gabrielhurley: I guess it all boils down to what is core... 20:45:28 yeah 20:45:31 I'm still undecided, FWIW 20:45:33 ttx: heat plugin for horizon in-progress 20:45:33 stevebake, got the link? 20:45:41 it's on github 20:45:43 * markmc can't find it 20:45:47 I've seen it 20:45:51 it's very nascent, but does exist 20:45:59 https://github.com/heat-api/heat-horizon 20:46:12 shardy: shouldn't that be "mirage"? :) 20:46:16 heh 20:46:19 +1 20:46:26 I agree with bcwaldon and jaypipes (except I would support removing current core non-IaaS projects) 20:46:28 I think this is an older screencast http://radez.fedorapeople.org/thermal1.ogv 20:46:28 there is also a screencast demo from radez around somewhere, not got the link to hand 20:46:33 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 https://github.com/heat-api/heat-horizon 20:47:03 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 yep 20:47:18 I'm familiar with cloudformation and how it's all supposed to work 20:47:21 it's an interesting challenge 20:47:28 what Amazon ended up with is awful 20:47:34 we'd have to do better ;-) 20:47:38 heh 20:47:53 gabrielhurley: we'd love to hear your input about that on the ML :) 20:47:57 for sure 20:48:01 lots of potential for autogenerated ui 20:48:07 definitely 20:48:27 * ttx repeats: Does anyone need extra information before deciding 20:48:33 nope 20:48:36 no 20:48:40 not me 20:48:40 no 20:48:41 or can we move on to vote (abstain being an option) 20:49:38 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 #startvote Approve Heat application for incubation? yes, no, abstain 20:49:48 Begin voting on: Approve Heat application for incubation? Valid vote options are yes, no, abstain. 20:49:49 Vote using '#vote OPTION'. Only your last vote counts. 20:49:54 #vote abstain 20:49:55 #vote yes 20:49:56 #vote abstain 20:49:57 #vote no 20:49:59 #vote yes 20:50:08 #vote abstain 20:50:08 #vote yes 20:50:13 #vote abstain 20:50:13 #vote yes 20:50:23 #vote yes 20:50:30 #vote abstain 20:50:31 ouch, that's close 20:50:35 wow 20:51:07 30 more seconds, unlikely to chnag ethe results anyway 20:51:11 I think we're sending a poor message approving for incubation and what it implies 20:51:14 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 note that you can change your vote. 20:51:35 * annegentle___ is only voting for incubation, core is in the future 20:52:02 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 that's a long 30 seconds :) 20:52:33 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 I don't know how we can reasonably vote for this without understanding what this means 20:52:34 annegentle___: that was my thought. incubation now, the rest is obviously up in the air 20:52:50 basically, start pushing the resources but be ready to pull them out 20:52:52 jaypipes: yes that (the "old" or "current" definition) 20:52:57 :) k 20:53:09 ttx: understood, but I'm abstaining because I think it's important to nail down what incubation means first. 20:53:11 markmc: as long as people discuss... 20:53:23 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 ok then 20 seconds 20:53:40 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 talk about sending a bad message ... 20:53:50 markmc: we need to define what it means to 'welcome into openstack' 20:53:58 #endvote 20:53:59 Voted on "Approve Heat application for incubation?" Results are 20:53:59 markmc: I'm more than happy for the project to exist and be associated 20:53:59 gabrielhurley: +1 to that 20:54:00 rejecting would be an awful message of exclusivity IMHO 20:54:01 yes (5): markmc, ttx, russellb, danwent, annegentle___ 20:54:02 abstain (5): heckj, gabrielhurley, jaypipes, bcwaldon, vishy 20:54:03 no (1): notmyname 20:54:07 markmc: only if you assume that not going into incubation is somehow bad (which it isn't) 20:54:09 bcwaldon, yeah, we suck we don't know what that means yet 20:54:09 bcwaldon: +1 20:54:21 lol 20:54:26 markmc: we need to be exclusive - we can't just accept anybody 20:54:32 bcwaldon, we're not 20:54:40 markmc: I wrote a project that spins up vms based on a script, should that be OpenStack™ 20:54:48 it seems like the logic being applied here is not consistent with the ceilometer vote last time 20:55:00 bcwaldon, I thought we weren't talking about trademarks :) 20:55:03 danwent: FWIW, I voted the same way :-) 20:55:06 I voted yes for the same reason I voted yes for ceilometer 20:55:12 notmyname: fair :) 20:55:12 markmc: I've had to come down to your level ;) 20:55:16 damn trademarks 20:55:23 danwent: would I be inconsistent 20:55:26 dansmith: ? 20:55:27 bcwaldon, trademarks are the last thing I want to talk about! 20:55:31 gah. danwent ... 20:55:39 markmc: me too! blah 20:55:49 i think voting yes to ceilometer and abstain to heat is inconsistent. 20:55:57 jaypipes: :) to me there was uncertaintly about the definition of "core" and "incubation" in both cases 20:55:59 russellb: is that what I did? 20:56:14 i don't know, just making a general statement, we had almost all yes to ceilometer 20:56:21 russellb: if so, yes, I was inconsistent and should not have been. 20:56:26 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 bcwaldon++ 20:56:31 * ttx lags 20:56:31 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 err, just was off network for a bit 20:57:05 did the bot record the results and my #endvote ? 20:57:10 yes 20:57:22 ok, I guess I'll read the log 20:57:32 #topic Preliminary discussion: Third-party APIs 20:57:32 ttx: 5-5-1 20:57:45 shardy, stevebake, zaneb, welcome :) 20:57:45 ttx: with 3 minutes remaining? 20:57:46 what does 5-5-1 mean, basically abstain? 20:57:52 or what? 20:57:53 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 russellb: it means yes 20:57:58 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 ttx: ok, thanks. 20:58:06 russellb: more yes than no, and at least 5 yes or no 20:58:11 heckj, this is an easy conversation :) 20:58:24 ttx, I can summarise the motion 20:58:44 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 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 #action markmc to summarize and propose a clear motion by EOD tomorrow 20:59:12 for next meeting 20:59:35 #action ttx to start discussion on the incubation/core process on -dev ML 20:59:39 markmc: yes 20:59:44 vishy, thanks 21:00:02 ok, no time for more today, see you all next week ? 21:00:19 yep, thanks ttx 21:00:28 thanks ttx 21:00:34 #endmeeting