490cddccaa
This patchset contains the code/charm for a working manila fileshare service. On its own, the fileshare the charm installs is not functional as a backend is needed. The charm-manila-generic plugin charm is provided separately to provide the generic NFS file share service. This patchset also includes the amulet/bundle tests to test that the charm installs the manila software and can get it running. However, no functional tests of the actual manila software are done. This patchset is dependent on the interface-manila-plugin interface and an updated version of charms.openstack that provides the 'options' member. It also depends on a slight change to the interface-neutron-plugin which adds a requires.py to allow it to be used to plugin to principal charms: these are declared below. Change-Id: Ie9bb7af1baab8b3bc20d26d907d9b51957eb326e Depends-On: Ied0ad014ab7b1d4778113b0d3f2bbae08075372e Depends-On: If6d103b4f62c95b0fa76562a18e418e0d319e987 Depends-On: I8760f2f9bec85ccc8b149b9560a6eed3e9ab418b
51 lines
2.4 KiB
Markdown
51 lines
2.4 KiB
Markdown
TODO
|
|
====
|
|
|
|
* Add roles to the manila charm: api, scheduler, data, process, (all)
|
|
* Ensure that HA is supported properly on the charm (and tested).
|
|
* Pause/Resume - implement the pause/resume actions that other charms support.
|
|
|
|
## Add roles:
|
|
|
|
It's necessary for the manila charm to be able to install itself as one of a
|
|
number of roles:
|
|
|
|
1. The manila-api: this provides the API to the rest of OpenStack. Until this
|
|
is HA aware, only ONE manila-api can be provisioned because it registers
|
|
itself with the keystone identity-service.
|
|
2. The manila-scheduler: Responsible for scheduling/routing requests to the
|
|
appropriate manila-share service. It does that by picking one back-end
|
|
while filtering all except one back-end.
|
|
3. The manila-share process: Responsible for managing Shared File Service
|
|
devices, specifically the back-end devices.
|
|
4. The manila-data process: This is responsible, in the manila system, for
|
|
data operations such as copying, migration, backups, etc. It's not clear
|
|
how far progressed that this service is.
|
|
|
|
Currently, the manila charm installs exactly one unit with all of the shared
|
|
services on the same unit. This is fine for testing, but won't be particularly
|
|
suited for a production environment.
|
|
|
|
So, it is proposed to enable configuration of the charm to enable it to install
|
|
any/all of the roles. This will then allow two manila (juju) applications to
|
|
be installed, such that (say) manila-api and manila-scheduler roles can be
|
|
configured as one (juju) application, and the manila-share as a seperate
|
|
application. Manila allows for serveral, different, manila-share instances to
|
|
be deployed, which would mean a single manila-api/scheduler (juju) application
|
|
and several (juju) applications, one each for each different manila-share
|
|
instance in the OpenStack cloud.
|
|
|
|
## Support HA Mode
|
|
|
|
The charm has been implemented using the `HAOpenStackCharm` class, which means
|
|
that the plumbing is available to support multiple juju units, each with a
|
|
manila instance, with the API endpoints provided via an vip. However, this has
|
|
not been tested, and before it can be declared 'production ready', this HA
|
|
modes need to be tested alongside the 'roles' discussed above.
|
|
|
|
## Pause/Resume
|
|
|
|
The charm does not implement the Pause/Resume actions that the other OpenStack
|
|
charms support. This needs to be implemented if the charm will be a
|
|
well-behaved citizen like the other charms.
|