RETIRED, python utility to manage a tripleo based cloud
Go to file
Jiri Stransky 73f30b7286 Fix get_file in out-of-tree templates
We already have special processing in place for out-of-tree environment
files and templates, but it didn't handle `get_file` (or `type`)
links. This commit adds that handling.

Heatclient automatically uses absolute `file:///` links when processing
the external environment files and other files referenced from them via
`get_file` or `type`. Because we upload all our environment files and
templates to Swift, such links don't work. We need to use relative links
in `get_file` and `type`.

Change-Id: I009f75cbc6278a0a2ff75e93e1ed44f2c4893783
Closes-Bug: #1631426
2016-10-10 18:00:36 +02:00
doc/source Fix doc page for overcloud deploy 2016-08-22 13:47:17 +02:00
tripleoclient Fix get_file in out-of-tree templates 2016-10-10 18:00:36 +02:00
.coveragerc Merge "Change ignore-errors to ignore_errors" 2015-09-25 20:53:52 +00:00
.gitignore Ignore the .eggs directory 2016-09-07 16:31:17 +00:00
.gitreview Update .gitreview to point to review.openstack.org 2015-09-08 10:10:44 -04:00
.mailmap Initial commit 2015-03-17 09:33:52 -04:00
.testr.conf Initial commit 2015-03-17 09:33:52 -04:00
CONTRIBUTING.rst Cleanup some strangling references to rdomanager-oscplugin 2015-09-17 15:54:14 +00:00
LICENSE Initial commit 2015-03-17 09:33:52 -04:00
README.rst Cleanup some strangling references to rdomanager-oscplugin 2015-09-17 15:54:14 +00:00
babel.cfg Initial commit 2015-03-17 09:33:52 -04:00
bindep.txt Add libffi-dev to bindep.txt 2016-09-06 19:01:24 -04:00
requirements.txt Updated from global requirements 2016-10-06 03:33:09 +00:00
setup.cfg Revert "Upgrades: Add 'stack upgrade' command" 2016-09-19 07:13:37 -04:00
setup.py Updated from global requirements 2015-12-23 00:37:32 +00:00
test-requirements.txt Updated from global requirements 2016-10-06 03:33:09 +00:00
tox.ini Initial support for bindep 2016-08-11 20:04:55 -04:00

README.rst

tripleoclient

OpenStackClient reference plugin module

The OSC plugin system is designed so that the plugin need only be properly installed for OSC to find and use it. It utilizes the setuptools entry points mechanism to advertise to OSC the plugin module and supported commands.

tripleoclient is an OpenStackClient (OSC) plugin implementation that implements commands useful for TripleO and the install and management of both an undercloud and an overcloud.

Discovery

OSC discovers extensions by enumerating the entry points found under openstack.cli.extension and initializing the given client module.

[entry_points]
openstack.cli.extension =
    oscplugin = oscplugin.plugin

The client module must implement the following interface functions:

  • API_NAME - A string containing the plugin API name; this is the name of the entry point declaring the plugin client module (oscplugin = ... in the example above) and the group name for the plugin commands (openstack.oscplugin.v1 = in the example below)
  • API_VERSION_OPTION (optional) - If set, the name of the API version attribute; this must be a valid Python identifier and match the destination set in build_option_parser().
  • API_VERSIONS - A dict mapping a version string to the client class
  • build_option_parser(parser) - Hook to add global options to the parser
  • make_client(instance) - Hook to create the client object

OSC enumerates the loaded plugins and loads commands from the entry points defined for the API version:

openstack.oscplugin.v1 =
    plugin_list = oscplugin.v1.plugin:ListPlugin
    plugin_show = oscplugin.v1.plugin:ShowPlugin

Note that OSC defines the group name as openstack.<api-name>.v<version> so the version should not contain the leading 'v' character.

This second step is identical to that performed for all but the Identity client in OSC itself. Identity is special due to the authentication requirements. This limits the ability to add additional auth modules to OSC.

Client

The current implementation of the tripleoclient Client class is an empty placeholder. This client object is not equired but OSC's ClientManager will maintain it as required and is the interface point for other plugins to access anything implemented by this plugin.