Shared File Systems service provides a set of services for management of
shared file systems in a multi-tenant cloud environment. The service resembles
OpenStack block-based storage management from the OpenStack Block Storage
service project. With the Shared File Systems service, you can create a remote
file system, mount the file system on your instances, and then read and write
data from your instances to and from your file system.
This is a pre-release charm for testing.
This charm provides the Manila shared file service for an OpenStack Cloud. It
installs a single instance that, on its own, can't be used.
In order to use the manila charm, a suitable backend charm is needed to
configure a share backend. At the time of writing (Dec 2016) the only backend
charm available for testing is the 'generic backend' charm called
'manila-generic'. This is used to configure a generic fileshare backend that
can implement an NFS server that then uses a cinder backend block storage
service to provide the share instances.
Without a backend subordinate charm related to the manila-charm there will be
no manila backends configured; the manila charm will be stuck in the blocked
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. Multiple backend charms can be related to the manila charm to
allow a manaila (juju) application to support multiple share backends.
Essentially, a plugin needs to be able to configure:
This pre-release of manila provides (in the charm store):
The backend provides a piece of the manila.conf configuration file with
the sections necessary to configure the backend. This is mostly for the share,
rather than the api level.
Manila (plus manila-generic) relies on services from the mysql/percona,
rabbitmq-server, keystone charms, and a storage backend charm. The following
yaml file will create a small, unconfigured, OpenStack system with the
necessary components to start testing with Manila. Note that these target the
'next' OpenStack charms which are essentially 'edge' charms.
# vim: set ts=2 et:
# Juju 2.0 deploy bundle for development ('next') charms
# UOSCI relies on this for OS-on-OS deployment testing
- [ keystone, mysql ]
- [ manila, mysql ]
- [ manila, rabbitmq-server ]
- [ manila, keystone ]
- [ manila, manila-generic ]
- [ glance, keystone]
- [ glance, mysql ]
- [ glance, "cinder:image-service" ]
- [ nova-compute, "rabbitmq-server:amqp" ]
- [ nova-compute, glance ]
- [ nova-cloud-controller, rabbitmq-server ]
- [ nova-cloud-controller, mysql ]
- [ nova-cloud-controller, keystone ]
- [ nova-cloud-controller, glance ]
- [ nova-cloud-controller, nova-compute ]
- [ cinder, keystone ]
- [ cinder, mysql ]
- [ cinder, rabbitmq-server ]
- [ cinder, nova-cloud-controller ]
- [ "neutron-gateway:amqp", "rabbitmq-server:amqp" ]
- [ neutron-gateway, nova-cloud-controller ]
- [ neutron-api, mysql ]
- [ neutron-api, rabbitmq-server ]
- [ neutron-api, nova-cloud-controller ]
- [ neutron-api, neutron-openvswitch ]
- [ neutron-api, keystone ]
- [ neutron-api, neutron-gateway ]
- [ neutron-openvswitch, nova-compute ]
- [ neutron-openvswitch, rabbitmq-server ]
- [ neutron-openvswitch, manila ]
and then (with juju 2.x):
juju deploy manila.yaml
Note that this OpenStack system will need to be configured (in terms of
networking, images, etc.) before testing can commence.
Please report bugs on Launchpad.
For general questions please refer to the OpenStack Charm Guide.