Having two shells - a simple user shell for tinkering and an advanced one for real ops and developers - would be fine, as long as one is not deprecated. Can't trust something deprecated for tooling.
On Wed, May 13, 2015 at 10:52 AM, Esteban Gutierrez <este...@cloudera.com> wrote: > +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 <apurt...@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 <st...@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 <bus...@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) > > > -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
