Jump to: navigation, search

Difference between revisions of "UnifiedCommandLineClient"

Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
−
== Required Options ==
+
= [[OpenStack]] Unified Client =
−
I understand the irony (?) of having required options, but they're not technically required because they'll default to environmental variables, so having them as command line arguments is not an option.
+
Working with multiple [[OpenStack]] projects can be quite tedious as they all have their own command-line tools. Having a single command-line interface (CLI) will help to unify project developers, reduce operational headaches, and provide users with a better overall experience.
  
−
{| border="1" cellpadding="2" cellspacing="0"
+
== Start with Authentication / Authorization ==
−
|bgcolor="#DDDDDD" | '''Command Line Option'''
+
If the first step, when calling our unified CLI, is to authenticate against a provided authentication endpoint (managed by a Keystone-compaible service), then right away feedback can be given to the user regarding which services are available for use.
−
|bgcolor="#DDDDDD" | '''Environmental Variable'''
 
−
|-
 
−
|  --url
 
−
|  OS_AUTH_URL
 
−
|-
 
−
|  --project
 
−
|  OS_PROJECT_ID
 
−
|-
 
−
|  --username
 
−
|  OS_AUTH_USER
 
−
|-
 
−
|  --apikey
 
−
|  OS_AUTH_KEY
 
−
|}
 
  
−
Simply typing 'os' will give you usage/help information. This would be the same as typing -h or --help:
+
'''For example, if incorrect authentication is given, or an invalid/inaccessible URL is given:'''
  
  
Line 33: Line 19:
  
  
−
If correct username, api key, and URL is provided via environment variables, the a more detailed response can be formulated using information returned by the authentication server (regarding which services are available to the authenticated user).
+
'''Once valid authentication information is given, we can provide the user with a better overview of available services:'''
  
  
Line 52: Line 38:
  
  
−
Drilling deeping, when a project has been selected, specific commands can be given, and help is returned which is tailored to your authentication and authorization.
+
The list of services above is generated by reading the response headers when authenticating with Keystone. For example, a successful Keystone request might response with a custom "X-Compute-Url" header which indicates that the user is successfully authorized for some function at that Compute endpoint.
 +
 
 +
When a service is selected on the command line, detailed information will be generated based on the authorization of the currently authenticated user. For example:
  
  
Line 91: Line 79:
  
  
−
==== Obvious Problems ====
+
We can see that this user has access to many of the run-of-the-mill Compute tasks, but they are also authorized to use functions from the "Compute Administrative Extension" and the "Compute Zones Extension". You can tell that these commands are provided by extensions because they are prefixed with a relevant...prefix.
−
An implementation of this might be slow before caching is involved because even the error response views above require a round-trip talk with one or more [[OpenStack]] services. Caching solves this, but caching shouldn't be in v1.
+
 
 +
=== Required Options ===
 +
I understand the irony (?) of having required options, but they're not technically required because they'll default to environmental variables, so having them as command line arguments is not an option.
 +
 
 +
{| border="1" cellpadding="2" cellspacing="0"
 +
|bgcolor="#DDDDDD" | '''Command Line Option'''
 +
|bgcolor="#DDDDDD" | '''Environmental Variable'''
 +
|-
 +
|  --url
 +
|  OS_AUTH_URL
 +
|-
 +
|  --project
 +
|  OS_PROJECT_ID
 +
|-
 +
|  --username
 +
|  OS_AUTH_USER
 +
|-
 +
|  --apikey
 +
|  OS_AUTH_KEY
 +
|}
 +
 
 +
=== Potential Issues ===
 +
  An implementation of this might be slow before caching is involved because even the error response views above require a round-trip talk with one or more [[OpenStack]] services. Caching solves this, but caching shouldn't be in v1.

Revision as of 18:59, 4 August 2011

OpenStack Unified Client

Working with multiple OpenStack projects can be quite tedious as they all have their own command-line tools. Having a single command-line interface (CLI) will help to unify project developers, reduce operational headaches, and provide users with a better overall experience.

Start with Authentication / Authorization

If the first step, when calling our unified CLI, is to authenticate against a provided authentication endpoint (managed by a Keystone-compaible service), then right away feedback can be given to the user regarding which services are available for use.

For example, if incorrect authentication is given, or an invalid/inaccessible URL is given: 


$ os
usage: os [--url URL] [--username USERNAME] [--apikey APIKEY] [--project PROJECT]

Command-line interface for connecting to various OpenStack projects.

Correct authentication URL and credentials must be supplied before more detailed options can be given.


Once valid authentication information is given, we can provide the user with a better overview of available services: 


$ os
usage: os <project>

Command-line interface for connecting to various OpenStack projects.

Supported projects:
	compute		Manage compute nodes via the "Nova" API.
	image		Manage disk images via the "Glance" API.
	queue		Manage queues via the "Burrow" API.
	volume		Manage remote disk volumes via the "Lunr" API.
	auth		Manage authentication and authorization via the "Keystone" API.
	network		Manage networks via the "Melange" API.


The list of services above is generated by reading the response headers when authenticating with Keystone. For example, a successful Keystone request might response with a custom "X-Compute-Url" header which indicates that the user is successfully authorized for some function at that Compute endpoint.

When a service is selected on the command line, detailed information will be generated based on the authorization of the currently authenticated user. For example: 


$ os compute
usage: os compute <command>

Command-line interface for retrieving information from an OpenStack Compute service.

Supported API versions:
	v1.0 
	v1.1 [Default]

Supported commands:
	boot			Boot a new server.
	delete			Shut down and delete a server.
	flavor-list		Print a list of available 'flavors'.
	image-list		Print a list of available disk images.
	snapshot		Create a new disk image based on a currently
				running server.
	list			List active servers.
	reboot			Reboot a server.
	rebuild			Shutdown, re-image, and re-boot a server.
	rename			Rename a server.
	resize			Begin the resize process.
	resize-confirm		Confirm a previously started resize.
	resize-revert		Revert a previously started resize.

	admin:diagnostics	Retrieve server diagnostics.
	admin:boot		Boot a new server, with extra options.
	admin:lock		Lock a server, preventing any changes.
	admin:unlock		Remove server lock, allowing future changes.

	zone:list		List zones underneath this endpoint.
	zone:info		Get information on this endpoint's zone.
	zone:add		Add a new child zone underneath this endpoint.


We can see that this user has access to many of the run-of-the-mill Compute tasks, but they are also authorized to use functions from the "Compute Administrative Extension" and the "Compute Zones Extension". You can tell that these commands are provided by extensions because they are prefixed with a relevant...prefix.

Required Options

I understand the irony (?) of having required options, but they're not technically required because they'll default to environmental variables, so having them as command line arguments is not an option.

Command Line Option Environmental Variable
--url OS_AUTH_URL
--project OS_PROJECT_ID
--username OS_AUTH_USER
--apikey OS_AUTH_KEY

Potential Issues

 An implementation of this might be slow before caching is involved because even the error response views above require a round-trip talk with one or more OpenStack services. Caching solves this, but caching shouldn't be in v1.
Retrieved from "https://wiki.openstack.org/w/index.php?title=UnifiedCommandLineClient&oldid=4022"