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 <[email protected]> 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 <[email protected]> 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)
