OpenStackClient has a consistent and predictable format for all of its commands.
Commands take the form:
openstack [<global-options>] <object-1> <action> [<object-2>] [<command-arguments>]
- All long options names begin with two dashes (
--) and use a single dash (-) internally between words (--like-this). Underscores (_) are not used in option names.
Global options are global in the sense that they apply to every command
invocation regardless of action to be performed. They include authentication
credentials and API version selection. Most global options have a corresponding
environment variable that may also be used to set the value. If both are
present, the command-line option takes priority. The environment variable
names are derived from the option name by dropping the leading dashes (--),
converting each embedded dash (-) to an underscore (_), and converting
to upper case.
For example, the default value of --os-username can be set by defining
the environment variable OS_USERNAME.
Commands consist of an object described by one or more words followed by an action. Commands that require two objects have the primary object ahead of the action and the secondary object after the action. Any positional arguments identifying the objects shall appear in the same order as the objects. In badly formed English it is expressed as "(Take) object1 (and perform) action (using) object2 (to it)."
<object-1> <action> <object-2>
Examples:
group add user <group> <user> volume type list # 'volume type' is a two-word single object
Each command may have its own set of options distinct from the global options. They follow the same style as the global options and always appear between the command and any positional arguments the command requires.
The objects consist of one or more words to compose a unique name.
Occasionally when multiple APIs have a common name with common
overlapping purposes there will be options to select which object to use, or
the API resources will be merged, as in the quota object that has options
referring to both Compute and Volume quotas.
access token: Identity - long-lived OAuth-based tokenaggregate: Compute - a grouping of serversbackup: Volume - a volume copyconsole log: Compute - a text dump of a server's consoleconsole url: Compute - a URL to a server's remote consoleconsumer: Identity - OAuth-based delegateecontainer: Object Store - a grouping of objectscredential: Identity - specific to identity providersdomain: Identity - a grouping of projectsendpoint: Identity - the base URL used to contact a specific serviceextension: Compute, Identity, Volume - additional APIs availableflavor: Compute - pre-defined configurations of servers: ram, root disk, etcgroup: Identity - a grouping of usershost: Compute - the physical computer running a hypervisorhypervisor: Compute - the virtual machine manageridentity provider: Identity - a source of users and authenticationimage: Image - a disk imageip fixed: Compute, Network - an internal IP address assigned to a serverip floating: Compute, Network - a public IP address that can be mapped to a serverkeypair: Compute - an SSH public keylimits: Compute, Volume - resource usage limitsmodule: internal - installed Python modules in the OSC processnetwork: Network - a virtual network for connecting servers and other resourcesobject: Object Store - a single file in the Object Storepolicy: Identity - determines authorizationproject: Identity - the owner of a group of resourcesquota: Compute, Volume - limit on resource usagerequest token: Identity - temporary OAuth-based tokenrole: Identity - a policy object used to determine authorizationsecurity group: Compute, Network - groups of network access rulessecurity group rule: Compute, Network - the individual rules that define protocol/IP/port accessserver: Compute - a virtual machine instanceservice: Identity - a cloud servicesnapshot: Volume - a point-in-time copy of a volumetoken: Identity - the magic text used to determine accessuser: Identity - individuals using cloud resourcesvolume: Volume - block volumesvolume type: Volume - deployment-specific types of volumes available
The actions used by OpenStackClient are defined below to provide a consistent meaning to each action. Many of them have logical opposite actions. Those actions with an opposite action are noted in parens if applicable.
authorize- authorize a token (used in OAuth)add(remove) - add some object to a container object; the command is built in the order ofcontainer add object <container> <object>, the positional arguments appear in the same ordercreate(delete) - create a new occurrence of the specified objectdelete(create) - delete a specific occurrence of the specified objectissue(revoke) - issue a tokenlist- display summary information about multiple objectslock(unlock)migrate- move a server to a different host;--liveperforms a live migration if possiblepause(unpause) - stop a server and leave it in memoryreboot- forcibly reboot a serverrebuild- rebuild a server using (most of) the same arguments as in the original createremove(add) - remove an object from a group of objectsrescue(unrescue) - reboot a server in a special rescue mode allowing access to the original disksresize- change a server's flavorresume(suspend) - return a suspended server to running staterevoke(issue) - revoke a tokensave- download an object locallyset(unset) - set a property on the object, formerly called metadatashow- display detailed information about the specific objectsuspend(resume) - stop a server and save to disk freeing memoryunlock(lock)unpause(pause) - return a paused server to running stateunrescue(rescue) - return a server to normal boot modeunset(set) - remove an attribute of the object
The command structure is designed to support seamless addition of plugin
command modules via setuptools entry points. The plugin commands must
be subclasses of Cliff's command.Command object. See :doc:`plugins` for
more information.
Commands are added to the client using setuptools entry points in setup.cfg.
There is a single common group openstack.cli for commands that are not versioned,
and a group for each combination of OpenStack API and version that is
supported. For example, to support Identity API v3 there is a group called
openstack.identity.v3 that contains the individual commands. The command
entry points have the form:
action_object = fully.qualified.module.vXX.object:ActionObject
For example, the list user command for the Identity API is identified in
setup.cfg with:
openstack.identity.v3 =
# ...
list_user = openstackclient.identity.v3.user:ListUser
# ...