20:01:56 #startmeeting tc 20:01:57 Meeting started Tue Sep 24 20:01:56 2013 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:01:58 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:01:59 o/ 20:02:02 The meeting name has been set to 'tc' 20:02:02 Our agenda: 20:02:07 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:02:09 Morning 20:02:14 This should be the last meeting for the current members ! 20:02:23 Let's break everything 20:02:30 ttx: +1 20:02:31 #topic Savanna incubation request: final discussion / vote 20:02:32 Heh 20:02:36 well then 20:02:37 wow sad to see the band break up 20:02:41 #link http://lists.openstack.org/pipermail/openstack-dev/2013-September/014623.html 20:02:47 #link https://wiki.openstack.org/wiki/Savanna/Incubation 20:02:55 Two weeks ago we had the initial discussion on Savanna. Several issues were raised... 20:03:05 Including the fact that Savanna was both providing a hadoop-cluster-provisioning API and a mapreduce data API 20:03:14 And that the cluster provisioning part still had to see where it fits, compared to Heat and Trove 20:03:20 Sergey posted a few answers recently at: 20:03:28 #link https://wiki.openstack.org/wiki/Savanna/Incubation#Raised_Questions_.2B_Answers 20:03:41 The discussion last week (and on the mailing-list since) shows that a lot of discussion is still needed to come up with a final integration plan 20:03:52 Some TC members think that incubation would be a way to encourage that discussion 20:04:05 Other TC members would prefer that the integration roadmap is finalized prior to incubation, the incubation period being about the execution of that plan (with graduation when the plan is executed) 20:04:05 * annegentle is listening to/watching the video at http://www.youtube.com/watch?v=SrlHM0-q5zI 20:04:31 Personally I was on the first group but I think the second group's position makes a lot of sense... no real need to rush this. But I just want to make sure that discussion happens 20:04:58 well, and I think incubation further encourages the discussion 20:04:59 * mordred is in the first group - doesn't think that we've required the integration plan pre-incubation for anyone else 20:05:01 So I guess I would be fine with deferring incubation for a few weeks/months, as long as we still give time to Savanna at the design summit so that they can discuss with other incubated/integrated projects and come up with a plan 20:05:22 i think incubating them gives even more reason for everyone else to participate in the needed discussion 20:05:28 so i guess i'm in the first group 20:05:33 mordred: I think the bigger questions were around overlap 20:05:57 yup. I'd also like to say thank you to SergeyLukjanov for responding to last time's questions 20:05:58 * jgriffith appears to be the only one still in the second group 20:06:12 we haven't required a full integration plan in the past, but integration hasn't felt as troubling to me personally in the past 20:06:25 I'm with markwash, it's a timing thing 20:06:30 integration means something very different in this case IMO 20:06:31 jgriffith: you're not alone. 20:06:46 may mean that it's incubating for longer than one release then 20:06:49 but i don't think that's bad 20:06:51 It's perfectly fine to defer the request until the concerns of scope overlap are solved 20:06:56 russellb: ++ 20:07:00 jgriffith: i'm in the second group with you 20:07:00 * markmcclain is in 2nd too 20:07:02 I was trying to think of any "loss" from deferring incubation, and I don't see any other than fairness, that they are getting more scrutinized due to the recent growth. 20:07:26 annegentle: IMO that needs to happen at some point 20:07:37 i think that whatever plan you go with should not result in the sort of situation we were in with trove where we graduated a project from incubation because we "had not been clear at the outset what the requirements should be" 20:07:38 annegentle: and I really think they're a *new* type of project 20:07:39 for me, the project looks like it's on the right track and has a sustainable developer team around it 20:07:43 and I'm not always in the business of fairness as my kids will tell you :) 20:07:43 mordred, russellb: the trick is, we bless the end goal here and the team to deliver it. here the end goal still looks a bit fuzzy to me, with both clustering and data API 20:07:56 annegentle: haha1 20:08:09 It is important to have this discussion now I think, because its a lot harder when people have put in all the incubation work and think its a done deal and then we're concerned. 20:08:17 ttx: the https://wiki.openstack.org/wiki/Savanna/Incubation#Raised_Questions_.2B_Answers has an aim towards most of the provisioning going to heat 20:08:17 mikal: +1 20:08:19 ttx: well can't we just make that clear now then, that there will be expectations, and those need to be formed? 20:08:25 mikal: ++ 20:08:31 I'm concerned that, based on the proposed integration specifically re: Trove, the savannah group may have a vested interest against what seems to me to be a likely "best" integration path 20:08:45 which is why bestowing incubation status feels like it may be premature 20:08:56 o/ 20:09:03 what are we saying is the "best" integration path? 20:09:38 markmc: personally I don't know that we can say that, other than address the overlap and shared concerns 20:09:39 markmc. . not we, just me. . I'm considering "savannah uses trove to deploy hadoop" to be a potential answer 20:09:52 * hub_cap stays quiet 20:10:08 I still don't know what "uses trove to deploy hadoop" really means - the two don't seem related to me at all 20:10:15 mordred, agree 20:10:15 mordred: +1 20:10:27 both of them using heat, yes 20:10:29 incubation should be about "Does this could ever be an integrated project for OpenStack?", that's it, IMHO, the rest is the purpose of incubation 20:10:33 russellb: ++ 20:10:36 the cluster provisioning *implementation* overlapping with heat makes sense to me 20:10:46 markmc: ++ 20:10:47 jd__: if that's the case it's an easier question IMO 20:10:49 which is similar feedback we gave to trove 20:11:03 yah. 20:11:13 jd__, we've required a sustainable developer team in the past too - e.g. for designate 20:11:16 fwiw, trove has no clustering solution, so integration will likely take a while whatever path is chosen ;) 20:11:20 markmc: the cluster provisioning implementation could be a new (shared) Heat resource 20:11:25 but it looks to me like savannah has that 20:11:27 mordred, russellb: I sit on the fence. I feel like we'll see a lot more clearly after the summit and be in a lot better position to decide. On the other hand, incubation might be a way to make sure that discussion happens :) 20:11:40 Keep in mind that provisioning VMs is a very small part of what Savanna brings to the table. 20:12:01 ttx: but if they don't incubate, they get lost in the noise 20:12:02 jd__: ++ 20:12:10 markmc: well because we probably don't envision a project with 0 or 1 developer being part of integrated OpenStack ;) 20:12:12 ErikB: that's a good point 20:12:21 russellb: if they poof that easily better now than later 20:12:24 ErikB: yeah. this sentence is what I think did it for me: "Hadoop isn't a database or just data storage, but a huge ecosystem with tons of data processing related tools." 20:12:26 jd__, right 20:12:34 russellb: in particular, I would like to clarify if Savanna's goal is to provide a provisioning API, a data API, or both. 20:12:50 ttx: +1 20:13:03 Currently it's "both", and it doesn't make real sense to me as an openstack project 20:13:03 which helped me realize I was framing hadoop a bit wrong in my head 20:13:16 mordred - exactly. Deploying Hadoop is complex and often times vendor specific not lending itself well to a generic approach. 20:13:18 ttx, what's the big issue with "both" as an answer? 20:13:22 * markmc isn't seeing it 20:13:25 ttx - both what? 20:13:26 ttx: I've been struggling with that view since you said it originally ... 20:13:28 what markmc said 20:13:44 I'm not sure what it's a problem - given the nature of hadoop/map reduce processing 20:13:52 I'm still very on the fence about this entire type of project... The "data processing" program seems like a big grey area of user/customer-oriented workflows and best practices and I have a hard time seeing the right fit for integration, but maybe that's just me. 20:13:54 the issue for me is that we already have similar provisioning apis 20:13:55 markmc: I see those two APIs as having a completely different audience 20:14:13 gabrielhurley: not just you FWIW 20:14:23 markmc: that's really two projects lumped together 20:14:24 it's goal isn't to provide a provisioning api or a data api. it's goal is to make hadoop viable in an openstack, virtualized environment. provisioning is part of that process, and it's MUCH more than a data api 20:14:38 I see it as "as a user of a cloud, I would like to map/reduce some data, but I don't want to have to understand the ops aspect of running a hadoop cluster" 20:14:43 ttx, for hadoop? I think I see it as the same audience 20:14:47 maybe I just need more time to find my way to the Kool-Aid table :-) 20:14:48 mordred, right 20:14:49 I _do_ grok the map/reduce job I want to run 20:14:54 jmaron: if you say that, then I have to say "why hadoop and not X?" 20:14:59 this is why I think it's a good fit for a cloud 20:15:03 ttx: you can't have one without the other. Provisioning is incidental it's the provisioning of the hadoop services on the virtualized resources where the value is. This is complex, vendor specific. 20:15:20 either a) you hav ea job and you want to run it on your own private hadoop, and still don't wnat to manage the details of running the hadoop 20:15:30 Hadoop is a huge ecosystem and Savanna goal is to provide integrated experience of running Hadoop solutions seamless on top of OpenStack 20:15:33 or b) you have a job and you don't mind running it on a potentially shared hadoop 20:15:57 but in either case, you want the workload taken care of, and you don't really care about the details of how the cluster operates 20:15:59 gabrielhurley: Savanna is specifically focused on hadoop and nothing else at the moment 20:16:08 yes, but why should OpenStack bless Hadoop? 20:16:09 providing integration with existent tooling to properly configure and operate Hadoop clusters in integral part of the all process 20:16:15 mordred: interesting 20:16:26 and Elastic Data Processing or Data API is built on top 20:16:27 gabrielhurley: same reason we bless MySQL 20:16:33 except we don't 20:16:36 sure we do 20:16:42 trove is MySQL aaS out of the box 20:16:42 we implicitly use mysql and are trying to add more backends 20:16:52 trove is also working to support postgres and nonrel 20:16:53 mordred: it has abstraction to provide for others 20:16:53 gabrielhurley, Hadoop is the largest open source eco in area of Big Data 20:17:01 gabriellehurley: I would assume openstack welcoming hadoop would be a win-win for both 20:17:02 I'm with gabrielhurley on this one :) 20:17:15 SergeyLukjanov: are they any viable competitors at the moment? 20:17:16 gabrielhurley - it's not about what is on backend of OpenStack - it's about apps running on OpenStack 20:17:19 jmaron: ++ 20:17:21 IlyaE, mordred: I guess I can see your point of providing a "portfolio of solutions for people wanting to do mapreduce stuff" 20:17:26 Savanna (as I understand it) has no intention of being pluggable, or agnostic in any way 20:17:27 SergeyLukjanov: or is it so big its the only game in town? 20:17:36 trove wil be supporting posgres soon fwiw, and redis 20:17:39 gabrielhurley: OpenStack provides IaaS presumably to do something useful, one of the use cases that users are screaming for is to deploy hadoop on OpenStack. This is not easy todo today, as a matter of fact it's quite difficult. Savanna solves this exact problem and brings hadoop to the masses on top of OpenStack. 20:17:44 Hadoop has a great ecosystem, but it's far from the only game in town 20:17:46 and cassandra / mongo will come after :) 20:17:49 IlyaE, mordred: that would address my fear of "two different audiences" 20:17:52 why wouldn't I want to use an off-the-shelf hadoop job management system, and just deploy my hadoop on openstack with trove or heat? 20:17:56 gabrielhurley Savanna has pluggable mechanism implemented already 20:18:00 ttx: 20:18:02 ttx: ++ 20:18:04 mikal, there are a lot of other tools in area of data processing, for example, Twitter Storm (that is now on the go to the Apache Foundation) 20:18:08 Yeah I'm a conservationist for OpenStack resources and having to support hadoop/savanna in our support channels is not win to me 20:18:11 markwash: because that's really hard 20:18:17 FWIW, I'm not arguing the value of savanna as solving a real problem. I'm questioning if that's a problem that integrated OpenStack is trying to solve for it's users. 20:18:45 ttx In terms of audience it's absolutely the same - people who need to run analytic/computational workloads on cloud platform 20:18:51 * mordred thinks that IaaS means "help me do things via APIs that I normally have to hire admins to do for me" 20:19:00 IlyaE: point taken 20:19:29 annegentle: you are not interested in running viable, sought after application soltuions on openstack? 20:19:33 SergeyLukjanov: would it be possible to have an API which expresses botha Hadoop map reduce or a Storm one in a sensible manner? 20:19:39 so that as a dev, I can focus on the task at hand, and as an operator, I can consolidate admin knowledge into an efficiency-by-scale solution 20:19:47 mordred: but admins can do ANYTHING 20:19:48 SergeyLukjanov: or are their assumptions so fundamentally different that API wouldn't make sense? 20:19:48 jmaron: not at all, but what resources are they entitled to? 20:20:00 mordred: wordpress shared blogging platforms ;-) 20:20:11 mikal yes Twitter Storm can be deployed to Hadoop via Yarn 20:20:22 notmyname: incubation approved 20:20:24 Hadoop clustering is hard. I wouldn't really want to do it from scratch personally. If I were gonna do it on OpenStack I *might* use Savanna for that. But I don't know that I would expect to find Savanna as a batteries-included part of OpenStack. The more I think about it the more it feels like an essential and important part of the ecosystem... 20:20:32 mikal, in terms of data processing api there are the same - run some workloads with specified configs, inputs and outputs, etc. 20:20:34 * markwash only kids 20:20:56 mikal, there are different data processing tools - Pig, Hive, raw MapReduce jobs. we already have API to use any of them 20:21:06 gabrielhurley: I'm not sure what "important part of the ecosystem" means 20:21:15 gabrielhurley: or what that looks like to me as a consumer 20:21:19 gabrielhurley: I don't always install Hadoop, but when I do, I use Savanna. 20:21:25 ttx: hahaha 20:21:37 mordred: if OpenStack doesn't find a way to promote projects that are useful and well-written without integrating them, we're doomed. 20:21:39 SergeyLukjanov: so you don't see a large _technical_ barrier to addding storm to savannah later if there was demand? 20:21:50 dooooooooooooooooomed 20:21:55 doooooooooooooooooooooooooooooooooooooooomed 20:21:55 sorry 20:22:00 So I guess we have three options for this meeting's vote: approve incubation now, defer the application until after summit and give some time at the summit to clarify it, or just plain deny it 20:22:01 gabrielhurley: exactly. 20:22:01 I'm not 20:22:13 mikal, no, there are no problems to add Twitter Storm to Savanna 20:22:18 gabrielhurley: I'd say if the ecosystem doesn't find a way for those to make sense for consumers, the ecosystem is doomed 20:22:22 I'm open to summit time and more thoguht 20:22:24 righ tnow "the ecosystem" is vaporware" 20:22:31 ttx: that sounds like two votes: do we defer; and do we incubate? 20:22:33 mordred: it's a two-way street 20:22:35 but yes 20:22:36 gabrielhurley: I don't think there is a silver bullet for every app 20:22:39 ttx: the second one only being needed for some outcomes of the first 20:22:42 (note that solution (2) is also about punting to the next TC membership) 20:22:50 gabrielhurley: if any of our public clouds would do anything other than NIH, we might get somewhere 20:22:59 :-/ 20:23:02 mikal: (2) is like (3) but granting some official summit time 20:23:15 gabrielhurley: thus far, the ONLY way any of them EVER work together on ANYTHING is when we're involved 20:23:32 ttx either way the integration vote is w a new group :) 20:23:34 so, as soon as I see that behvior even start to change a little bit, I'll be less of a maximalist 20:23:34 ttx: is there something that says a project that has been denied incubation by one TC can't re-apply to another TC? 20:23:35 mikal: I guess so, yes 20:23:41 dolphm: no 20:23:51 ttx: then what's the difference between 2 and 3? 20:24:01 ttx: either way it's a vote for "not now" 20:24:01 agreed. that's partly their fault for not self-organizing more, and partly ours for not guiding more and providing more framework/structure/tools that aren't stackforge->integration 20:24:14 dolphm: you allocate official summit time for savanna, which would otherwise have to fight for space in the unconference or wherever 20:24:16 So, I think deferring is a cop out. We've had several weeks to discuss this, and I'm not clear on how the small amount of free time each of us has at the summit will help things be clearer. We're here to make a technical call, and we should do that. 20:24:18 gabrielhurley: fair enough 20:24:35 ttx: ah, important distinction then 20:24:47 gabrielhurley: (altohugh I do think hadoop is normal enough that I want to see clouds support it across the board) 20:24:47 fwiw, regardless of tc vote, myself, heat core members and savanna need to talk 20:24:53 myself=trove 20:24:59 there is a lot of overlap 20:25:03 le trove, c'est moi 20:25:09 gabrielhurley: so I agre with you in the large, but on this particular thing, I think a hadoop is something I expect a cloud to be able to give me 20:25:16 I agree with gabrielhurley and mordred, "the ecosystem" is fuzzy and we should make that better, but is incubation "the ecosystem" is also fuzzy to me. 20:25:17 hub_cap: ++ 20:25:24 hub_cap: yes, and i think incubating a project is the best way to encourage that to happen 20:25:26 It looks like there is no consensus right now, and a bit more savanna exposure could help solve that 20:25:51 as well as hadoop exposure 20:26:12 ttx: a lot of TC members aren't talking at the moment though. I feel like a vote is the best way to test for concensus. 20:26:17 mikal: ++ 20:26:20 ++ 20:26:24 that is, after all, what voting is for 20:26:34 yeah 20:26:38 true words 20:26:42 it would seem unfair to the savannah folks not to vote 20:26:43 I'm studying savanna a ton, and I think they're on the right track, and I'd like to encourage them, but I'm not sure the timing of incubation before summit is quite right. 20:26:46 mordred: Hadoop's kind of a "least-common denominator" right now. it's often not the *right* thing, but people use to to kick the tires a bit, or to do some job that doesn't deserve to be specialized... 20:26:49 while voting keep in mind, that Savanna is fairly advanced technically, with cluster provisioning up and working, plugins allowing different Hadoop distributions integration, stable and growing community team 20:26:51 they've done everything we've asked to prepare for this 20:26:57 we have bunch of videos published 20:27:06 btw we've already have a bunch of working code and a great team that is working on project for long time, dashboard plugin, python bindings, diskimage-builder elements 20:27:12 annegentle: What timing would be better? 20:27:13 markmc: +1 20:27:14 markmc: ++ 20:27:25 I actually think they've done an excellent job in both keeping up with infra things 20:27:28 IlyaE: paradoxically I feel like it's that advancement that plays a bit against it :) 20:27:29 and being proactive about it 20:27:31 IlyaE: SergeyLukjanov so here's the thing... YOu're way ahead and things look great IMO 20:27:41 and incubation status would really help to accelerate the further integration of Savanna to OpenStack 20:27:42 annegentle: ++ 20:27:49 the confusion I have is how to reconcile with the overlap of tasks 20:27:52 that would be the key goal for IceHouse 20:28:02 IlyaE: i'm not convinced that's true 20:28:03 IlyaE: ++ 20:28:05 You keep saying "cluster provisioning is only a small part" 20:28:05 i think it's clear that the overlap is an issue and it's the major expectation we have to be worked on 20:28:07 but it is a part 20:28:15 and it's not that small else we wouldn't need heat 20:28:26 I'm fine with incubation 20:28:31 ok, we can do a plain yes/no vote, and in case no wins we can decide of any special measure like summit exposure 20:28:40 I just think it would be great to have better coordination 20:28:41 if everybody thinks Hadoop as a service fits OpenStack, the rest is up for incubation 20:28:42 ttx: ++ 20:28:46 ttx: ++ 20:28:48 overlap resolving etc 20:28:56 jd__: that's my take too 20:28:58 jgriffith, we would like to move provisioning code out as much as possible by Heat integration 20:28:59 jd__: I can agree with that 20:28:59 ErikB: probably just conflating my discomfort with the havana release less than a month away 20:29:04 jd__: ++ 20:29:13 I definitely think a mapreduce API belongs 20:29:23 resolving overlap is a major issue, but what guarantees do we have that incubation encourages resolving it in the right way? 20:29:31 "small" isn't a slight or a comment on its importance. it's an indication that provisioning is only a portion of the tasks executed as part of provisioning hadoop on openstack. 20:29:39 I'm actually afraid it makes it worse 20:29:39 annegentle: I see. Although I see them as orthogonal with no impact on each other. 20:29:40 markwash: not granting graduation? 20:29:43 markwash: good point, but we don't have other mechanisms 20:29:47 I'm slightly skeptical about the provisioning stuff, and would like it to be extremely thin and reuse existing bits, but everyone agrees with that 20:29:52 markwash there is gating factor in form of graduation 20:29:59 markwash: I've been beating marconi over the head about things since they got incubated 20:30:01 I've no problem with incubation during 3 years if they can't resolve the issues -- though the project may be kicked out before :) 20:30:01 markwash: i don't think we have a guarantee, but my gut says it's better than saying no. 20:30:02 markwash, graduation is the guarantee 20:30:03 my opinion is simply that resolving overlap is outside the scope of incubation, which should just be the last few steps towards an integrated release 20:30:04 markwash: and they have to take it :) 20:30:08 I think the crucial thing is "in the right way" 20:30:14 it will certainly be resolved before graduation 20:30:27 I had trouble with the "dual audience" question, but IlyaE and mordred kind of fixed that 20:30:32 russellb: I'm good with that 20:30:34 yay! I was helpful! 20:30:36 but I don't yet buy a lot of the arguments that "hadoop is just different" 20:31:09 jd__: +1 20:31:09 so i would want to see more flexibiliity from advocates on that position 20:31:14 before voting yes to incubation 20:31:34 markwash, what does "in the right way" mean? 20:32:24 markwash: I'd say that data transformation is a basic application building block, like a queue or a database 20:33:00 nadya: there are lots of ways to resolve the overlap. . we could decide it doesn't exist, we could delete everything provisioning and replace it with heat, we could use trove to provision more things clustery, we could build clustering as its own component 20:33:01 markwash: that's how I solve the "hadoop is ok, but wordpress is not" question in my mind 20:33:02 markwash: hadoop is different in two perspectives I believe: scale of deployment (100's to 1000's of nodes) , coordination of configuring and startup of services. My point of reference being JavaEE servers and databases on Hadoop. 20:33:23 correction on Hadoop = on OpenStack 20:33:39 ummm... you can run single node hadoop. Just saying 20:33:41 nadya: but the advanced state and the corporate connection with savannah spells "vested interests" to me 20:33:47 but anyway, I think we're getting off track 20:34:03 so I just want to be sure before voting yes 20:34:04 jgriffith: this is not what we are solving. We are solving the real world use cases of large scale deployments. 20:34:17 What about things like Storm, Spark, Azkaban, etc. that aren't "hadoop ecosystem"? 20:34:20 also keep in mind from an openstack perspective a managed service(similar to trove) for provisioning and managing clustering services would be a good separated project. i.e it doesn't have to be Hadoop specific and can support other clustered applications as well. 20:34:23 fwiw incubation is a lot less... definitive than graduation to integrated is. 20:34:32 ErikB: settle, wasn't criticizing or challenging you there 20:34:43 rnirmal: I would vote for that in a heartbeat ;-) 20:34:48 ErikB: I understand what you're saying 20:34:54 gabrielhurley, some of them could be installed at Hadoop 2 using YARN (for example, Twitter Storm) 20:34:59 the next TC can remove it if it doesn't like what it sees, and it can stay in incubation for 3 years if that's what it takes to integrate properly 20:35:14 let's vote! 20:35:15 SergeyLukjanov: is that something Savanna would want to add to their roadmap? 20:35:41 markwash, I think all of us agree that Clustering API is important question and we are ready to discuss it. it's too complicated. several project are involved 20:36:10 * annegentle has to get to an appointment, mikal has my proxy vote 20:36:17 TC members: please indicate when you're ready to vote, so that I know when to start it 20:36:23 ready to vote 20:36:24 ttx: ready 20:36:26 ready 20:36:27 ready 20:36:27 ready 20:36:29 ready 20:36:32 ready 20:36:34 ready 20:36:36 ready 20:36:37 ready 20:36:41 ready 20:36:44 gabrielhurley, technically it's possible, but it's depend on approved project scope 20:36:49 ready 20:36:53 wait 20:37:02 SergeyLukjanov: I think this is essential to the idea of scope 20:37:03 * ttx freezes 20:37:07 is this part of your scope or not? 20:37:18 gabrielhurley, currently no 20:37:21 is your scope "hadoop" or "map reduce clustering"? 20:37:23 okay 20:37:27 thanks for clarifying 20:37:39 now ready 20:37:45 * mordred actually just held his breath tensely 20:37:49 lol 20:38:05 (only TC members vote, thx) 20:38:06 #startvote Accept Savanna in incubation for the Icehouse cycle? yes, no, abstain 20:38:07 Begin voting on: Accept Savanna in incubation for the Icehouse cycle? Valid vote options are yes, no, abstain. 20:38:08 Vote using '#vote OPTION'. Only your last vote counts. 20:38:13 #vote yes 20:38:14 #vote yes 20:38:15 #vote yes 20:38:16 #vote abstain 20:38:16 #vote no 20:38:19 #vote yes 20:38:19 #vote no 20:38:21 #vote no 20:38:22 #vote yes 20:38:22 #vote no 20:38:24 #vote yes 20:38:25 #vote no 20:38:25 #vote yes 20:38:28 #vote yes 20:38:36 30 more seconds 20:38:42 #vote yes 20:39:14 #endvote 20:39:15 Voted on "Accept Savanna in incubation for the Icehouse cycle?" Results are 20:39:16 yes (9): markmc, vishy, shardy, jd__, russellb, jgriffith, mikal, mordred, annegentle_proxy 20:39:17 abstain (1): ttx 20:39:18 no (5): gabrielhurley, dolphm, notmyname, markwash, markmcclain 20:39:23 That's a yes 20:39:31 <3 20:39:33 good call 20:39:35 congrats savannah folks 20:39:39 thank you 20:39:41 (too many to call out individually :) 20:39:41 ok now integrate better! 20:39:42 wow. we actually had a close vote! I'm proud of us! 20:39:43 thank you 20:39:45 thank you 20:39:47 :) 20:39:48 thank you a lot! 20:39:50 vishy: :) 20:39:56 thanks! 20:39:57 :) 20:39:58 sweet! 20:40:00 thank you 20:40:00 :) ! 20:40:03 thanks guys, i look forward to seeing what you do over the next 6 months 20:40:03 SergeyLukjanov: now you get to migrate to testr :) 20:40:05 indeed, congratulations and no hard feelings, I hope. I would still like to see more agnostic data processing and clustering instead of hadoop-specific. 20:40:06 :) 20:40:17 Explanation for my abstain: I would actually have preferred to vote on this after the next design summit. But then I'm selfish. 20:40:34 ttx: I was going to give you a hard time about that 20:40:42 anyway, this is devil's advocate club 20:40:46 #topic Open discussion 20:40:50 gratz savanna! hope to see you in the summit to chat trove! 20:40:53 (and heat) 20:40:55 The initial governance repo commit is still awaiting your reviews at: 20:40:57 ttx: so - sum up for me the state of the TC after this meeting 20:40:59 #link https://review.openstack.org/#/c/44489/ 20:41:12 hub_cap, yep, absolutely 20:41:14 Also PTL self-nomination in progress, closes Thursday 20:41:19 #link https://wiki.openstack.org/wiki/PTL_Elections_Fall_2013 20:41:23 The PTL nominations make me sad 20:41:24 gabrielhurley, i'd like to see that too 20:41:39 notmyname: you running? :-) 20:41:44 mikal: please elaborate 20:41:46 I think all of those candidates are great, but I worry that we haven't managed to build a larger group of potential leaders 20:41:47 ttx: do we have a TC between now and the TC elections? 20:41:53 u mean the ptl single person per category cept for horizon mikal? 20:41:56 mikal: you're not running? 20:41:59 markwash: it just feels unhealthy 20:42:00 mikal: yah. there is only one contested electoin 20:42:05 russellb: ya, just been doing fun stuff like debugging and airline bookings ;-) 20:42:08 mordred: the current TC is still in charge until October 17 20:42:12 * mordred considered nominating myself as a second candidate in all elections 20:42:12 jgriffith: that's a fair point, and I may yet. I did run last election... 20:42:27 just for funsies 20:42:29 I guess I'd rather see 1 candidate than 0 candidates 20:42:34 jgriffith: ++ 20:42:38 mordred: I think we should elect you for all of them if you do :-) 20:42:39 u know has anyone thoguht of that? 20:42:41 mordred: although it's good practice to avoid taking decisions while the vote is in progress... unless we are forced to 20:42:44 markwash: oh god. 20:42:50 what happens if u have 0 interested in a ptl for a 6mo? 20:42:50