Charm Interface - Manila configuration plugin
Go to file
Alex Kavanagh 14cb348a09 Migrate unit tests from testr to stestr
Note: there aren't actually any unit tests, but this at least moves it
away from the deprecated library.

Change-Id: Ic9bec4534bc200d427241cd60b5b90b0fd89102e
2021-02-10 10:50:51 +00:00
.gitignore plugin interface for manila to backends 2016-11-15 15:21:27 -06:00
.gitreview OpenDev Migration Patch 2019-04-19 19:32:02 +00:00
.stestr.conf Migrate unit tests from testr to stestr 2021-02-10 10:50:51 +00:00
.zuul.yaml import zuul job settings from project-config 2018-10-04 11:28:52 +00:00
LICENSE plugin interface for manila to backends 2016-11-15 15:21:27 -06:00
README.md Merge "Omit the twice occured words in README.md" 2019-01-09 10:29:36 +00:00
interface.yaml plugin interface for manila to backends 2016-11-15 15:21:27 -06:00
provides.py Remove StateList and State from provides/requires files 2017-11-23 14:09:39 +00:00
requires.py Fix the misspelling of "configuration" 2018-12-27 11:28:22 +08:00
test-requirements.txt Migrate unit tests from testr to stestr 2021-02-10 10:50:51 +00:00
tox.ini Migrate unit tests from testr to stestr 2021-02-10 10:50:51 +00:00

README.md

Overview

This interface provides a mechanism for 'plugins' to the the Manila charm to provide configuration sections/parts to the Manila charm.

It is intended to be used to enable manila share backends to be configured independently of the main charm, so that vendors/maintainers can supply their own backend configuration charms as the project continues.

Manila usage

This interface is used between the Manila charm (share backend role or all) to provide the manila service user auth details to backend configuration charms, and to obtain configuration information that needs to be written into 8 No explicit handler is required to consume this interface in charms that consume this interface.

The interface provides manila-plugin.connected and manila-plugin.available states.

For a Manila backend subordinate charm

A Manila subordinate charm uses this interface to configure the manila configuration files to 'plugin' its functionality. e.g. the generic backend needs authentication information (the manila service user) so that it can generate the configuration information for nova, neutron and cinder as part of the backend configuration in manila.conf.

The generic charm then needs to set the configuration that the manila principal charm will use to write the manila.conf and other files. i.e. the manila charm will fold in the data presented into the its configuration information.

How the conversation 'goes' between the principal (manila) and subordinate

  1. Juju connects the two charms.
  2. When the 'requires' side connects (hook {requires:manila-plugin}-relation-joined fires), the Manila principal charm will receive the state({relation_name}.connected).
  3. When the 'provides' side connect (hook {provides:manila-plugin}-relation-joined fires) the subordinate charm will receive the state({relation_name}.connected).
  4. When the Manila charm has received keystone authentication information it will set that on the relation, and on receipt the 'provides' side will set the {relation_name}.available state. This allows the providing charm (subordinate backend) to use this information.
  5. If the subordinate needs the auth info, then it should block until {relation_name}.available is available.
  6. The subordinate should present its configuration information on the interface, which will be received on the 'requires' side. This will set the {relation_name}.available.
  7. If either side changes 'their' data (e.g. the data they set on the interface), then the receiving side will set the {relation_name}.changed state. IF the consuming charm uses the ...changed state, it MUST remove it as otherwise it will not 'receive' it again.

The important points are:

  • the ...available state indicates the first time that the data from the other side of the interface.
  • the ...changed state indicates the next and subsequent times that data from the other side has changed. This may not be important to the subordinate, but Manila will use this to rewrite the configuration files.
  • If the subordinate consumes the ...changed state, then it must remove it at the end of processing, so that it can 'see' it the next time it is set.

metadata

To consume this interface in your charm or layer, add the following to layer.yaml:

includes: ['interface:manila-plugin']

and add a provides interface of type manila to your charm or layers metadata.yaml:

provides:
  manila:
    interface: manila-plugin
    scope: container

Please see the example 'Manila generic backend' charm for an example of how to author a manila backend configuration charm.

Bugs

Please report bugs on Launchpad.

For development questions please refer to the OpenStack Charm Guide.