r63 - 19 Feb 2010 - 16:03:37 - BeckyHYou are here: Wiki >

AppLogic 2.7/2.8 Documentation The latest production release is AppLogic 3.0.30

Application Control and Management Commands

The following commands are supported:

Command	Description
`list`	List applications
`info`	Retrieve application information
`create`	Create application
`destroy`	Destroy application
`rename`	Rename application
`copy`	Copy application
`config`	Configure application
`start`	Start application
`stop`	Stop application
`continue`	Continue starting application
`restart`	Restart application
`build`	Build application
`clean`	Clean application
`repair`	Repair application
`login`	Log into application
`export`	Export application
`import`	Import application
`migrate`	Migrate application
`provision`	Provision application
`get_desc`	Display application package descriptor
`put_desc`	Modify application package descriptor
`lock`	Lock application
`unlock`	Unlock application

list

Description:	List applications
Syntax:	`application list` [ `--active` ] [ `--template` ] [ `--batch` ] [ `--verbose` ]
Arguments:	`--active`	List only active (i.e., running) applications
	`--template`	List only template applications.
	`--batch`	Display output in UDL format.
	`--verbose`	Include application ID and description in output.
Examples:	`application list` - List all applications with their descriptions
Notes:	A specification of the output of this command can be found here.

Typical Output

   Name                State     Template
   -----------------------------------------
   BackupHelper_r1     stopped   yes
   LampCluster_r6      stopped   yes
   Lamp_r2             stopped   yes
   LampX4_r2           stopped   yes
   MigHelper           stopped   yes
   SugarCRM_r2         stopped   yes
   Sys_Filer_Linux     stopped   yes
   Sys_Filer_Solaris   stopped   yes
   Sys_Filer_Windows   stopped   yes
   TWiki_r2            stopped   yes
   VDS_CentOS50_r3     stopped   yes
   VDS_CentOS51_r3     stopped   yes
   VDS_Win03_r2        stopped   yes
   VDS64_CentOS50_r3   stopped   yes
   VDS64_OSOL_r2       stopped   yes

info

Description:	Display application information
Syntax:	`application info` `name` [ `--batch` ] [ `--verbose` ]
Arguments:	`name`	Name of application for which to display information
	`--verbose`	Include detailed information for each component
	`--batch`	Display output in UDL format
Examples:	`application info sugarcrm` - Display information for application 'sugarcrm'
Notes:	A specification of the output of this command can be found here.

Typical Output

Name                    : SugarCRM_r4
Description             : Fully featured, scalable CRM Application, based on SugarCRM's Sugar Open Source 4.0.1 (v4.0.1d-11)
ID                      : 2
Documentation URL       : http://doc.3tera.net/AppLogic27/RefAppsSugarCRM.html
Template                : yes
Locked                  : no
User1                   :
User2                   :
Destroy on Stop         : no
State                   : stopped
CPU                     : 1.65
Memory                  : 2.25 GB
Bandwidth               : 2050 Mbps
Default Login Appliance :

create

Description:	Create an application
Syntax:	`application create` `name`
Arguments:	`name`	Name of application to create
Examples:	`application create sugarcrm` - Create application 'sugarcrm'
Notes:	This command will fail if there is already an application installed with the same name. The result of this command is that a directory is created for the application under the AppLogic/apps directory and template binding and application descriptors are created.

destroy

Description:	Destroy an application
Syntax:	`application destroy` `name` [ `--force` ]
Arguments:	`name`	Name of application to destroy
	`--force`	Do not ask the user anything
Examples:	`application destroy sugarcrm` - Destroy application 'sugarcrm'
Notes:	If the application is running, this command will fail.
	If the `--force` option is not specified, the user is asked if he really wants to destroy the application. The result of this command is: All volumes, component descriptors, and application descriptor are deleted. The application directory under the AppLogic/apps directory is also deleted.

rename

Description:	Rename an application
Syntax:	`application rename` `name` `new-name`
Arguments:	`name`	Name of application to rename
	`new-name`	New name of application
Examples:	`application rename sugarcrm sugarnew` - Rename application 'sugarcrm' to 'surgarnew'
Notes:	This command will fail if the application is currently running or if there is already an application installed as `new-name`.

copy

Description:	Copy an application
Syntax:	`application copy` `name` `new-name` [`--fscpy` [`--prefill`]]
Arguments:	`name`	Name of application to copy
	`new-name`	New name of application
	`--fscpy`	Copy volumes using filesystem-level copy rather than block-level copy. This is useful if the application contains a large volume that has little data stored on it.
	`--prefill`	Allocate ALL blocks of the volume.
Examples:	`application copy sugarcrm sugarnew` - Copy application 'sugarcrm' to 'surgarnew'
Notes:	Copy is like `export` + `import` with no intermediate packaged storage. This command will fail if the application is currently running or if there is already an application installed as `new-name`.

config

Description:	Configure an application
Syntax:	`application config` `name` [`--batch`]
	`application config` `name` `--boundary`
	`application config` `name` [`--reset` ] [ `prop>=val`]* [`--d` `prop`]* [ `--partial` ] [`--verify` ]
	`application config` `name` [ `prop=val`]* [`--d` `prop`]* `--test_only` [ `--partial` ] [`--verify` ]
	`application config` `name` `--template=app` [ `--skip_rsc` ] [ `prop=val`]* [`--d` `prop`]* `--test_only` [ `--partial` ] [`--verify` ]
	`application config` `name` `--stdin` [`--test_only`] [ `--partial` ] [`--verify` ]
Arguments:	`name`	Name of application to configure
	`--boundary`	Show application boundary (i.e., list of properties that may be configured).
	`--reset`	Reset all properties to default.
	`--template=app`	Name of application whose configuration is to be used as a base configuration before applying any configuration parameters specified on the command line.
	`--skip_rsc`	Do not propagate any resource settings from the template application.
	`prop=val`	Change a property setting.
	`--d` `prop`	Reset property to default.
	`--test_only`	Test provided configuration parameters, do not set. Note `--test-only` is provided for backward compatibility.
	`--partial`	Skip verification that all mandatory properties are set. As of Applogic 1.5, this option is provided for backward compatibility only (i.e., no-op).
	`--batch`	Display output in UDL format.
	`--stdin`	Read configuration parameters to be set from standard input.
	`--verify`	Verify that all mandatory properties are set.
Examples:	`app config SugarCRM` - Show current configuration for SugarCRM
	`application config SugarCRM --boundary` - Show configurable parameters for SugarCRM
	`application config SugarCRM --reset` - Reset app configurable parameters for SugarCRM to defaults
	`application config SugarCRM --stdin < sugar.params` - configure application using settings contained within the file `sugar.params`.
	`application config MyApp .template=1 --partial` - configure application as a template so that it may be later provisioned.
Notes:	Application configuration parameters specified by `prop` can be one of the following:
	* `.name` - attribute, attributes can be:
	`.description` - Free form text describing application
	`.template` - 0/1 - must be set in order for application to be provisioned
	`.user1, .user2` - Free form text used for client billing information
	`.destroy_on_stop` - Destroy application after it is stopped.
	`.doc_url` - URL where application documentation can be found.
	* `name` - property
	* `resource.val` - resource, resource can be cpu, mem, bw val can be min, max, dflt
	* `vol. name` - volume
	* `servers. val` - set servers, val can be min, max, set.
	When configuring an application using the `--stdin` option, the format of the input should be similar to the output of the following command: `app confiig` `name` `--batch`.
	As of Applogic 1.5, this command will not validate that all mandatory properties are set by default. To enable the property validation, specify the `--verify` option.
	Using the `--template=app` option is similar to executing `'app config mytemplate --batch \| app config myapp --stdin'` in that the configuration from 'mytemplate' is configured on 'myapp'.
	An added benefit of using the `--template=app` option is that additional configuration parameters may be specified that override those of the template application.
	A specification of the output of this command can be found here.

start

Description:	Start application
Syntax:	`application start` `name` ( `prop=val` )* [ `--debug` ] [ `--norestart` ] [ `--skipbuild` ] [ `--force` ] [ `--cap_cpu` ]
Arguments:	`name`	Name of application.
	`prop=val`	Parameters for scheduling. The following parameters may be specified:
		`cpu` - (optional) CPU allocation in whole CPUs or percent (`val`[`%`])
		`mem` - (optional) Memory allocation (`val`[`M[B]\|G[B]`]). If units are not specified, memory is specified in MB.
		`bw` - (optional) Bandwidth allocation (`val`[`M[b]\|G[b]`]). If units are not specified, bandwidth is specified in Mbps.
		`sched` - String specifying scheduling target (see below)
		`servers` - Number of servers on which application is to be started;
	`--debug`	Start application in debug mode.
	`--norestart`	Do not restart application upon grid failure.
	`--skipbuild`	Do not build application prior to start.
	`--force`	Force releasing any volumes that are currently in use without asking for verification.
	`--cap_cpu`	Enable the capping of CPU for all components of the application.
Examples:	`application start sugarcrm` - Start application 'sugarcrm'
Notes:	The following scheduling targets are supported:
	`sched="percentile=(resource percentile)"`
	`sched=crunch` - assign the minimum resources to all components, same as "percentile=0"
	`sched=expand` - assign the maximum resources to all components, same as "percentile=100"
	`sched="mode=(scheduling mode)"`, valid values are one of the following:
	* `1` - pack servers, schedule appliances on server with least amount of available resources
	* `2` - round robin with random start, randomly schedule first appliance to a server and then assign remaining appliances to other servers using round robin
	* `3` - round robin, schedule first appliance on the first server and then assign remaining appliances to other servers using round robin
	When using the pack server scheduling mode, the servers are chosen in priority order based on their assigned role and the least amount of available resources. AppLogic will always use servers with a role of `none` first, `secondary` second and `primary` last; without regards to the available resources on those servers (i.e., the `secondary` servers won't be used until all of the `none` servers are used, the `primary` server won't be used until all `secondary` and `none` servers are used).
	The application start will fail if `--debug` is specified and the application has field engineering code 16 set.
	Starting an application resets the component flapping counters that are maintained by AppLogic. A component's flapping counter is the number of times that component has failed within the last 24 hours (each component has its own flapping counter). Once a component fails 3 times in 24 hours, the component is not restarted by AppLogic. `comp start/restart` or `app restart` may also be used to reset a component's flapping counter.

stop

Description:	Stop an application
Syntax:	`application stop` `name` %BAR `--all` [ `--user` \| `--force` ]
Arguments:	`name`	Name of application to stop.
	`--all`	Stop all applications.
	`--user`	Stop all user applications. This option is only valid if `--all` is specified.
	`--force`	Skip user prompt to verify whether it is OK to stop system applications.
Examples:	`application stop sugarcrm` - Stop application 'sugarcrm'
	`application stop --all` - stop all applications
	`application stop --all --user` - stop only user applications
	`application stop --all --force` - stop all applications and do not prompt if system applications should be stopped.
Notes:	None.

continue

Description:	Continue starting an application.
Syntax:	`application continue` `name`
Arguments:	`name`	Name of application to continue starting
Examples:	`application continue sugarcrm` - Continue starting application 'sugarcrm'
Notes:	This command is used to continue the starting of an application that was started with `--debug` option and one of the components of the application failed to start.

restart

Description:	Restart application
Syntax:	`application restart` `name` ( `prop=val` )* [ `--debug` ] [ `--clean` ] [ `--norestart` ] [ `--skipbuild` ] [ `--force` ] [ `--cap_cpu` ]
Arguments:	`name`	Name of application.
	`prop=val`	Parameters for scheduling. The following parameters may be specified:
		`cpu` - (optional) CPU allocation (`val`[`%`])
		`mem` - (optional) Memory allocation (`val`[`M[B]\|G[B]`]). If units are not specified, memory is in MB.
		`bw` - (optional) Bandwidth allocation (`val`[`M[b]\|G[b]`]). If units are not specified, bandwidth is in Mbps.
		`sched` - String specifying scheduling target (see below)
		`servers` - Number of servers on which application is to be started;
	`--debug`	Restart application in debug mode. SCR 779
	`--clean`	Clean application prior to restart.
	`--norestart`	Do not restart application upon grid failure.
	`--skipbuild`	Do not build application prior to restart.
	`--force`	Force releasing any volumes that are currently in use without asking for verification. This is useful when restart is executed over an application that is not currently running. Supported in Applogic 2.8.8+.
	`--cap_cpu`	Enable the capping of CPU for all components of the application.
Examples:	`application restart sugarcrm` - Restart application 'sugarcrm'
Notes:	This command combines application stop and start commands.
	The `--clean` and `--skipbuild` options may not be specified at the same time.
	The following scheduling targets are supported:
	`sched="percentile=(resource percentile)"`
	`sched=crunch` - assign the minimum resources to all components, same as "percentile=0"
	`sched=expand` - assign the maximum resources to all components, same as "percentile=100"
	`sched="mode=(scheduling mode)"`, valid values are one of the following:
	* `1` - pack servers, schedule appliances on server with least amount of available resources
	* `2` - round robin with random start, randomly schedule first appliance to a server and then assign remaining appliances to other servers using round robin
	* `3` - round robin, schedule first appliance on the first server and then assign remaining appliances to other servers using round robin
	When using the pack server scheduling mode, the servers are chosen in priority order based on their assigned role and the least amount of available resources. AppLogic will always use servers with a role of `none` first, `secondary` second and `primary` last; without regards to the available resources on those servers (i.e., the `secondary` servers won't be used until all of the `none` servers are used, the `primary` server won't be used until all `secondary` and `none` servers are used).
	The application restart will fail if `--debug` is specified and the application has field engineering code 16 set.
	Restarting an application resets the component flapping counters that are maintained by AppLogic. A component's flapping counter is the number of times that component has failed within the last 24 hours (each component has its own flapping counter). Once a component fails 3 times in 24 hours, the component is not restarted by AppLogic. `comp start/restart` or `app start` may also be used to reset a component's flapping counter.

build

Description:	Build an application
Syntax:	`application build` `name`
Arguments:	`name`	Name of application to build
Examples:	`application build sugarcrm` - Build application 'sugarcrm'
Notes:	This command will fail if the application has already been started or is in an intermediate state.

clean

Description:	Clean an application
Syntax:	`application clean` `name`
Arguments:	`name`	Name of application to clean
Examples:	`application clean sugarcrm` - Clean application 'sugarcrm'
Notes:	This command will fail if the application has already been started or is in an intermediate state.

repair

Description:	Repair an application
Syntax:	`application repair` `name`
Arguments:	`name`	Name of application to repair
Examples:	`application repair sugarcrm` - Repair application 'sugarcrm'
Notes:	This command will fail if the application is not in ‘failed’ state.
	If the application is supposed to be running and there are components that are not running, then those components are restarted.
	if the application is supposed to be stopped and there are components that are not stopped, then those components are stopped.

login

Description:	Access the console of the default component of an application. A single component of the application may be specified to provide the console for the application.
Syntax:	`application login` `name` [`--ssh`] [`console=text\|graphic`] [`--force`] [`--abort`] [`command`]
Arguments:	`name`	Name of application whose console is going to be accessed.
	`--ssh`	SSH into the default component of the application (default)
	`console=text`	Access a text console of the default component of the application.
	`console=graphic`	Access a graphical console of the default component of the application.
	`--force`	Take control of console (kill existing console)
	`--abort`	Kill existing console (if any)
	`command`	Optional command line to execute. If there is more than one argument, the command must be enclosed in quotes (e.g., "ls /tmp"). This argument is only valid if --ssh is specified.
Examples	`application login sugarcrm --ssh` - SSH into default component of application 'sugarcrm'
	`application login sugarcrm "ls /tmp"` - SSH into default component of application 'sugarcrm' and execute `ls /tmp`
Notes:	A single application component may be specified as the default login console by right-clicking on the component within the AppLogic Editor and selecting "Set Default Console" from the context menu.
	When no console options are specified, login to the application using the default console that is specified for the application’s default component.
	This command will fail if the application or default component is not started.
	The ssh login is performed using a special appliances ssh key installed on your grid. This key does not need a passphrase -- it is assumed that if you are logged in on the controller, you are authorized to log in on the appliances. Contact Technical Support if you cannot log in on an appliance or if you believe your appliance key has been compromised and want to have it replaced.
	This command is similar to executing `comp login app:comp` where `app:comp` is the name of the component that is specified as the default console of the application.
	Only one console type may be specified – ssh, text, graphic.
	The --force and --abort options are only valid for text and graphic consoles.
	Whenever a user logs into an appliance, AppLogic creates an environment variable named `_APPLOGIC_USERID` which contains the name of the user that logged into the appliance. This is only valid if the appliance uses the `dhcp` configuration mode (APK).

export

Description:	Export an application
Syntax:	`application export` `name` [`dir`] [`file=file`] [ `--force` ] [ `--nocompress` \| `--novols` ]
Arguments:	`name`	Name of application to export
	`dir`	Name of exchange directory relative to /vol/_impex where application is to be exported. If not specified, the exchange directory name is the same as the application name.
	`file`	Name of tar file to contain the exported application. The specified file may have one of the following extensions: `.tar` : create a tar archive without compression `.tar.gz` : create a zipped tar archive `.tar.gz2` : create a bzip2 tar archive Supported in AppLogic 2.7.5+.
	`--force`	Overwrite contents of `dir` if not empty and/or `file` if it exists. If not specified and `dir` is not empty or `file` exists, this command will fail.
	`--nocompress`	Do not compress the volume images.
	`--novols`	Do not export the application volumes.
Examples:	`application export sugarcrm sugar` - Export application 'sugarcrm' to /vol/_impex/sugar
	`application export my-app` - Export application 'my-app' to /vol/_impex/my-app.
	`application export my-app file=my-app.tar` - Export application 'my-app' to /vol/_impex/my-app and create tar archive /vol/_impex/my-app.tar.
Notes:	If the application is running, this command will fail.
	At the conclusion of this command, the application's packing slip is created and all descriptors, images, etc. are copied to the destination directory.
	Applications exported from grids running AppLogic 1.2.12 and later may not be imported on a grid running Applogic 1.2.11 and earlier due to a defect in the earlier versions. However, applications exported from earlier versions of AppLogic may be imported on a grid running a later version of AppLogic.
	When exporting an application from a grid running AppLogic 1.2.12 and later with the intention of importing the application on a grid running an older version of AppLogic, the application must be exported with `--nocompress` option.

import

Description:	Import an application
Syntax:	`application import` `name` [`dir` \| `file`] [`user=user` [`pwd=-`]][ `mirrored=val` \| `--novols` ]
Arguments:	`name`	Name of application to import
	`dir`	Name of exchange directory from which the application is to be imported. The directory may be one of the following: - directory relative to /vol/_impex - URL with the following format 'http://`path`'. If not specified, the exchange directory name is the same as the application name.
	`file`	Name of tar file relative to /vol/_impex containing the previously exported application. The archive file must be one of the following types: - tar archive - tar archive with gzip compression - tar archive with bzip2 compression. Supported in AppLogic 2.7.5+.
	`user`	Name of user to use for authentication purposes when importing the application from a URL
	`pwd=-`	(Optional) Prompt for password to use for authentication purposes when importing the application from a URL. If the standard input is not a terminal device, it will not print a prompt and expect only one copy of the password on 'stdin' (this can be used for batch operations, to set the password from a file).
	`mirrored`	If set to 1, create all application's volumes as mirrored. Default is 1 if multi-server grid is configured.
	`--novols`	Do not import the application's volumes.
Examples:	`application import sugarnew sugar` - Import application 'sugarnew' from /vol/_impex/sugar
	`application import sugarnew http://myhttpserver.com/sugar` - Import application 'sugarnew' from HTTP server
	`application import my-app3` - Import application 'my-app3' from directory '/vol/_impex/my-app3'
	`Application import my-app myapp.tar.bz2` - Import application from bzip2 archive from '/vol/_impex/myapp.tar.bz2'
Notes:	Applications exported from grids running AppLogic 1.2.12 and later may not be imported on a grid running Applogic 1.2.11 and earlier due to a defect in the earlier versions. However, applications exported from earlier versions of AppLogic may be imported on a grid running a later version of AppLogic.
	When exporting an application from a grid running AppLogic 1.2.12 and later with the intention of importing the application on a grid running an older version of AppLogic, the application must be exported with `--nocompress` option.

migrate

Description:	Migrate an application from/to a remote grid
Syntax:	`application migrate` `remote_grid app` [ `.name=newapp` ] [ `--export \| --import` ] [ `--nocompress` ] [ `--nocleanup` ] [ `--debug` ] [ (`prop=val`)* ]
Arguments:	`remote_grid`	Name of remote grid
	`app`	Name of application to migrate
	`.name=newapp`	Optional new name for migrated application.
	`--export`	Migrate the application TO the remote grid.
	`--import`	Migrate the application FROM the remote grid.
	`--nocompress`	Do not compress application volumes during migration. This option is useful when migrating applications that have large volumes.
	`--nocleanup`	skip cleanup upon failure or completion (troubleshooting)
	`--debug`	show debug information during migration (troubleshooting)
	`prop=val`	config parameter pairs as used for the `application config` command.
Examples:	`app migrate myoldgrid.3tera.net myapp` - migrate application 'myapp' from grid 'myoldgrid.3tera.net' to current grid.
	`application migrate grid1.3tera.net crm7 usr_ip=64.4.47.21 out_ip=64.4.47.22` - Migrate application 'crm7' from grid 'grid1.3tera.net' and set its 'usr_ip' and 'out_ip' properties.
	`application migrate myoldgrid.3tera.net myapp .name=mynewapp` - migrate application 'myapp' from grid 'myoldgrid.3tera.net' to current grid and rename application to 'mynewapp'.
	`application migrate mynewgrid.3tera.net myapp --export` - migrate application myapp from current grid to grid 'mynewgrid.3tera.net'.
Notes:	If neither the `--export` or `--import` options are specified, the application is migrated FROM the remote grid.
	If the original application is running, it will be stopped prior to the migration. Upon completing the migration, the new application will be started. If the original application was not started, the new application will not be started.
	When accessing the grid via SSH, SSH agent and agent forwarding must be enabled on the client machine for the remote grid access to work. In addition, either the user's and/or the grid's public SSH key must also be installed on the remote grid in order to set up a "trust" between the two grids.
	The `--nocompress` option is useful when migrating applications that have very large volumes.
	see app config for help on properties and resources. The full and per-property reset are not supported (--reset and -d ).

provision

Description:	Provision an application
Syntax:	`application provision` `template target` [ (`vol.size=val`)* ] [ (`param=val`)* ] [ `--skipstart` ] [ `--fscpy` [`--prefill`]]
Arguments:	`template`	Name of template application from which to provision the application
	`target`	Name of application to provision; must not exist
	`vol.size=val`	Specify size of application user and singleton class volumes. Units may be specified (e.g, 128M[B], 2G[B]). If units are not specified, it is assumed that the specified value is in MB. The format of `vol` is one of the following: `name` - application user volume `class.name` - application singleton class volume
	`param=val`	Parameter to set on the application. The format of each parameter is the same as that specified for 'app config'.
	`--skipstart`	Do not start application after provisioning process is done. Note, the application is configured if parameters are specified.
	`--fscpy`	Perform filesystem-level copy when copying volumes. This is useful if the application has largge data volumes that have little data stored on them.
	`--prefill`	Allocate ALL blocks of the volume.
Examples:	`app provision SugarCRM crm7 usr_ip=64.4.47.21 out_ip=64.4.47.22 data.size=64M` - Provision crm7 application using SugarCRM as a template, resize the data volume, and set its usr_ip and out_ip properties prior to start.
Notes:	This command will fail if the template application is running.
	As of Applogic 1.2.5 this command will fail if the template application does not have the `template` attribute set - see `app config`.
	This operation is similar to 'application copy' with added volume resizing, configuration, and application start.

get_desc

Description:	Display application package descriptor
Syntax:	`application get_desc` `app`
Arguments:	`app`	name of application for which package descriptor is to be displayed
Examples:	`application get_desc my-app` - display package descriptor for application `my-app`
Notes:	None.

put_desc

Description:	Modify application package descriptor
Syntax:	`application put_desc` `app`
Arguments:	`app`	name of application for which package descriptor is to be modified
Examples:	`application put_desc my-app` - modify package descriptor for application `my-app`
Notes:	The new descriptor is obtained from standard input. The user can type in or paste the new descriptor contents followed by typing CTRL-d to terminate the input.
	The name of the application may not be changed within the new descriptor.
	If the operation is executed remotely, the command can be specified as follows: `ssh root@controllerhost app put_desc myapp < newdesc` where `newdesc` is a file containing the modified descriptor.

lock

Description:	lock an application
Syntax:	`application lock` `app` [ `pwd=-`]
Arguments:	`app`	name of application to be locked
	`pwd=-`	Prompt for the password used to unlock the application. If the standard input is not a terminal device, it will not print a prompt and expect only one copy of the password on 'stdin' (this can be used for batch operations, to set the password from a file).
Examples:	`application lock my-app` - Lock application `my-app`
	`application lock my-app pwd=-` - Lock application `my-app` and prompt for password
Notes:	A password is required for a non-maintainer to lock an application.
	If the `pwd` argument is specified, it is required in order to unlock the application.
	When an application is locked, no volumes belonging to the application may be managed and the application may not be modified in any way
	See Application and Class Locking Reference for more information.

unlock

Description:	unlock an application
Syntax:	`application unlock` `app` [ `pwd=-`] [`--override`]
Arguments:	`app`	name of application to be unlocked
	`pwd=-`	Prompt the user for the password that was provided when the application was locked. If the standard input is not a terminal device, it will not print a prompt and expect only one copy of the password on 'stdin' (this can be used for batch operations, to set the password from a file).
	`--override`	Override the lock and unlock the application. This option is only available to grid maintainers.
Examples:	`application unlock my-app` - Unlock application `my-app`
	`application unlock my-app pwd=-` - Unlock application and prompt for password
Notes:	If the application was locked with a password, the passwords must match
	If the application was locked without a password, then only a maintainer may unlock the application.
	See Application and Class Locking Reference for more information.

-- BeckyH - 23 May 2006

AppLogic27

Documentation
- Home

References
- Dashboard
- Configurator
- Editor
- Monitor
- Volume Browser
- Shell
- Catalog
- Applications
- Glossary

Guides
- App Provisioning?
- App Deployment
- Appliance Creation

Helpdesk| Bugzilla| Wiki