96 lines
3.8 KiB
Markdown
96 lines
3.8 KiB
Markdown
# 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`:
|
|
|
|
```yaml
|
|
includes: ['interface:manila-plugin']
|
|
```
|
|
|
|
and add a provides interface of type `manila` to your charm or layers
|
|
`metadata.yaml`:
|
|
|
|
```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](https://bugs.launchpad.net/openstack-charms/+filebug).
|
|
|
|
For development questions please refer to the OpenStack
|
|
[Charm Guide](https://github.com/openstack/charm-guide).
|