hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Hsieh <...@cloudera.com>
Subject Re: HBase shell compatibility needs
Date Mon, 18 Aug 2014 20:14:48 GMT
On Thu, Aug 14, 2014 at 1:44 PM, Sean Busbey <busbey@cloudera.com> wrote:

> Responses inline
>
>
> On Thu, Aug 14, 2014 at 3:16 PM, Jonathan Hsieh <jon@cloudera.com> wrote:
>
> > I've always found working with the jruby part of the hbase shell jarring
> > because many of the hbase commands don't interact "natively" with jruby
> > constructs.  Some work was done [1] [2] to make it a little better but it
> > is in that uncanny half-there half-not-there state.
> >
> >
> Yes, the tension caused by both trying to be a shell specific to HBase and
> IRB is part of what I'd like to get rid of.
>
> >  On Thu, Aug 14, 2014 at 11:53 AM, Sean Busbey <busbey@cloudera.com>
> > wrote:
> >
> > > Hiya Folks!
> > >
> > > Right now, the HBase shell relies on an old version of JRuby (1.6, last
> > > released ~2 years ago) and a very old version of Ruby (1.8).
> > >
> > > I'd like to start working towards refactoring the shell. Updating some
> of
> > > our underlying libraries will make it easier to fix up some of our low
> > > hanging improvements (start up latency, utf8 support).
> > >
> > > This got me wondering about what the bounds of changing are (esp for
> > > master).
> > >
> > > 1) How common is making use of the fact that our shell is actually and
> > IRB
> > > session? Do we want to keep encouraging that for users? Could we change
> > the
> > > focus of the IRB version to be developers of HBase? Could we just make
> a
> > > HBase client gem and provide instructions for using it in IRB?
> > >
> > >
> > Most admin work and much "repair" work happens in the shell.
> >
> > If a gem makes it super easy for folks to get started with hbase that
> > sounds good.  It does seem we'd need to haev a gem for each major
> version's
> > shelll to maintain compatibility if the gem is hosted separately from the
> > hbase release though, no?
> >
> >
> We could publish the gem as a part of our release process. Avro does this
> now for its Ruby support.
>
> We could also have a copy of the gem included in our binary release
> somewhere for local installs.
>
> fine by me.  I'm not familiar with ruby's community conventions.

>
>
> >
> > > 2) However extensive our keeping IRB is, do we need to keep the same
> Ruby
> > > compatibility? Spanning Ruby 1.8 and 1.9 is a pain, but possible. (I
> know
> > > very few people still using 1.8 though) When Ruby 2 support lands
> > > supporting either of those won't be possible, because at that point
> JRuby
> > > will only support Ruby 2.1[1].
> > >
> >
> > I have a slight preference for keeping modern.
> >
>
> Me too, but what does that mean for backports?
>
> Ruby 1.9 to 2.1 updates are supposedly smooth, but that's cold comfort to
> the ops person who discovers they have to update their hbase maintenance
> scripts because they land in a corner case.
>
> Ruby 1.8 -> later updates will be more painful. The pain is well
> documented[2], but only particularly relevant if people are relying on the
> "run a ruby script" functionality.
>
>
Maybe we just do this for hbase master/v2.0?


>
>
> > >
> > > 4) Lacking #2, what do we want to ensure keeps working the same?
> Existing
> > > shell commands in the exact form they have now? Table variables (as
> > opposed
> > > to setting a "current table" context for the shell session)?
> > >
> > > I have a preference for a more ruby-esque and more oo style of api for
> > the
> > shell.  Today it is a frankenshell that is partially oo ruby style, and
> > partially procedural sql-shell-style.  I'd even consider a new "user
> shell"
> > that is parallel to the current "hacker" shell, with the goal
> marginalizing
> > the current shell for low level repair work.
> >
> >
> >
> So the oo-style shell would be the "hacker shell" and the "user shell"
> would be a more traditional procedural shell? Or do you mean the reverse?
>
> i was thinking "hacker shell" is what we have today.  The ruby-esque
oo-style shell would be the "user/dbashell".

I can see  how making the ruby one the hacker shell makes sense as well --
you're in favor of the a ruby-esque hacker shell and a stripped down
procedural-style dba shell?


> I'm having trouble thinking of an example of a product with a
> non-procedural user facing shell.
>
> As a programmer I want a hacker shell. As a person supporting hbase I want
a dba shell that does not allow the user/dba to do anything except for what
we've explicitly allowed them to do.


> --
> Sean
>



-- 
// Jonathan Hsieh (shay)
// HBase Tech Lead, Software Engineer, Cloudera
// jon@cloudera.com // @jmhsieh

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message