20:02:09 #startmeeting tc 20:02:10 Meeting started Tue Sep 10 20:02:09 2013 UTC and is due to finish in 60 minutes. The chair is ttx. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:02:12 o/ 20:02:13 o/ 20:02:14 The meeting name has been set to 'tc' 20:02:17 o/ 20:02:17 Our agenda: 20:02:25 #link https://wiki.openstack.org/wiki/Governance/TechnicalCommittee 20:02:38 #topic Savanna incubation request: initial discussion 20:02:44 #link http://lists.openstack.org/pipermail/openstack-dev/2013-September/014623.html 20:02:50 #link https://wiki.openstack.org/wiki/Savanna/Incubation 20:02:59 SergeyLukjanov: hi! 20:03:13 ttx, howdy! 20:03:19 Hi 20:03:27 hi 20:03:30 So we usually consider incubation over two meetings. The first week is an initial discussion so that the main issues can emerge 20:03:46 and at the second one we usually conclude that discussion and vote 20:04:06 So this week is mostly about Q&A 20:04:22 Personally I had a question about the scope. Savanna is a single project but proposes two very different services: cluster and data operations 20:04:39 That sounds like two very separate use cases to me 20:04:47 yes the former seems very similar to trove mission 20:04:54 So far we had provisioning stuff like Trove 20:05:04 and data-oriented stuff like Marconi 20:05:06 I would like to hear more about plans for heat as well 20:05:17 mikal: ++ 20:05:22 but no project that would handle both at the same tiem 20:05:22 o/ 20:05:33 let's start from the question about cluster and data ops 20:05:37 could you explain the value of bundling those two activities in the same project ? 20:05:52 all data ops are build around the Hadoop eco 20:06:34 and the Hadoop cluster provisioning process is very complex, additionally, we need not only Hadoop cluster but a lot of other tools that works on Hadoop 20:06:36 i.e. relying on Heat? 20:06:49 Specifically, Savanna is focused around enabling setup, provisioning, configuration and deployment of Hadoop on OpenStack and related data operations that would be executed on Hadoop 20:07:22 yes but trove is focused on enabling setup, prov, config and deployment of X on OpensSTack 20:07:28 where X is a datastore 20:07:37 Savanna main goal is the elastic data processing, but without cluster operation it is unreachable. So the first step was creation of staff for cluster operation 20:07:43 sounds like a product definition more than a project definition... how much code would be shared between those two types of ops ? 20:07:54 hub_cap, we're not targeting Savanna as data store provider 20:08:19 (not saying you don't need both, just wondering how much sense it makes as a single project) 20:08:34 ttx, in fact we want to provide data ops using Hadoop eco, but we need to provision complex cluster to do it 20:08:40 im not sure what you mean by data store provider? youre targetting a "spin up a hadoop ecosystem", yes? 20:08:41 another way to look at it, is that the cluster part could be considered part of the OpenStack Deployment program 20:08:51 hub_cap: hadoop isn't storage, it's processing 20:09:02 mordred, yep, absolutely 20:09:07 russellb: or some kind of trove-like project that would leverage heat 20:09:08 SergeyLukjanov, ErikB, a little background of Hadoop might help to level the understanding 20:09:09 actually it's both.. 20:09:11 ttx: yes 20:09:23 im pretty sure its more than just processing 20:09:24 ok so the problem here is that cluster management and configuration is a shared problem 20:09:33 correct vishy well put 20:09:38 which is partially solved by trove and heat 20:09:43 russellb: I can see a use case for someone to spin up hadoop clusters rather than submit direct jobs... it just sounds like a very different type of user 20:09:53 ElasticDataProcessing allows to execute MapReduce jobs on demand. It means that Hadoop cluster will be provisioned specifically for the job, and destroyed once job is complete. 20:10:03 fwiw, i dont want to touch a data api w/ a 10 ft pole..., so i see savanna filling that gap 20:11:16 So the use case here is that a user sends an api requests saying "map reduce this please" and savnna brings up the jobs and kicks them off? 20:11:29 mikal right 20:11:31 is there no use case for long running hadoop clusters? 20:11:32 I guess I don't understand why Savanna shouldn't be using heat to orchestrate that process 20:11:51 I've heard it said that Hadoop is too complicated for Heat to deploy... I would love to at least find out what we're missing 20:11:54 hub_cap, we have such use case 20:11:58 or even hadoop provisioning for customers 20:11:59 hub_cap, yes there is such use case 20:12:01 mikal: but there is also a use case where a user sends api requests to bring up a whole hadoop cluster 20:12:02 to use on their own 20:12:32 ttx: a hadoop cluster that lives longer than a single map reduce you mean? 20:12:38 mikal: yes 20:12:40 ttx: that can still use heat behind the scenes tho, no? 20:12:47 shardy: definitely 20:12:50 * gabrielhurley is late to the meeting 20:12:52 shardy: agreed 20:12:53 shardy, +1 20:13:11 mikal: yes, and for which you'd use classic hadoop tools to submit jobs 20:13:26 ttx: fair enough 20:13:27 or some data api savanna provides ttx? 20:13:46 Hadoop can be fairly difficult to configure and deploy. Savanna provides the mechanism to deploy the Hadoop infrastructure (composed of multiple services, configuration, topology) on OpenStack leveraging distribution specific constructs. Each distribution (Apache, MapR, Cloudera, HDP) tends to provide their own mechanism for deployment and management which is what Savanna provides a framework for. Duplicating this in Heat 20:13:53 Hadoop cluster provisioning is a very complex process with tons of configs and Savanna provides an ability for users to create templates 20:13:58 IMHO Savanna is like EMR + Netflix Genie tightly integrated. I'm not sure Heat can solve the orchestration problem completely but I agree can be part of the solution 20:14:15 do you feel hadoop is more complicated than setting up a cassandra or mongo cluster? 20:14:30 because Trove is going to tackle those, as blueprints are sitting in our queue 20:14:32 hub_cap definetely 20:14:34 I might be wrong but currently heat doesn't have the option to do a post processing operation. which is needed for cluster configuration 20:14:43 oh oh oh Trove can :) 20:14:48 SergeyLukjanov: Trove would need that same capability to configure clusters and templates that describe the complexities of the different cluster deployments 20:14:49 I worry that saying "we can model this in heat" indicates a heat bug instead of a need for a new orchestration system 20:14:51 enhancing Heat might be a better solution though asavu 20:14:54 i know heat has deferred things too 20:14:56 rnirmal: but part of being an OpenStack projet is to work with other projects to fill gaps :) 20:14:59 hub_cap yes it hadoop cluster contains several services with circular dependencies 20:15:00 asavu: as mentioned by zaneb, we'd like to understand the parts you think you can't solve with heat atm 20:15:10 hub_cap, we're provisioning not only Hadoop, but Hadoop eco using some Hadoop management consoles 20:15:12 russellb: agree... just wanted to point it out 20:15:32 yes, hadoop(hdfs, mr service and services for data processing) has more complexity than deployment of cassandra 20:15:35 sure SergeyLukjanov / akuznetsov and im sure cassandra would be as such too... are there no ecosystem tools wrt it? 20:15:38 and i think one of the expectations if you were to be incubated would be to work with projects to fill gaps so that you can build on them as much as possible 20:15:47 +1 russellb 20:15:52 mikal: Agree, probably we just need to better understand what's missing/needed in Heat 20:16:12 My point is that while I see a value for the data API, I question the value of a hadoop-specific cluster thing. That would overlap with a lot of Heat/Trove space 20:16:13 shardy: yes. I think an analysis of that is something I'd like to see for part two of this discussion. 20:16:20 the main issue that Heat is not support a circular decencies 20:16:21 so part of the Q&A is trying to establish some vision for where this is headed, and how it might integrate 20:16:26 mikal: +1 20:16:30 yah 20:16:34 ttx +1. and id love a cassandra data api too built on top of heat/trove ;) 20:16:39 we actually have a wiki page for such questions about "Why don't you use Heat?" - https://wiki.openstack.org/wiki/Savanna/WhyNotHeat 20:16:44 I mean, when trove came to us, it was not using heat, and we said, dude, you should use heat 20:16:45 hub_cap, there are a lot of tools that works on Hadoop - Hive, Pig, Oozie 20:16:45 maybe savanna fits for a "data api" 20:16:50 ruhe: /me looks 20:16:58 SergeyLukjanov: sure, and i assume we could install them 20:17:09 we have a postprocessing guest that is in charge of this 20:17:13 * ttx looks 20:17:20 "Savanna currently maintains Grizzly+ compatibility. " - if you got integrated, would that still be a goal? 20:17:21 all of this isn't necessarily arguing where you should be *right now*, just where you should go :) 20:17:22 to be clear ... 20:17:25 and it keeps services online and reports failures 20:17:27 russellb: ++ 20:17:28 shardy afaik aws cloudformation doesn't have all the semantics we need e.g arbitrary script execution, vendor API interaction etc. 20:17:32 russellb: +1 billino 20:17:40 *billion 20:18:10 "Circular dependencies - we should generate ‘/etc/hosts’ for all instances in provisioned cluster." - I believe os-*-config will be your friends there 20:18:19 agree, that at some point we'll need to use Heat for provisioning. It's just a matter of time 20:18:28 ah - good 20:18:30 "Once Heat fulfills all these requirements we will be able and should use Heat for VM provisioning. " 20:18:39 mordred, we're currently planing to guarantee only H support in 0.3 release (mid October) 20:18:40 So... basically if Heat needs to be improved to be used as a basis for Savanna... then maybe it makes sense to wait for that to happen before filing Savanna for incubation. Incubation is about INTEGRATING with existing intergrated projects to form a coherent whole. 20:19:02 asavu: we're working on lots of native, non cloudformation-compatible functionality atm, your requirements (and contributions) would be very valuable to that process 20:19:02 projects can completely exist outside of incubation 20:19:06 +1 20:19:14 rather than just rolling your own everything 20:19:18 ttx: or, perhaps part of integrating is a list of things that need to be done on both sides to come out of integrating 20:19:30 i woould still see a lot of overlap between the clustering api trove has proposed and the savanna clustering api 20:19:33 it's hard to say "hey, heat, we need this feature for X" if X isn't on heat's radar per-se 20:19:38 rather than saying "just heat" 20:19:43 ttx, integration with Heat is one of our goals for I cycle 20:19:52 to be clear, the Heat team is working on a new template format with the explicit goal of being able to describe something like a Hadoop deployment 20:20:07 i think these sorts of things are fine to work on during incubation 20:20:09 i.e. this is the canonical example of what we want to be able to support 20:20:11 mordred: so you would incubate and let them there until proper integration is achieved ? 20:20:20 ttx: that's the point of incubation, no? 20:20:21 that's what we asked of trove 20:20:26 yar 20:20:26 ttx: +1 20:20:33 mordred: we welcome feedback from users and potential contributors about what features they need 20:20:39 ttx: mordred: +1 20:20:42 so does no one see the overlap between trove/savanna wrt the clustering? 20:20:50 hub_cap: ++ 20:20:51 i mean, we should have reasonable confidence that they can/will achieve what we're asking, and are off to a good start 20:20:52 mordred: sure, as long as the stated goal of savanna is to achieve that integration 20:20:56 hub_cap: sure- I'd love to see you guys working together 20:21:18 +1 mordred it would make trove a better product 20:21:19 hub_cap: explicitly working on solving that - either by one of you consuming the other, or by spinning off a third thing that both of you consume 20:21:21 or something 20:21:37 mordred: i.e. it makes sense to incubate if its' to work on integration. Not so much if it's to explain that they can't use Heat because of A and B 20:21:40 absolutely mordred... something can be consenus-ified 20:21:48 SergeyLukjanov, wouldn't you say that a core goal of savanna is to integrate with other openstack projects? 20:21:53 also cluster provisioning doesn't just apply to hadoop.. it's hadoop today.. spark tomorrow and a whole lot of possible other tools/projects 20:21:58 ttx: I think their 'why not heat' is already actually a 'why not heat right now' 20:21:58 hub_cap: what "clustering" do you need that couldn't be provided by heat? 20:22:02 but Sergey said it's one of their goals, so I think we are fine 20:22:03 +1 rnirmal 20:22:05 imho it's a core reason savanna is being done in the openstack community instead of outside 20:22:05 sounds like that shared clustering feature might be a good candidate for a shared library 20:22:21 gabrielhurley: that would work 20:22:26 ttx, yep integration with other OS projects is our goal 20:22:41 vishy: we use heat for clustering, for installiation of a cluster 20:22:49 doing things like master/slave promotion for mysql 20:22:50 i think part of incubation should be viewed as more attentive guidance from us on how/where a project should integrate 20:22:51 or failover 20:23:07 mordred: I'd like to see a roadmap of "$stuff we need to migrate to heat in the medium term" 20:23:08 complex things require knowledge from "within" so to speak, being a guest 20:23:13 i think that works well ... gets it more on everyone's radar 20:23:16 ok so promotion and failover 20:23:18 there is also benefit to a common API for clustering so we don't end up with two completely distinct clustering API provisioning methods 20:23:35 that isn't what I think of when i think clustering 20:23:35 to start, vishy, thats 2 things i can think of 20:23:37 unless the use case is so different that it calls for it, but I don't see it as such just yet for the API 20:23:50 demorris: +1 20:23:54 vishy: clustering a data store 20:23:56 because if it is just launch a group of vms i think heat handles that just fine 20:23:57 I think you need a clearer definition of "cluster" and or "clustering". In the hadoop world it's more than the provisioning of VMs - it's the provisioning and configuraiton of a slew of data services on top of those hosts (Note that hadoop isn't necessarily cloud/VM aware) 20:24:00 hub_cap, I hope that we'll use Heat for cluster provisioning and potentially for [auto]scaling support 20:24:12 possible clustering should be done on Heat side, for example cluster for j2ee application 20:24:15 vishy: totally agree, thats what we are doing in trove :) 20:24:20 cluster deployment is one of the simplest things in Savanna. there are lot's of details related to Hadoop - integration with Swift, HDFS block placement 20:24:21 so specifically it is atomically configuring things 20:24:23 install = heat 20:24:31 which is going to require something like zookeeper, no? 20:24:56 possibly :) 20:25:02 can't heat already handle that? or will do soon? 20:25:06 that doesn't sound like it specifically belongs to one project so shared library might be the way to go 20:25:22 im all for shared lib 20:25:25 shared = better right? :) 20:25:29 have to wonder if it actually fits into the the taskflow library 20:25:31 hub_cap, so the idea is to develop clustering support in Heat which then could be used by Trove and Savanna? 20:25:48 possibly? we are already going ot use heat for clustering support 20:25:57 ruhe: +1 20:25:59 hub_cap: cluster_provisioning lib is VERY(!!!) good point 20:26:01 i see it as savanna uses trove for clustering / post processing etc... 20:26:14 hub_cap: and it could be like the part of heat 20:26:16 and if you want a "hadoop prov api only" you can use trove 20:26:23 the location of the clustering library is a minor point 20:26:23 which obviously will use heat to prov 20:26:26 * ttx sees a lot of discussions needed between heat, trove and savanna guys in HK 20:26:33 yes plz! 20:26:38 but I like what I'm seeing 20:26:38 ttx ^ ^ 20:26:49 i think there is much overlap 20:26:53 and i dont like duplicating work 20:27:03 hub_cap +1 20:27:03 ttx: ++ 20:27:08 hub_cap, Trove is 'Database as a Service', but Hadoop isn't a DB 20:27:22 is it not, at the heart of it? 20:27:27 ttx: ++ 20:27:31 is there not a (or many) ways to process and retrieve data 20:27:35 and a storage engine 20:27:42 it is and it isn't ;) 20:27:43 hub_cap, it's main goal is bigdata processing 20:27:46 and a plethora of tools avail 20:27:46 SergeyLukjanov: but Hive/HBase - yes ! 20:28:07 absolutely, and i dont want to touch processing in Trove 20:28:08 I think at the very least, even with clustering completely stripped off, savanna would make sense standalone as a data API 20:28:19 ttx:++ 20:28:30 id love to see savanna as the data api in openstack 20:28:32 ttx: good point 20:28:38 ttx: I agree. I just think savanna should be as thin as possible to reduce duplication of effort 20:28:48 mikal: ++ 20:28:51 the deployment still has to be solved somewhere 20:28:54 mikal: sounds like one of my lines 20:28:58 hub_cap, i guess we need a definition of clustering 20:29:02 id love to see savanna tackle cassandra and mongo in the future 20:29:06 ruhe: yes 20:29:08 in terms of data api 20:29:13 thin++ 20:29:19 those might be different data APIs though ... 20:29:26 russellb: oh sure. But it's aproblem space that several others are exploring..; and all those people need to talk around a beer to solve it 20:29:35 fair enough 20:29:39 ttx beer+whiteboard 20:29:41 mikal: ++ 20:29:41 hub_cap, we're planning to support cassandra as external data source 20:29:43 hub_cap: cassandra/mongo via savanna ?? 20:29:53 dmakogon_: the data api 20:29:58 SergeyLukjanov: I also have a slight concern about you being the author of more than half of the commits 20:30:00 not the prov/clustering 20:30:03 It's not as extreme as Designate (59% instead of 84%) but it still looks a bit brittle to me 20:30:06 where can I learn more about the savanna data api? 20:30:09 hub_cap we will have cassandra and mongo as one of the data source for edp 20:30:17 SergeyLukjanov: are you superman ? 20:30:28 SergeyLukjanov: are there buses near where your live ? 20:30:34 akuznetsov: and you will need clusters for those correct? 20:30:56 and trove is going to solve prov'ing those clusters in its near future (dmakogon_ is foaming at the mouth) 20:30:56 markwash https://wiki.openstack.org/wiki/Savanna/EDP 20:31:03 ttx, it's mostly related to the initial state of the project, you can take a look for the last 3 months percentage 20:31:16 hub_Cap: correct me if i'm wrong, trove could use savanna(in future) for provision clusters of cassandra ? 20:31:19 https://github.com/stackforge/savanna/contributors 20:31:30 and I keep typoing Savanna as Savannah because of Savannah, GA 20:31:32 :( 20:31:41 i see it as the opposite dmakogon_, savanna being a data api uses trove to prov the clusters 20:31:45 and then does magic data stuff w them 20:31:48 hub_cap, i'm not sure if database_as_a_service is a proper tool to provision data_processing_tool 20:31:57 ttx, savanna has active development from mirantis, red hat and hortonworks. state is mirantis seeded the project and has a lot of historical commits. 20:31:58 ruhe, agreed 20:32:14 hub_cap: it sounds like you are starting to see trove as cluster_provisioning_as_a_service 20:32:23 akuznetsov: so is it basically "post up a hive/pig script after establishing your data sources" ? 20:32:28 maybe that needs to be split out into it's own service then 20:32:29 SergeyLukjanov: agree that recent data shows a good trends 20:32:29 hub_cap: we can do it in any way 20:32:31 well we are clustering nosql datastors as a service vishy :) 20:32:46 man i cant type 20:32:46 i don't think it clearly "belongs" to any project today 20:32:47 hub_cap: savanna via trove, trove via savanna 20:32:57 mattf: there are a lot more mirantis people though right? I don't think that's bad (and all credit to mirantis), but do you think the project would survive if for some reason it stopped being a priority for mirantis? 20:32:58 hub_cap: multiple dual support 20:33:02 i think we all agree that clurster provisioning is important 20:33:04 markwash not only 20:33:16 * cluster 20:33:16 +1 for clusters 20:33:19 and it goes somewhere 20:33:23 the provisioning of VMs in savanna is already fairly well partitioned as an API/service. trove/heat are not precluded as playing a potential role. However, it is only a portion of what is required to configure a hadoop deployment (hate using cluster - seems to be a term with specific conotation in this crowd ;) ) 20:33:23 anyway, Savanna is all around about integration with various Hadoop vendors. I'm worried that splitting development into two separate project will make thing really complex. both will need integration with various Hadoop distros 20:33:30 vishy: ++ 20:33:32 vishy: I wouldn't mind trove to expand scope to support generic clustering 20:33:33 mikal - savanna is a priority for Hortonworks 20:33:36 mikal, i think the community is growing, will continue to grow and will be sustaining outside of mirantis, yes 20:33:40 and trove/heat/savanna/workflow can fight to the death about who gets to own it 20:33:50 vishy: cage match? 20:33:56 mikal: savanna has contributors from RedHat, so it could survive in any way) 20:33:58 savanna already has a lot staff for clustering anti affinity group, networks and ect. 20:33:58 vishy: otherwise everyone will keep on reinventing it 20:33:59 oh and tripleo 20:34:05 since they have to provision clusters as well 20:34:11 :o 20:34:19 lol 20:34:25 vishy, it seems like Heat is the right tool to provision cluster, others are for tight integration with software running inside VMs 20:34:25 zomg clusters 20:34:26 yeah - but that's just heat really :) 20:34:31 * hub_cap hands vishy the wrench for the meeting 20:34:33 * mordred clusters himself 20:34:41 * markwash noms on clusters of nuts 20:34:41 oh god now were all doomed 20:34:51 ruhe: +1 for clusters provisioning 20:35:00 ruhe: the issue is provisioning the vms is easy 20:35:04 wow 34min in and it's already toasted 20:35:09 ruhe, yep and we planning to digg into Heat and try to contributed missed features to it to be able to use it for provisioning in Savanna 20:35:21 ttx fwiw, i wouldnt mind expandoing scope cuz its going to be cassandra/mysql/mongo/redis/etc/etc/etc in trove 20:35:27 it is configuring the services to know about each other, do elections, etc. 20:35:27 that is hard 20:35:28 and savanna will have hadoop 20:35:34 SergeyLukjanov: good idea 20:35:38 and although the software is different there is definitely a lot of overlap in these things 20:35:42 hub_cap: + Vertica CE 20:35:44 I think big data/ map reduce use cases are really valuable, and would like to see heat orchestrating to help other projects laser focus on use cases 20:35:44 vishy, not only provision, but apply configs, for instance host names in /etc/hosts for the whole cluster 20:36:07 yes that should be the same w/ cassandra right ruhe? 20:36:18 ruhe: would wouldn't just bring up an instane running bind and point everyone to that (or something other than losts of copies of /etc/hosts?) 20:36:19 hub_cap, right 20:36:23 we plan on supporting in a generic way, cuz im sure mongo/cassandra will need 20:36:32 ruhe: imo that is part of configuring the software 20:36:32 annegentle: yes, and I wouldn't mind Savanna contributors to contribute the missing stuff they need to existing projects :) Yay cross-openstack collaboration 20:36:52 ttx: yep 20:36:55 ++ 20:37:10 vishy: ++ 20:37:14 a lot of the difficulty would be avoided if we had integrated dns and autodiscovery 20:37:21 I think there needs to be a clearer distinction here 20:37:22 * vishy has a whole bag of wrenches 20:37:33 geez you sure do 20:37:34 so basically I think there is value in incubating savanna, if only to get all those devs to show up at the design summit and see how they can best fit 20:37:43 +1 ttx 20:37:46 so um, state of clustering at the summit? 20:37:50 hup_cap: SergeyLukjanov: i see the next situation: trove support HBase/Hive - that is means that trove get Hadoop cluster provisioned via Savanna and than install Hive/Hbase on that cluster 20:37:52 vishy: huge +1 to auto discovery ... 20:37:56 hub_cap:+1 20:38:15 * ttx looks up scedhule to make sure heat/trove and savanna don't run at the same time 20:38:18 vishy: we keep inventing new methods to do that by hand, kinda getting silly 20:38:35 vishy: dns++ 20:38:37 dmakogon_, don't hurry :) HBase provisioning is the most complicated thing i ever seen in my life 20:38:42 and yes, dns++ too 20:38:48 is anyone help with dns yet? 20:38:51 I mean, getting it done right 20:38:52 (sorry, another topoic) 20:38:58 hah 20:39:00 ruhe: no way it is more complicated than configuring openstack! 20:39:05 err. trove and heat run at the same time, sigh 20:39:10 ruhe: i know, i've deployed it by hands a lot of times 20:39:14 vishy, good catch 20:39:25 ttx FAIL 20:39:27 russellb: no worries - we can talk about infinite number of things in parallel in this meeting 20:39:37 mordred: hows the weather? 20:39:51 hub_cap: great! I got some torchy's tacos yesterday and a bowl of queso 20:39:59 agreed with need to discuss where clustering part should be done 20:40:02 ttx: rework the whole scedule now! 20:40:08 on it 20:40:08 mordred, super linear scaling eh? 20:40:12 mordred: /jealous 20:40:34 yes id love to see 1 project support clustering, there is no need to reinvent 20:40:40 heat can provision a cluster with some work maybe... but some X needs to configure it and X needs to manage the lifecycle of a cluster... be it hadoop, cassandra or spark.. and I see a split between savanna and trove..... can we work towards solving that first 20:40:43 and id love to see 1 project support a data api 20:40:49 hub_cap: +1 to shared lib 20:40:55 +1 to single project 20:41:04 rnirmal +1 20:41:10 rather than shared lib w/ the same api's between 2 diff projects heh 20:41:15 i think this is shouldn't be a standalone project 20:41:28 just some algorithms 20:41:32 oh no a data api is quite valid :) 20:42:34 hub_cap: shared lib (vs. shared service) seems quite reasonable to me? 20:42:43 or heat should provision clusters for next usage in terms of current project 20:42:45 yes zaneb 20:43:36 mordred: I'll propose to swap trove and ironic on https://docs.google.com/spreadsheet/ccc?key=0AmUn0hzC1InKdDdPRXFrNjV4SW91SWF5N2gwYnRHYWc#gid=1 -- sounds like the most limited change that would solve it 20:43:44 +1 rnirmal - this is the value that Savanna adds. 20:43:47 hub_cap: shared lib ease to reuse without any integration 20:43:53 to understand requirements of such shared lib (or service) we'll need to understand requirement from both Trove and Savanna 20:43:56 ironic and heat overlap is probably rough too 20:44:16 since the folks interested in baremetal, are also interested in tripleo, which are interested in heat 20:44:21 +1 ruhe 20:44:32 russellb: there are more heat slots than ironic slots though, so they can still attend some of it 20:44:41 ttx: ah, cool, probably fine then 20:44:50 looks like no ideas for clustering discussion now and the best solution is to setup clustering discussion at design summit and apply the decision in I cycle 20:44:51 hmmm seems like we are starting to see program vs project 20:45:05 +1 SergeyLukjanov we have submitted one for trove :) 20:45:20 hub_cap: ++ 20:45:20 http://summit.openstack.org/cfp/details/54 20:45:29 SergeyLukjanov: +1 20:45:34 ttx: we should just serialize the whole thing and have the design summit never end 20:45:52 when it is over is when it begins 20:45:55 russellb: sounds like paradise 20:46:51 OK, so it would be great to start this discussion a bit this week so that we can see the premises of this collaboration by the time we finally vote on this (next week or the week after) 20:47:11 good call 20:47:28 hub_cap: SergeyLukjanov: we could discuss clustering together, it term of trove/heat/savana/ironic 20:47:31 ttx: how does the election timing and vote for incubation line up? 20:47:38 ttx: I can't remember when elections are 20:47:40 and unless someone has another concern to raise, we can go to open discussion now 20:47:43 annegentle: next topic 20:47:45 yes dmakogon_ 20:47:51 go go go ttx 20:47:58 we have another topic? jeez 20:48:05 not really 20:48:07 #topic Open discussion 20:48:12 I set up the pages for the PTL and TC elections in the next weeks: 20:48:13 we are gonna discuss mordred's hatred for open discussion 20:48:18 #link https://wiki.openstack.org/wiki/PTL_Elections_Fall_2013 20:48:22 hub_cap: SergeyLukjanov: more that +100500 for shared lib for clustering 20:48:23 #link https://wiki.openstack.org/wiki/TC_Elections_Fall_2013 20:48:33 I'm looking for volunteers for filling the election official roles, especially for the PTL election 20:48:43 Can be difficult since you should not be running for any of the PTL positions to be an PTL election official... 20:49:02 are there any other questions about savanna? (we've discussed only one not main feature of savanna…) 20:49:11 dang that's a lot of PTL positions :-) 20:49:17 elections like woah 20:49:36