Bug 1006347 - Deprecate rhqserver scripts
Summary: Deprecate rhqserver scripts
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Launch Scripts
Version: JON 3.1.2
Hardware: All
OS: All
unspecified
high
Target Milestone: ER04
: JON 3.2.0
Assignee: Jay Shaughnessy
QA Contact: Mike Foley
URL:
Whiteboard:
: 1002221 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-10 13:21 UTC by Larry O'Leary
Modified: 2014-01-02 20:38 UTC (History)
8 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: Task
Embargoed:


Attachments (Terms of Use)

Description Larry O'Leary 2013-09-10 13:21:06 UTC
Description of problem:
Due to the differences between what the old rhqserver script did and the new rhqctl script does and how its use will vary depending on the installed environment, we need to deprecate the existing rhqserver scripts in the following way:

 1. The script should report an error indicating it has been deprecated and is no longer used.
 2. The script should display information on how to do the equivalent command(s) using the new rhqctl script.
 3. The script should return a non-zero error code to indicate a failure to any scripts or processes that may invoke it directly.

Comment 1 John Mazzitelli 2013-09-13 14:51:48 UTC
we still use the other scripts (rhq-server.sh, rhq-installer.sh). Its just that rhqctl wraps them. In fact, developers still do use rhq-server.sh (at least I do).

However, what we should do is MOVE the old scripts to a location that doesn't confuse the users. For example, we discussed moving them to some subdirectory inside bin/ so the users don't see a cluttered bin/ directory with scripts that they probably don't need to use. somethign like "bin/internal". rhqctl and the underlying Java code it uses need to change to know to point to the new location for the scripts.

Comment 2 John Mazzitelli 2013-09-13 15:10:36 UTC
OK, I think I know what you are talking about. I think we can leave rhq-server.sh and rhq-installer.sh in the /bin directory but have it do as you say - report errors and all that.

BUT have rhqctl code not even use those. It should call scripts in bin/internal.

this way, people still using bin/rhq-server.sh or bin/rhq-installer.sh will be told that these are no longer used. But it doesn't matter to rhqctl because it doesn't even call those scripts - its calling scripts in bin/internal.

Comment 3 John Mazzitelli 2013-09-13 21:14:25 UTC
this is going to suck when it comes to upgrading, because now we have to check "if old server is 4.9, the scripts are in bin/ - otherwise, they are in bin/internal"

This is going to require some good upgrade testing to make sure nothing breaks.

Comment 4 Larry O'Leary 2013-09-13 23:11:58 UTC
Are you saying that upgrading is copying scripts from the old install to the new?

Comment 5 Jay Shaughnessy 2013-09-19 17:46:50 UTC
*** Bug 1002221 has been marked as a duplicate of this bug. ***

Comment 6 John Mazzitelli 2013-09-19 21:13:51 UTC
git master commit: 3ef6782

Most scripts are now in bin/internal. The original scripts in bin/ are now obsolete ones that only spit out errors to tell people to use rhqctl instead now.

This commit also fixed some problems with upgrading from RHQ 4.9.

Comment 7 John Sanda 2013-09-20 02:13:08 UTC
Why are we leaving copies of original scripts in the bin the directory? That just seems like another source of confusion.

Comment 8 Heiko W. Rupp 2013-09-20 07:49:55 UTC
(In reply to John Sanda from comment #7)
> Why are we leaving copies of original scripts in the bin the directory? That
> just seems like another source of confusion.

Ideally they should print the new command and "exit 1" so that the user knows what they would need to use instead. The exit code of 1 indicates that an error occurred and the user needs to look into it (e.g. when rhq-server.sh was copied to /etc/init.d to be used at system startup).

I am reopening to add these usage hints.
Target mile stone is er2 for now.

Comment 9 Simeon Pinder 2013-09-30 13:36:51 UTC
Moving into ER3 as didn't make it into ER2.

Comment 10 Jay Shaughnessy 2013-10-01 20:47:30 UTC
Currently the scripts do return exit code of 1, and print:

  This script is obsolete and no longer used.  Use rhqctl instead.

I guess I don't understand what it is you are looking for past this?  We could be a little more verbose, I suppose. Maybe like:

  This script has been replaced by rhqctl.  For help on the new command try:

     rhqctl --help

  Or visit the documentation at:

     https://docs.jboss.org/author/display/RHQ/RHQ+Control+Script


-----------------------------------------------------------------------

Is that what you are looking for?  If you are implying we need to translate the old command into a new command.  I don't think that is worthwhile.

Comment 11 John Mazzitelli 2013-10-01 20:56:57 UTC
(In reply to Jay Shaughnessy from comment #10)
> Currently the scripts do return exit code of 1, and print:
> 
>   This script is obsolete and no longer used.  Use rhqctl instead.
> 
> I guess I don't understand what it is you are looking for past this?  We
> could be a little more verbose, I suppose. Maybe like:
> 
>   This script has been replaced by rhqctl.  For help on the new command try:
> 
>      rhqctl --help
> 
>   Or visit the documentation at:
> 
>      https://docs.jboss.org/author/display/RHQ/RHQ+Control+Script
> 
> 
> -----------------------------------------------------------------------
> 
> Is that what you are looking for?  If you are implying we need to translate
> the old command into a new command.  I don't think that is worthwhile.

Do NOT put doc links in the output. That just causes pain in the JON builds because now we'd have to re-brand the scripts by altering them via JON build scripts to point to the JON doc URL as opposed to the RHQ doc URL.

I like the "see rhqctl --help for more" - that could be useful.

Comment 12 Larry O'Leary 2013-10-01 23:19:11 UTC
From comment #0:

> 2. The script should display information on how to do the equivalent command(s) using the new rhqctl script.

The intention is to quickly provide the user with the next step(s). I think this might be sufficient:

> This script has been replaced by rhqctl.  For help on the new command try:
> 
>      rhqctl --help


This takes care of 2. As mentioned, the old script also returns error code 1 which takes care of 3. The remaining question (1.) is does it report an error to stderr or not? 

For example:

echo >&2 "ERROR: $0 has been replaced by rhqctl."
cat <<EOF
Please use rhqctl. For help on the new command try:

    rhqctl --help
EOF

This will allow the error to be seen on the console in the event that stdout is being redirected to a file and prevent redundancy in the event that stdout and stderr go to the same place.

Comment 13 Thomas Heute 2013-10-03 12:03:09 UTC
I don't see a reason to block the release because of this.
The solution is similar to EAP's solution (granted that EAP doesn't have installer command, just a run command and a bit more verbose). 

While I understand the concerns I actually think we should close and move on.

Comment 14 Simeon Pinder 2013-10-08 07:52:47 UTC
Moving into ER04 as not completed in ER03.

Comment 15 Jay Shaughnessy 2013-10-10 15:22:32 UTC
master commit bf886d871f336211846d4852032f089a54b0b6c7
    - updated scripts with better messaging
    - updated .sh scripts with better handling of stderr

release/jon3.2.x cherry pick commit 8e38e7d87f95b0f7a26f197ee2d7eac15315e33b

Comment 16 Simeon Pinder 2013-10-24 04:09:59 UTC
Moving to ON_QA for testing in the next build.

Comment 17 Sunil Kondkar 2013-11-06 10:11:29 UTC
Verified on Version: 3.2.0.ER4 Build Number: e413566:057b211

Running the scripts (rhq-server.sh and rhq-installer.sh) display below in the console:

ERROR: ./rhq-server.sh has been replaced by rhqctl.
Please use rhqctl. For help on the new command try:

    rhqctl --help
[root@sunillaptop bin]# ./rhq-installer.sh --help
ERROR: ./rhq-installer.sh has been replaced by rhqctl.
Please use rhqctl. For help on the new command try:

    rhqctl --help
[root@sunillaptop bin]#


Note You need to log in before you can comment on or make changes to this bug.