Client for OpenStack services
Go to file
James E. Blair 95c2f27fa4 Add openstack-common and test infrastructure.
Fix pep8 errors (project is pep8 clean now).

Update setup.py to use openstack-common style dependencies.

Remove the unused novaclient dependency.

Change the keystoneclient dependency to a git URL.

Add test-requires, and move some pip-requires dependencies
into it.

Remove the test_utils unit test which wasn't testing anything
that is actually present in the project.

Add the test_authors unit test.

Use tox for running tests locally.

See: http://wiki.openstack.org/ProjectTestingInterface

Tox can manage virtualenvs, and is currently doing so for running
tests in Jenkins. It's just as, or more, useful for running tests
locally, so this starts the migration from the run_tests system to
tox. The goal is to reduce duplicate testing infrastructure, and
get what's running locally on developer workstations as close to
what is run by Jenkins as possible.

Run_tests.sh will now call tox to facilitate the transition for
developers used to typing "run_tests.sh".

Developers will need tox installed on their workstations. It can
be installed from PyPI with "pip install tox". run_tests.sh outputs
those instructions if tox is not present.

New facilities are available using tox directly, including:

tox -e py26 # run tests under python 2.6
tox -e py27 # run tests under python 2.7
tox -e pep8 # run pep8 tests
tox # run all of the above
tox -e venv foo # run the command "foo" inside a virtualenv

The OpenStack nose plugin is used when running tox from the
command line, so the enhanced, colorized output is visible to
developers running the test suite locally. However, when Jenkins
runs tox, xunit output will be used instead, which is natively
understood by jenkins and much more readable in that context.

Change-Id: Ib627be3b37b5a09d3795006d412ddcc35f8c6c1e
2012-04-28 22:27:34 +00:00
docs First commit 2012-04-18 13:16:39 -05:00
openstackclient Add openstack-common and test infrastructure. 2012-04-28 22:27:34 +00:00
tests Add openstack-common and test infrastructure. 2012-04-28 22:27:34 +00:00
tools Add openstack-common and test infrastructure. 2012-04-28 22:27:34 +00:00
.gitignore Add openstack-common and test infrastructure. 2012-04-28 22:27:34 +00:00
.gitreview Add openstack-common and test infrastructure. 2012-04-28 22:27:34 +00:00
AUTHORS Add openstack-common and test infrastructure. 2012-04-28 22:27:34 +00:00
LICENSE First commit 2012-04-18 13:16:39 -05:00
MANIFEST.in Add openstack-common and test infrastructure. 2012-04-28 22:27:34 +00:00
README.rst Add token auth to shell and README 2012-04-27 11:49:15 -05:00
openstack-common.conf Add openstack-common and test infrastructure. 2012-04-28 22:27:34 +00:00
run_tests.sh Add openstack-common and test infrastructure. 2012-04-28 22:27:34 +00:00
setup.cfg Add openstack-common and test infrastructure. 2012-04-28 22:27:34 +00:00
setup.py Add openstack-common and test infrastructure. 2012-04-28 22:27:34 +00:00
tox.ini Add openstack-common and test infrastructure. 2012-04-28 22:27:34 +00:00

README.rst

OpenStack Client

python-openstackclient is a unified command-line client for the OpenStack APIs. It is a thin wrapper to the stock python-*client modules that implement the actual REST API client actions.

This is an implementation of the design goals shown in http://wiki.openstack.org/UnifiedCLI. The primary goal is to provide a unified shell command structure and a common language to describe operations in OpenStack.

python-openstackclient is designed to add support for API extensions via a plugin mechanism

Configuration

The cli is configured via environment variables and command-line options as listed in http://wiki.openstack.org/UnifiedCLI/Authentication.

The 'password flow' variation is most commonly used:

export OS_AUTH_URL=<url-to-openstack-identity>
export OS_TENANT_NAME=<tenant-name>
export OS_USERNAME=<user-name>
export OS_PASSWORD=<password>    # yes, it isn't secure, we'll address it in the future

The corresponding command-line options look very similar:

--os-auth-url <url>
--os-tenant-name <tenant-name>
--os-username <user-name>
--os-password <password>

The token flow variation for authentication uses an already-aquired token and a URL pointing directly to the service API that presumably was acquired from the Service Catalog:

export OS_TOKEN=<token>
export OS_URL=<url-to-openstack-service>

The corresponding command-line options look very similar:

--os-token <token>
--os-url <url-to-openstack-service>

Additional command-line options and their associated environment variables are listed here:

--debug             # turns on some debugging of the API conversation
                      (via httplib2)
--verbose | -v      # Increase verbosity of output. Can be repeated.
--quiet | -q        # suppress output except warnings and errors
--help | -h         # show a help message and exit