A helpful multi-utility cli that takes care of a lot of the configuration needed to use the various openstack clients.
1) Make a directory named ".mush" in your home or current directory
2) Create a file named "config" in the ".mush" directory
(There is a sample "config" file in the code repository)
3) Create a file named "datastore.csv" file in the ".mush" directory
(There is a sample "datastore.csv" file in the code respository)
Mush's config file has one required section "[default_plugins]" and an additional section for each plugin.
The [default_plugins] section tells mush which plugins you want it to use for which interface. There should only be one entry per interface here (e.g., there should only be one value assigned to 'datastore')
You can define a configuration section for each plugin by naming that section with the interface and plugin names, like so:
[interface_name.plugin_name]
option=value
These sections will be read and used if the plugin is defined as the default plugin for that interface. The example config contains empty sections for all included interfaces and their plugins.
Working with the openstack command line utilities can be a little frustrating at times, especially if you routinely have to use several different combinations of users and environment-specific configuration for different deployments.
I moved all my user and environment stuff into a central data file (by default a .csv file, but there is support for other options), stored as specific combinations of environment variables and values, indexed by an alias. Mush then gives you a cli that lets you choose which set to export before making a call to any of the external clients. Mush doesn't care about what you're setting in the environment, and it doesn't care about the syntax of whatever client you may be using. It just sets the env vars on a subprocess call to the command you specify, like this:
Given the following data:
: example_alias
OS_AUTH_URL : https://192.168.0.1:5000
OS_TENANT_NAME : 12345
OS_USERNAME : myuser
OS_PASSWORD : mypassword
Assuming that the python-novaclient is installed, the following command:
mush example_alias nova list
Would export those OS_* env vars, then execute nova list
.
The neat thing is that it does this in the subprocess, so your shell's environment remains untouched.
Mush's datastore is pluggable, so you can implement a plugin that works for whatever backend you need. By default, the csv datastore is used.
The actual user-contributed plugins go here. They can be as complicated as packages themselves, or individual modules.
This module contains classes that define the pluggable interfaces. You can inherit from any of these classes in your plugin and implement the interface and everything else will work like magic. Mush's plugability is limited by the interfaces defined here.
This is how mush interacts with the plugins. For every class in interface.py, there is an autogenerated method in api that mush will call to retrieve an implemented version of that interface class. As an example, when api.data_store is called in the mush cli, it's making that call to the plugin you've configured mush to use.
###datastore.supernova
If you're also using Major's supernova client for Openstack clients, this plugin will allow you to your .supernova file as a datastore for mush.
To use: Set 'datastore=supernova' in the [default_plugins] section of your mush config file.
Create a section named [datastore.supernova] with an option named 'location' equal to the
path where your supernova config file is located.
###access_secret.python_keyring
If your datastore uses python's keyring package for storing passwords, this plugin will allow mush to access that keyring.
To use: Set 'access_secret=python_keyring' in the [default_plugins] section of your mush config file.
Create a section named [access_secret]
Set an option named 'magic_prefix' equal to the prefix used by your datastore. This defaults
to 'magic_prefix=KEYRING:'
Set an option named 'service' equal to the service name your key/pass pairs are saved under
in the keyring. (e.g., for supernova, this is usually 'supernova')