On Thu, Aug 14, 2014 at 1:44 PM, Sean Busbey <bus...@cloudera.com> wrote:
> Responses inline > > > On Thu, Aug 14, 2014 at 3:16 PM, Jonathan Hsieh <j...@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 <bus...@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 // j...@cloudera.com // @jmhsieh
