hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <bus...@cloudera.com>
Subject Re: HBase shell compatibility needs
Date Thu, 14 Aug 2014 20:49:14 GMT
darn, missed the inclusion of my links about the pain around moving Ruby
1.8 -> 1.9. Also "well documented" is relative. ;)

[2]:
http://nerds.airbnb.com/upgrading-from-ree-187-to-ruby-193/
http://www.darkridge.com/~jpr5/2012/10/03/ruby-1.8.7-1.9.3-migration/


On Thu, Aug 14, 2014 at 3: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.
>
>
>
>>
>> > 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.
>
>
>
>> >
>> > 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'm having trouble thinking of an example of a product with a
> non-procedural user facing shell.
>
> --
> Sean
>



-- 
Sean

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