Open Stack

Just to reiterate, the current proposal is for standalone and pseudo-distributed only.

-amrith

> -----Original Message-----
> From: Greg Hill [mailto:greg.hill at RACKSPACE.COM]
> Sent: Thursday, January 07, 2016 1:59 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [trove] Adding support for HBase in Trove
> 
> I don't work on Sahara, but I do work on a similar closed-source project.
> FWIW, I agree with Kevin here.  standalone and pseudo-distributed HBase
> are only intended for Hbase developers to test code without having to spin
> up a cluster; it's not meant for operators or users to actually use as a
> database. Hbase is designed to run on HDFS and relies on Zookeeper for
> coordination as well. Unless trove is going to re-implement half of Sahara,
> having it there makes no sense, and will ultimately only lead to confusion
> among users who see Hbase and think they're getting something useful
> when they are in fact not.
> 
> My $0.02
> 
> Greg
> 
> On 1/7/16, 12:19 PM, "Fox, Kevin M" <Kevin.Fox at pnnl.gov> wrote:
> 
> >Oh. And I'd suggest having this conversation with the Sahara team. They
> >may have some interesting insight into the issue.
> >
> >Thanks,
> >Kevin
> >________________________________________
> >From: Fox, Kevin M
> >Sent: Thursday, January 07, 2016 9:44 AM
> >To: OpenStack Development Mailing List (not for usage questions)
> >Subject: Re: [openstack-dev] [trove] Adding support for HBase in Trove
> >
> >the whole hadoopish stack is unusual though. I suspect users often want
> >to slice and dice all the components that run together on the cluster,
> >where HBase is just one component of the shared cluster. I can totally
> >envision users walking up to my door saying, I provisioned this HBase
> >system with Trove, and now I want to run such and such job on the
> >cluster... Building on top of Sahara enables that kind of thing. If
> >trove wants to do the clustering all itself, then that's either out of
> >the picture, or you end up having to add lots of sahara like
> >functionality in the end to get its functionality back up to where users will
> want it.
> >
> >Thanks,
> >Kevin
> >________________________________________
> >From: michael mccune [msm at redhat.com]
> >Sent: Thursday, January 07, 2016 8:17 AM
> >To: openstack-dev at lists.openstack.org
> >Subject: Re: [openstack-dev] [trove] Adding support for HBase in Trove
> >
> >thanks for bringing this up Amrith,
> >
> >On 01/06/2016 07:31 PM, Fox, Kevin M wrote:
> >> Having a simple plugin that doesn't depend on all of Sahara, for the
> >>case a user only wants a single node HBase does make sense. Its much
> >>easier for an Op to support that case if thats all their users ever
> >>want. But, thats probably as far as that plugin ever should go. If you
> >>need scale up/down, etc, then your starting to reimplement large
> >>swaths of Sahara, and like the Cinder plugin for Nova, there could be
> >>a plugin that works identically to the stand alone one that converts
> >>the same api over to a Sahara compatible one. You then farm the work
> over to Sahara.
> >
> >i think this sounds reasonable, as long as we are limiting it to
> >standalone mode. if the deployments start to take on a larger scope i
> >agree it would be useful to leverage sahara for provisioning and scaling.
> >
> >as the hbase installation grows beyond the standalone mode there will
> >necessarily need to be hdfs and zookeeper support to allow for a proper
> >production deployment. this also brings up questions of allowing the
> >end-users to supply configurations for the hdfs and zookeeper
> >processes, not to mention enabling support for high availability hdfs.
> >
> >i can envision a scenario where trove could use sahara to provision and
> >manage the clusters for hbase/hdfs/zk. this does pose some questions as
> >we'd have to determine how the trove guest agent would be installed on
> >the nodes, if there will need to be custom configurations used by
> >trove, and if sahara will need to provide a plugin for bare (meaning no
> >data processing framework) hbase/hdfs/zk clusters. but, i think these
> >could be solved by either using custom images or a plugin in sahara
> >that would install the necessary agents/configurations.
> >
> >of course, this does add a layer of complexity as operators who wish
> >this type of deployment will need to have both trove and sahara, but
> >imo this would be easier than replicating the work that sahara has done
> >with these technologies.
> >
> >regards,
> >mike
> >
> >_________________________________________________________
> ______________
> >___ OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> >OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >_________________________________________________________
> ______________
> >___ OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> >OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >_________________________________________________________
> ______________
> >___ OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> >OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __________________________________________________________
> ________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev