hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Appy (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-15965) Shell test changes. Use @shell.command instead directly calling functions in admin.rb and other libraries.
Date Thu, 30 Jun 2016 20:46:10 GMT

    [ https://issues.apache.org/jira/browse/HBASE-15965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15357815#comment-15357815

Appy commented on HBASE-15965:

The idea here is that *interactive* are user-facing things and might change substantially
between releases to improve the user experience. See it as functionality + formatting.
In contrast, *non-interactive* are meant to be used when building scripts using hbase shell's

You should be able to get the return value using -n (non-interactive) flag.

bq. Actually I was thinking of further extending the return values to contain more information
Every change [breaks someone's workflow|https://xkcd.com/1172/]. Changing return value to
contain more information *will* break someone else's workflow (who's manually parsing shell
output). The idea above is, let's at least give users a more stable way of building on top
of shell by removing their dependency on how shell format's data.

bq. How about if we add an extra set of "query" commands (e.g. get_tables or maybe tables?)
that return values regardless of interactivity?
That approach requires duplicating classes and we over 100 commands, not good from dev perspective.
It'll be a mess from user perspective too. Imaging about 200 commands, some of which are basically
just like others. I don't feel that extra set of commands is the right way to design this
because there will be naming consistency issues, extra maintenance cost, etc. And then comes
the issue of compatibility guarantees. Ideally, stuff users use to build their own scripts
should have better compat guarantees. It's far easier to have different compat guarantees
for two different modes than different compat guarantees for different commands.
So i'd really like to not go this path.

I'm more inclined to two mode approach, because it'll make things far easier for users. If
you see a problem or a case not being handled, lets discuss it and come up with even better

> Shell test changes. Use @shell.command instead directly calling functions in admin.rb
and other libraries.
> ----------------------------------------------------------------------------------------------------------
>                 Key: HBASE-15965
>                 URL: https://issues.apache.org/jira/browse/HBASE-15965
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Appy
>            Assignee: Appy
>             Fix For: 2.0.0
>         Attachments: HBASE-15965.master.001.patch, HBASE-15965.master.002.patch, HBASE-15965.master.003.patch
> Testing by executing a command will cover the exact path users will trigger, so its better
then directly calling library functions in tests. Changing the tests to use @shell.command(:<command>,
args) to execute them like it's a command coming from shell.
> Norm change:
> Commands should print the output user would like to see, but in the end, should also
return the relevant value. This way:
> - Tests can use returned value to check that functionality works
> - Tests can capture stdout to assert particular kind of output user should see.
> - We do not print the return value in interactive mode and keep the output clean. See
Shell.command() function.
> Bugs found due to this change:
> - Uncovered bug in major_compact.rb with this approach. It was calling admin.majorCompact()
which doesn't exist but our tests didn't catch it since they directly tested admin.major_compact()
> - Enabled TestReplicationShell. If it's bad, flaky infra will take care of it.

This message was sent by Atlassian JIRA

View raw message