openstack/charm-manila-generic
Code Issues Proposed changes
Files
cdae8ebe6bac3577941aecd3f4cd4cfc857207a8
charm-manila-generic/TODO.md
T
Alex Kavanagh 9b039d3981 First commit of charm-manila-generic 
The generic manila charm provides the generic backend NFS configuration
for the manila file service charm (charm-manila).  This is the first
commit of code, and the CI tests have been disabled to enable it to
land.  This is because of a circular dependency with the manila charm
which requires this charm to be able to configure at least one backend.

This patchset is dependent on the interface-manila-plugin interface and
an updated version of charms.openstack that provides the 'options'
member: these are declared below.

Change-Id: I052f272dcd310091d988afd7104dea68115053ac
Depends-On: Ied0ad014ab7b1d4778113b0d3f2bbae08075372e
Depends-On: If6d103b4f62c95b0fa76562a18e418e0d319e987
2016-12-02 13:50:46 +00:00

2.3 KiB
Raw Blame History

TODO

  • Add roles to the manila charm: api, scheduler, data, process, (all)
  • Add a manila-backend-plugin interface
  • Split the generic configuration into manila-generic-backend charm
  • Add unit tests
  • Add amulet tests
  • Put the manual testing bits into charm-openstack-testing so that the bundles are available

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. Also, it may not make sense to provision more than one manila-api server per OpenStack installation.
  2. The manila-scheduler: TODO
  3. The manila-data process: TODO
  4. The manila-share process: TODO

Split the generic backend configuration out into a separate charm + interface

It's necessary to have the ability to configure a share backend independently of the main charm. This means that plugin charms will be used to configure each backend.

Essentially, a plugin needs to be able to configure:

  • it's section in the manila.conf along with any network plugin's that it needs (assuming that it's a share that manages it's own share-instance).
  • ensure that the relevant bits are restarted.

It's not clear whether, for example, the api bit needs to know if the backend is a generic backend, rather than something else.

Anyway, to start with:

  • charm-manila : the main charm that can be deployed as multiple roles
  • interface-manila-backend-plugin : the interface for plugging in the generic backend (and other interfaces)
  • charm-manila-generic-backend : the plugin for configuring the generic backend.

The backend needs to provide a piece of the manila.conf configuration file with the bits necessary to configure the backend. This is mostly for the share, rather than the api level. However, the issue is that parts of this file actually need informatation from the principal charm (i.e. the manila service user and password). And only the API charm should register with keystone (particularly when the HA stuff is done with a floating VIP).

So, to solve that particular problem, we need to 'half' do the template, OR provide the keystone 'manila' user credentials across the interface. And I prefer the latter!

View Git Blame Copy Permalink