openstack/charm-manila
Code Issues Proposed changes
c070c82572
charm-manila/TODO.md
Alex Kavanagh 490cddccaa First commit of manila charm 
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
2016-12-02 13:50:04 +00:00

2.4 KiB
Raw Blame History

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.