Re: [openstack-dev] [trove] [sahara] Adding support for HBase in Trove

[michael mccune]

On 01/08/2016 08:34 AM, Amrith Kumar wrote:

As Kevin suggests, I'm adding [sahara] to the subject line.

Others in sahara who now see this thread, apologies for sending you a delayed 
invitation to the party. There's still lots of food and beer so come on in!


Amrith,

thanks for reposting this, some of our team was on holiday during the 
last week (jan 3-8).


regards,
mike


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [trove] [sahara] Adding support for HBase in Trove

[Amrith Kumar]

As Kevin suggests, I'm adding [sahara] to the subject line. 

Others in sahara who now see this thread, apologies for sending you a delayed 
invitation to the party. There's still lots of food and beer so come on in!

-amrith

> -Original Message-
> From: Fox, Kevin M [mailto:kevin@pnnl.gov]
> Sent: Thursday, January 07, 2016 7:32 PM
> To: OpenStack Development Mailing List (not for usage questions)
> 
> Subject: Re: [openstack-dev] [trove] Adding support for HBase in Trove
> 
> While I applaud raising the issue on the mailing list to get more folks to 
> weigh
> in, I think part of the problem maybe the lack of a [sahara] tag on the 
> subject.
> The thread is still tagged to be a Trove centric conversation. All respondents
> please consider adding [sahara] to the subject.
> 
> Thanks,
> Kevin
> 
> From: Amrith Kumar [amr...@tesora.com]
> Sent: Thursday, January 07, 2016 1:59 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [trove] Adding support for HBase in Trove
> 
> > -Original Message-
> > From: michael mccune [mailto:m...@redhat.com]
> > Sent: Thursday, January 07, 2016 3:12 PM
> > To: openstack-dev@lists.openstack.org
> > Subject: Re: [openstack-dev] [trove] Adding support for HBase in Trove
> >
> > On 01/07/2016 11:59 AM, Amrith Kumar wrote:
> > >  From the things that you and Pete (Peter MacKinnon) are saying, I
> > > don't
> > understand why there is an objection to accepting the currently
> > proposed implementation which is clearly for single node deployments?
> > Both Standalone and Pseudo-Distributed are by definition, explicitly,
> > necessarily, absolutely, positively, definitely single node. I can't
> > be more explicit about that. That's all that is being proposed at this
> > time. See more comments below.
> >
> > i didn't think i explicitly objected to the spec, if it seems that way
> > then i apologize. after reading the spec and the comments, it seemed
> > that there was some question about engagement with the sahara team. i
> > wanted to help bring some light to the issues surrounding deploying
> > hbase and thought it would be good to participate in the discussion.
> 
> You are correct Michael. There was a suggestion that we should engage with
> the Sahara team (in the Trove team meeting yesterday) and that is what
> prompted this email thread. So I appreciate your participation as one who is a
> member of the Sahara team.
> 
> >
> > > Further, the current proposal also chooses an implementation
> > > strategy that
> > makes it much easier to handle fully-distributed in a different way in
> > the future. Consider this, Trove could equally well have dealt with
> > HBase using a single datastore for all operating modes. In the current
> > implementation, one would create a HBase standalone instance using a
> command that included:
> > >
> > > --datastore hbase-standalone
> > >
> > > And a pseudo-distributed instance by including
> > >
> > > --datastore hbase-pseudo-distributed.
> > >
> >
> > and this delineation sounds reasonable to me
> >
> > > Trove could equally well function by having a single datastore
> > > (hbase) but
> > this would make hbase-fully-distributed harder to do in a different
> > way in the future. I consciously eschewed that path, for this very
> > specific reason; it would limit choice in the future.
> >
> > agreed
> >
> > > Now, the implementation behind hbase-fully-distributed could be a
> > custom Trove guest agent that could (if we decided to go that route)
> > interact with Sahara. However, an alternative implementation of
> > hbase-fully- distributed could orchestrate everything natively in
> > Trove. There is much flexibility in the current proposal, and I submit
> > to you that this is being lost in your reading of the specification
> > and the current implementation as proposed.
> >
> > i don't think your characterization of my reading comprehension is fair.
> > as i stated earlier, i wanted to participate in the discussion
> > surrounding deploying a technology that sahara currently deploys.
> > fwiw, i agree with what you are saying here, but i also think it is
> > axiomatic, the trove team can choose whichever path it would like for
> implementation.
> >
> > >> 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.
> > >
> > > Why only standalone? The current proposal explicitly covers only
> > standalone and pseudo-distributed which are both valid strictly (add
> > other adjectives here to taste) single node topologies and the
> > currently submitted specification specifically carves out
> > fully-distributed operation as requiring further thought and contemplation.
> >
> > i think starting with standalone mode (and not