hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Esteban Gutierrez <este...@cloudera.com>
Subject Re: Ruby shell versions for HBase 2.0
Date Wed, 13 May 2015 17:52:05 GMT
+1 for new JRuby for now and having a JIRA to discuss what features should
this shell have would be great.

However, I think that during the last few years many of us have used the
hbase shell for major surgery as Andrew said and it has added some
confusion to users about what the hbase shell is used for and I think that
functionality shouldn't be longer exposed to regular users. One way we
could probably do this is to have a user facing CLI that will be more for
DDL, permissions and data interaction for users (sort of psql or phoenix
/me runs too) and deprecate/update the old shell just leaving table/region
management functionality for admins, also since most of advanced scripting
is done by interacting with Admin directly (see region_mover.rb or
copy_tables_desc.rb) I don't think we should worry too much about backwards
compatibility if that gets properly documented.

thanks,
esteban.



--
Cloudera, Inc.


On Wed, May 13, 2015 at 10:25 AM, Andrew Purtell <apurtell@apache.org>
wrote:

> I'd be curious to hear proposals for a new shell. Wondering what the
> arguments in favor would be and arguments against current.
>
> JRuby has served us well. Recently it personally saved me hassle by
> allowing scripted surgery (advanced ops) rather than dev of a one off Java
> utility. OTOH, if what we had available for scripting was the Nashorn JS
> engine (Java 8+) instead, that would have worked well also.
>
> And if we're talking about new shells, what about a SQL shell? /me ducks
> and runs for cover
>
>
> On Wed, May 13, 2015 at 10:19 AM, Stack <stack@duboce.net> wrote:
>
> > Nice writeup Sean.
> >
> > Yeah, +1 to new jruby in hbase 2.0. We'd need to be careful license is
> > still amenable and hopefully jruby 9k will be slimmer than jruby 1.7+.
> >
> > But if we are going to do a significant shell refactor for hbase 2.0,
> > should we consider doing something more radical; e.g. a new shell? If
> > interest, could start up a new thread so don't distract from this one.
> >
> > St.Ack
> >
> >
> >
> >
> > On Wed, May 13, 2015 at 9:22 AM, Sean Busbey <busbey@cloudera.com>
> wrote:
> >
> > > Hi folks!
> > >
> > > If you weren't aware, our current shell relies on Ruby, specifically
> the
> > > REPL program IRB from JRuby. When we launched 1.0 we were on JRuby 1.6
> > with
> > > defaults, which means we're stuck on Ruby 1.8.
> > >
> > > For those that don't already know, Ruby 1.8 is super old and has been
> > > walking off into the sunset for a few years now. Most (but not all!)
> > formal
> > > support systems for running Ruby have EOLed 1.8 and there are numerous
> > > known issues with it.
> > >
> > > Right now there's an open ticket to get us on JRuby 1.7 so that our
> shell
> > > can work on PPC systems[1]. That version of JRuby defaults to Ruby 1.9
> > but
> > > can be run in Ruby 1.8 mode. There are some implementation details
> > > outstanding, but I'm hoping that ticket can work out such that it can
> > land
> > > in branch-1.
> > >
> > > For HBase 2.0, I'd like us to plan for a little farther out in the
> future
> > > than just updating to Ruby 1.9 (though that would be a fine incremental
> > > step with some non-trivial work attached). The "current" version of
> Ruby
> > is
> > > 2.2. Much like the move from 1.8 -> 1.9 it is not backwards compatible.
> > >
> > > JRuby's next major maintenance release line is "version 9000"[2] and it
> > > will start out *only* supporting Ruby 2.2. Right now JRuby 9000 is in
> its
> > > second "preview" release. They still have a few feature complete items
> to
> > > address before they hit their first GA release.
> > >
> > > I'd like us to move to Ruby 2.2 via JRuby 9000 for HBase 2.0.  This
> will
> > > cause operator pain to folks with advanced scripts based on Ruby 1.8,
> but
> > > it should allow us to update versions to avoid e.g. perf, correctness,
> > and
> > > security issues much more easily over the lifetime of 2.0.
> > >
> > > What do folks think? Would JRuby 9000 need to hit a GA release prior to
> > > HBase 2.0 getting released for us to adopt it? Or would it only need
> > enough
> > > of Ruby 2.2 to run our current shell?
> > >
> > >
> > > [1]: https://issues.apache.org/jira/browse/HBASE-13338
> > > [2]: http://www.slideshare.net/CharlesNutter/over-9000-jruby-in-2015
> > >
> > > --
> > > Sean
> > >
> >
>
>
>
> --
> Best regards,
>
>    - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>

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