Typically, a Manila backend configuration simply needs to provide one or more configuration sections to the manila.conf file. It might also need to install some additional software to the node that manila is running on. (Note that, at present, all the manila services run on the same machine unit.)
In order to make it easier to write a configuration charm for a backend, a template has been provided to bootstrap the process. This example shows how to get started and provides pointers to help understand what to do next.
In the example below we will assume that a new charm provides a simple configuration to the manila charm.
(Note. This will change once the OpenStack templates are on pypi)
In order get the OpenStack charm templates installed into the charm create command, the charm-templates-openstack module needs to be installed alongside the charm-tools module. The code assumes that the charm-tools module is already installed.
mkdir working
cd working
git clone git@github.com:openstack-charmers/charm-templates-openstack.git
cd charm_templates_openstack
sudo ./setup.py install
Charm tools provides a utility for building an initial charm from a template. During the charm generation charm tools asks a few questions about the charm.
Note that the charm created from the template is not functional and needs further editing to produce the functional charm needed.
cd path.to.working
charm-create -t openstack-manila-plugin new-manila-plugin
INFO: Generating charm for new-manila-plugin in ./new-manila-plugin
INFO: No new-manila-plugin in apt cache; creating an empty charm instead.
What is the earliest OpenStack release this charm will support? mitaka
What packages should this charm install (space seperated list)?
What is the package to take the version from (manila-api is probably ok)?
Three questions are asked:
The files that the template creates is:
tree
.
├── LICENSE
├── requirements.txt
├── src
│ ├── config.yaml
│ ├── copyright
│ ├── icon.svg
│ ├── layer.yaml
│ ├── lib
│ │ └── charm
│ │ └── openstack
│ │ ├── __init__.py
│ │ └── new_manila_plugin.py
│ ├── metadata.yaml
│ ├── reactive
│ │ └── new_manila_plugin_handlers.py
│ ├── README.md
│ ├── templates
│ │ └── mitaka
│ │ └── manila.conf
│ ├── tests
│ │ ├── basic_deployment.py
│ │ ├── gate-basic-trusty-icehouse
│ │ ├── gate-basic-trusty-liberty
│ │ ├── gate-basic-trusty-mitaka
│ │ ├── gate-basic-xenial-mitaka
│ │ ├── README.md
│ │ └── tests.yaml
│ └── tox.ini
├── test-requirements.txt
└── unit_tests
├── __init__.py
├── test_lib_new_manila_plugin_handlers.py
└── test_new_manila_plugin_handlers.py
This is a reactive source charm layer that is used to build the final charm. The files in the template are:
The basic theory of operation of a manila configuration plugin charm is to use the config that is presented to the charm to write a configuration section for a backend for manila. The charm may also need to install software, and the charm can be altered to do this, but normally the manila software comes with all of the supported drivers as part of the code base. Here only the configuration is considered.
The plugin charm has access to the same authentication credentials as the manila charm if it needs to configure OpenStack services or needs to write authentication credentials to other configuration files. The manila-generic charm needs to configure [nova], [neutron] and [glance] sections and uses the authentication data to do so.
It is probably that the configuration charm will use config parameters as part of the template. This are exposed via the config. option in the template, and on the options member in the charm instance. It is sometimes useful to compute a configuration option that can be used in the template or charm (e.g. a boolean to say that the config is available).
A computed config option is done as:
@charms_openstack.adapters.config_property
def is_config_okay(config):
if config.something and config.something_else > 10:
return True
return False
This can then be used as {{ config.is_config_okay}} in a template or in the charm instance as:
def some_method(self):
if self.options.is_config_okay:
do_something_if_the_config_is_okay()
else:
do_something_else()
The configuration for manila.conf is generated in the get_config_for_principal() method in the charm class defined in the src/lib/charm/openstack directory. The key steps to be aware of are:
It’s useful to verify that the charm code is valid Python code and that all the imports needed are met and other linting issues. With tox installed, this can easily be done by:
tox -e pep8
The charm now needs to be built to pull down all the interfaces and layers the charm depends on and rolled into the built charm which can be deployed.
tox -e build
Testing/deploying the charm can only be really done with a fragment of an OpenStack system and the tox func27-smoke target gives an easy method to deploy and verify the small system. Note that once it is deployed, if there are errors then they can be modified and the charm rebuilt and re-deployed. A test session might look something like:
cd build/builds/{package-name}
tox -e func27-smoke # this will run the gate-basic-xenial-mitaka
This will get an OpenStack fragment running. The gate-basic-xenial-mitaka may need to be changed if that target is not supported by the charm.
Then if there are errors:
cd {package-name}
# make changes
tox -e build
juju remove-relation manila {package-name}
# wait until the subordinate is removed/and or destroy the manila unit.
# If destroying the manila unit, then remember to redploy it
juju upgrade-charm --path=build/builds/{package-name} {package-name}
juju add-relation manila {package-name}
This will re-install the subordinate charm which may show further errors, etc.
juju status will now show both charms deployed.