New Documentation of Petals CLI-Command Line Interface

compared with
Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (59)

View Page History
h1. Usage of Petals CLI

{color:red}A revoir (après discussion){color}
{color:red}Needs to be updated{color}

{code}
{code}

-This command is wrapped by another shell: petals-cli-console.sh.- As it is not more usable than the option '-C' on command line, the wrapper script is removed. On Linux, a shell alias can be defined.
On Windows, this command is wrapped by another shell: petals-cli-console.bat.
On Linux, there is no wrapper script but a shell alias can be created.

h3. Execution of a Petals CLI command directly on the command line
h3. Execution of a Petals script file

Launching Petals CLI with the following command line executes the commands of a from the specified Petals script.
{code}
> ./petals-cli.sh <filename>
h3. Execution of an inlined Petals script

{color:red}Pas clair. Expliciter un peu mieux.{color}

Launching Petals CLI with the following command line executes commands provided through the standard input ("stdin").


The list of available commands is available by using the command '{{help}}' without argument.
The help on a command can be get using the command '{{help}}'. A usage and a description of the command is displayed.
Help about a command is available by using the '{{help}}' command. Command's usage and description are then displayed.
{code}> ./petals-cli.sh -C

h2. Getting the version of Petals CLI

To get the version of Petals CLI, the version of the JVM running Petals CLI, and its operating system, use the '-V' option '-V':
{code}
> ./petals-cli.sh -V
* Petals CLI is interrupted with the return code 2.

h3. Error management of a command entered in interactive mode

If an error occurs during the execution of a command entered in interactive mode:
\\
Note:
* The return values of command {{isParsingErrorReturned}}, {{isExecutionErrorReturned}} and {{isNoErrorReturned}} are re-intialized reset when invoking another command. Only the error of the last command execution can be checked.
* The attribute {{lastErrorCode}} is an argument of the command {{exit}} to return the return code of the last executed command.

h2. Exit from the 'console' mode

To exit the 'console' mode, use the command '{{{*}exit{*}}}' command. If a number is set as an argument, it is used as a return code otherwise, code. Otherwise, the return code 0 is used.
{code}
> ./petals-cli.sh -C
> ./petals-cli.sh -h <host> -n <port> -u <user> -p <password> -c <command>
> ./petals-cli.sh -h <host> -n <port> -u <user> -p <password> -C
Conected on <host1>:<port1> with <user1>
petals-cli@<host1>:<port1>>
{code}

h2. Interacting with several Petals nodes without exiting Petals CLI

In interactive mode or script mode, we should be able to close a connection and open another one without leaving Petals CLI. This is done by commands achieved with the '{{{*}connect{*}}}' and '{{{*}disconnect{*}}}' commands. If no arguments are argument is set on command 'connect', the 'connect' command, default values are used. These default values are specified in a properties file located in the Petals CLI directory. The default values defined in this properties file are (localhost:7700, login=petals, pwd=petals).

{code}
petals-cli> disconnect
petals-cli> connect
petals-cli> Would you like to connect to <default-user>:*****@<default-host>:<-default-port>? (y/n)
y
Connected on <default-host>:<-default-port> with '<default-user>'
petals-cli@<default-host>:<default-port>>
{code}


By default (if no argument or option is set):
- In 'console' mode, the connection is established on command '{{{*}connect{*}}}' to the values defined in the properties file that define the preferences (localhost:7700 with credentials 'petals/petals').
- In 'console' mode, the connection is established on command '{{{*}connect{*}}}' to the values given in the preferences file.
{code}
> ./petals-cli.sh -C
------------------------------------------------------------------------------
petals-cli> connect
petals-cli> Would you like to connect to <default-user>:*****@<default-host>:<-default-port>? (y/n)
y
Connected on <default-host>:<-default-port> with '<default-user>'
petals-cli@<default-host>:<default-port>>
{code}

- In 'command line' mode, if no argument or option is set, a connection is established to the values defined in the properties file that define the preferences (localhost:7700 with credentials 'petals/petals').
- The confirmation can be skipped by adding the "yes" argument to the command.
{code}
> ./petals-cli.sh -C

Type 'help' for help.
------------------------------------------------------------------------------
petals-cli> connect -y
petals-cli@<default-host>:<default-port>>
{code}

- In 'command line' mode, if no argument or option is set, a connection is established to the values defined in the preferences file.

{code}
> ./petals-cli.sh -c stop
{code}
{tip}It's needed to stop easily a local container{tip}
{tip}This is necessary to easily stop a local container{tip}
- In mode 'script' mode, the connexion connection is establish on command 'connect' to <default-host>:<-default-port> with credentials '<default-user>/<default-pwd>'.
{code}
> ./petals-cli.sh - << EOF
h2. Security

For security reasons, a Petals CLI user may decide that there should be a no default connection.
In that case, he may decide to delete the preference file, so that any user will have to type in the right information.
If the preference (properties file) does not exist, Petals CLI displays an error message.
petals-cli> Username: right-username
petals-cli> Password: right-pwd
Connected on <default-host>:<-default-port> with '<right-username>'
petals-cli@<default-host>:<-default-port>>
{code}

* {{<configuration-properties>}} is a list of '{{<property-name>=<property-value>}}', separated by a space, where {{<property-name>}} is the name of the property to configure with {{<property-value>}}. This argument is used only if the artifact is a component. It has no sense for other artifacts. This argument is exclusive with {{<configuration-file>}}.

\\
{tip}Auto-completion is available on artifacts IDs and artifact file names.{tip}

h3. Installation/Deployment of an artifact located into a Maven repository

* {{<artifact-id>}} is the JBI identifier of the artifact to start.

\\
{tip}Auto-completion is available on artifacts IDs and artifact file names.{tip}

h3. Stopping an artifact

* {{<artifact-id>}} is the JBI identifier of the artifact to stop.

\\
{tip}Auto-completion is available on artifacts IDs and artifact file names.{tip}

h3. Uninstallation/Undeployment and stop of an artifact in one command

* {{<artifact-id>}} is the JBI identifier of the artifact to undeploy.

{note}Add feature to remove artifact by name{note}
\\
{tip}Auto-completion is available on artifacts IDs and artifact file names.{tip}

h3. Uninstallation/Undeployment and stop in mass
* Its type (SL, BC, SE, SA, SU).

h3. Getting information on about an artifact

Information about a JBI artifact can be got by using the command '{{{*}show{*}}}':
*** Its target component ((displayed using its JBI identifier)

* For a service unit:
** Its JBI identifier
** Its version, if available
** Its target component ((displayed using its JBI identifier)
\\
{tip}Auto-completion is available on artifacts IDs and artifact file names.{tip}

h3. Interrupting a flow of commands
{code}
> ./petals-cli.sh -c stop container --shutdown
Are you sure you want to shutdown the container (Y/n) ? container? (y/n)
{code}
A confirmation is expected, except if the flag 'yes' is set on the command line. A confirmation message is displayed in the mode 'console', except is the flag 'yes' is set on the command line.

h3. Getting the topology

When connected to a container, it is possible to get information about the topology this node is part of.

{code}
petals-cli@host:port> topology-list
Domain: Domain 1
Subdomain: SubDomain 1
* Node1
** information

* Node2
** information

Subdomain: SubDomain 2
...
{code}

This command shows a set of Petals nodes, sorted by domain and sub-domains, each node having the following information:
* Container name
* Node type (master or slave)
* Host
* Node ports

h3. Getting the server properties

When connected to a container, it is possible to get all the values defined in the *server.properties* file.

{code}
petals-cli@host:port> properties-list
Key1: value1
Key2: value2
...
{code}
where "key1" and "value1" are the keys and values defined in the *server.properties* file of this container.

h3. Changing logger levels

On a container, it is possible to change the level of a logger.
{code}
petals-cli@host:port> logger-set <logger-name> <level>
logger1
logger2
...
{code}

To get all the available loggers, use loggers without any argument.
{code}
petals-cli@host:port> loggers
logger1
logger2
...
{code}

You can also use a regular expression to filter the candiate results.
{code}
petals-cli@host:port> loggers <regular expression>
logger1
logger2
...
{code}

{tip}Auto-completion is available on logger names.{tip}

h2. Working with the Service Registry

{note}Qualified names, like service and interface names, are written as follows:\{namespace-uri\}local-part.{note}

h3. Synchronizing the registry

A synchronization of the registry on all nodes of the Petals topology a specific node can be done with the command '{{{*}registry-sync{*}}}':
{code}
> ./petals-cli.sh -c registry-sync
> registry-sync
Synchronization is done
{code}

A synchronization of all the topology nodes can be done with the same command and the *--all* argument.
{code}
> registry-sync --all
<Progress Report (as a percentage)>
Synchronization is done
{code}

{note}Global synchronization is done in two passes:
* Each slave declares its end-points to the master node (n-1 synchronizations, where n is the number of nodes in the topology).
* Each slave gets the master end-points (start from the n-2 nodes until we get back to the first slave).
{note}

The response message is displayed in 'console' mode only.

* <endpoints-list> is the list of endpoint name implementing the interface or service.

{note}VZ: pas très clair.

* ITF
** SRV (implémentant cette interface)
*** EDPT (implémentant ce service) : caractéristiques
{note}

h3. Filtering the registry's full content by endpoint

The content of the registry related to an endpoint can be dumped by using the command '{{{*}registry-list{*}}}':
{code}
./petals-cli.sh -c registry-list endpoint <endpoint-name-regexp>
Endpoints:
<endpoint-name>: <endpoint-characteristics>

where:
* <endpoint-name-regexp> is a regular expression used as filter on the full end-point name.
* <endpoint-name> is the endpoint name used as filter.
* <endpoint-characteristics> is the attributes of the endpoint, separated by comma: container identifier, component identifier, endpoint type.
* <service-name-x> is the services associated to the specified endpoint.
* <interface-name-x> is the interfaces names associated to with the specified endpoint.

h3. Filtering the registry's full content by service
The content of the registry related to a service can be dumped by using the command '{{{*}registry-list{*}}}':
{code}
./petals-cli.sh -c registry-list service <service-name-regexp>
Endpoints:
<endpoint-name-1>: <endpoint-1-characteristics>
* <endpoint-name-x> are the endpoint names implementing the service.
* <endpoint-x-characteristics> is the attributes of the endpoint, separated by comma: container identifier, component identifier, endpoint type.
* <service-name-regexp> is a regular expression used as a filter on the full service name.
* <service-name> is the service full-name used as filter.
* <interface-name-x> are the interfaces of the service.
* <endpoints-list> is the list of endpoint name implementing the interface or service.
The content of the registry related to an interface can be dumped by using the command '{{{*}registry-list{*}}}':
{code}
./petals-cli.sh -c registry-list interface <interface-name-regexp>
Endpoints:
<endpoint-name-1>: <endpoint-1-characteristics>
* <endpoint-x-characteristics> is the attributes of the endpoint, separated by comma: container identifier, component identifier, endpoint type.
* <service-name-x> are the service names implementing the interface.
* <interface-name> is the interface full-name used as filter.
* <interface-name-regexp> is a regular expression used as a filter on the full interface name.
* <endpoints-list> is the list of endpoint name implementing the interface or service.

{note}Même remarque que plus haut sur la clarté de la réponse.{note}

{note}Serait-il intéressant de pouvoir faire du requêtage ?
registry-list query srv=toto&itf=getClient
registry-list query itf=get%Client

% = wildcard
{note}