<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 13, 2013 at 7:26 PM, Michael Basnight <span dir="ltr"><<a href="mailto:mbasnight@gmail.com" target="_blank">mbasnight@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>On Sep 13, 2013, at 6:56 AM, Alexander Kuznetsov wrote:<br>


> On Thu, Sep 12, 2013 at 7:30 PM, Michael Basnight <<a href="mailto:mbasnight@gmail.com" target="_blank">mbasnight@gmail.com</a>> wrote:<br>
> On Sep 12, 2013, at 2:39 AM, Thierry Carrez wrote:<br>
><br>
> > Sergey Lukjanov wrote:<br>
> ><br>
> >> [...]<br>
> >> As you can see, resources provisioning is just one of the features and the implementation details are not critical for overall architecture. It performs only the first step of the cluster setup. We’ve been considering Heat for a while, but ended up direct API calls in favor of speed and simplicity. Going forward Heat integration will be done by implementing extension mechanism [3] and [4] as part of Icehouse release.<br>


> >><br>
> >> The next part, Hadoop cluster configuration, already extensible and we have several plugins - Vanilla, Hortonworks Data Platform and Cloudera plugin started too. This allow to unify management of different Hadoop distributions under single control plane. The plugins are responsible for correct Hadoop ecosystem configuration at already provisioned resources and use different Hadoop management tools like Ambari to setup and configure all cluster  services, so, there are no actual provisioning configs on Savanna side in this case. Savanna and its plugins encapsulate the knowledge of Hadoop internals and default configuration for Hadoop services.<br>


> ><br>
> > My main gripe with Savanna is that it combines (in its upcoming release)<br>
> > what sounds like to me two very different services: Hadoop cluster<br>
> > provisioning service (like what Trove does for databases) and a<br>
> > MapReduce+ data API service (like what Marconi does for queues).<br>
> ><br>
> > Making it part of the same project (rather than two separate projects,<br>
> > potentially sharing the same program) make discussions about shifting<br>
> > some of its clustering ability to another library/project more complex<br>
> > than they should be (see below).<br>
> ><br>
> > Could you explain the benefit of having them within the same service,<br>
> > rather than two services with one consuming the other ?<br>
><br>
> And for the record, i dont think that Trove is the perfect fit for it today. We are still working on a clustering API. But when we create it, i would love the Savanna team's input, so we can try to make a pluggable API thats usable for people who want MySQL or Cassandra or even Hadoop. Im less a fan of a clustering library, because in the end, we will both have API calls like POST /clusters, GET /clusters, and there will be API duplication between the projects.<br>


><br>
> I think that Cluster API (if it would be created) will be helpful not only for Trove and Savanna.  NoSQL, RDBMS and Hadoop are not unique software which can be clustered. What about different kind of messaging solutions like RabbitMQ, ActiveMQ or J2EE containers like JBoss, Weblogic and WebSphere, which often are installed in clustered mode. Messaging, databases, J2EE containers and Hadoop have their own management cycle. It will be confusing to make Cluster API a part of Trove which has different mission - database management and provisioning.<br>


<br>
</div>Are you suggesting a 3rd program, cluster as a service? Trove is trying to target a generic enough™ API to tackle different technologies with plugins or some sort of extensions. This will include a scheduler to determine rack awareness. Even if we decide that both Savanna and Trove need their own API for building clusters, I still want to understand what makes the Savanna API and implementation different, and how Trove can build an API/system that can encompass multiple datastore technologies. So regardless of how this shakes out, I would urge you to go to the Trove clustering summit session [1] so we can share ideas.<br>


<br></blockquote><div>Generic enough™ API shouldn't contain a database specific calls like backups and restore (already in Trove).  Why we need a backup and restore operations for J2EE or messaging solutions? </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
[1] <a href="http://summit.openstack.org/cfp/details/54" target="_blank">http://summit.openstack.org/cfp/details/54</a><br>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>