--- title: Charmhub | Deploy Cinder using Charmhub - The Open Operator Collection description: Deploy the latest version of Cinder on any cloud. OpenStack block storage service url: https://charmhub.io/cinder --- # Cinder [OpenStack Charmers](https://charmhub.io/publisher/openstack-charmers "View all packages from OpenStack Charmers") * [OpenStack Charmers](https://charmhub.io/publisher/openstack-charmers "View all packages from OpenStack Charmers") * [Cloud](https://charmhub.io/?filter=cloud) * [Storage](https://charmhub.io/?filter=storage) Platform: 24.04 23.10 23.04 22.10 22.04 21.10 21.04 20.10 20.04 +4 yoga/stable 815 ``` juju deploy cinder --channel yoga/stable ``` [Learn to deploy on juju >](https://juju.is/docs/juju/manage-applications) --- Share your thoughts on this charm with the community on discourse. [Join the discussion](https://discourse.charmhub.io/) # Overview The cinder charm deploys [Cinder](https://docs.openstack.org/cinder/latest/), the Block Storage (volume) service for OpenStack. The charm works alongside other Juju-deployed OpenStack services. **Important:** This documentation supports version `3.x` of the Juju client. See the [OpenStack Charm guide](https://docs.openstack.org/charm-guide/latest/project/support-notes.html#breaking-changes-between-juju-2-9-x-and-3-x) if you are using the `2.9.x` client. # Usage ## Configuration To display all configuration option information run `juju config `. If the application is not deployed then see the charm’s [Configure tab](https://charmhub.io/cinder/configure) in the Charmhub. Finally, the [Juju documentation](https://juju.is/docs/olm/configure-an-application) provides general guidance on configuring applications. ## Deployment The cinder application requires the following applications to be present: keystone, nova-cloud-controller, nova-compute, rabbitmq-server, and a cloud database. The database application is determined by the series. Prior to focal [percona-cluster](https://charmhub.io/percona-cluster) is used, otherwise it is [mysql-innodb-cluster](https://charmhub.io/mysql-innodb-cluster). In the example deployment below mysql-innodb-cluster has been chosen. Deploy Cinder itself (here, to a container on machine ‘1’), add relations to the core cloud applications, and then connect it to the cloud database: ``` juju deploy --to lxd:1 --config cinder.yaml cinder juju integrate cinder:identity-service keystone:identity-service juju integrate cinder:cinder-volume-service nova-cloud-controller:cinder-volume-service juju integrate cinder:amqp rabbitmq-server:amqp juju deploy mysql-router cinder-mysql-router juju integrate cinder-mysql-router:db-router mysql-innodb-cluster:db-router juju integrate cinder-mysql-router:shared-db cinder:shared-db ``` Multiple backend storage solutions are described next. ### Ceph-backed storage Cinder can be backed by Ceph, which is the recommended storage method for production Cinder deployments. This functionality is provided by the [cinder-ceph][cinder-ceph-charm] subordinate charm. ### LVM-backed storage Cinder can be backed by storage local to the cinder unit, where local block devices are used as LVM physical volumes, and volumes are offered via iSCSI. This functionality is provided by the [cinder-lvm](https://charmhub.io/cinder-lvm) subordinate charm. > **Note**: Built-in support for LVM in the cinder charm is deprecated. ### NetApp-backed storage Cinder can be backed by a NetApp appliance local to the cinder unit, where volumes are offered via iSCSI or NFS. This functionality is provided by the [cinder-netapp](https://charmhub.io/cinder-netapp) subordinate charm. ### Pure Storage-backed storage Cinder can be backed by a Pure Storage appliance reachable by its API endpoint. This functionality is provided by the [cinder-purestorage](https://charmhub.io/cinder-purestorage) subordinate charm. ## Separate Volume Service For certain operations when an instance is not involved, the cinder application will connect directly to the storage for operations such as cloning a volume from a glance image. You can deploy a second cinder application for the volume service only where the primary cinder application cannot connect to this storage. This may be required for iSCSI connections because LXD containers cannot create iSCSI connections or where you need a physical Fibre Channel connection. This is not required for Ceph deployments which use userspace RBD tools. 1. Deploy cinder with enabled-services=api,scheduler 2. Deploy a second application of cinder named ‘cinder-volume’ with enabled-services=volume 3. Relate the storage subordinate (e.g. cinder-purestorage) to the cinder-volume application only (not to the ‘cinder’ application) 4. Keystone should be related to cinder:identity-**service** but cinder-volume:identity-**credentials** The primary cinder application gets keystone credentials when registering a service endpoint via the identity-service relation. The cinder-volume application does not register a service, so we need to relate identity-credentials instead. The image volume cache will not work without this relation. 5. Both cinder and cinder-volume should otherwise have the same relations ## High availability This charm supports high availability via HAcluster. When more than one unit is deployed with the [hacluster](https://charmhub.io/hacluster) application the charm will bring up an HA active/active cluster. ## Network spaces This charm supports the use of Juju [network spaces](https://juju.is/docs/olm/network-spaces) (Juju `v.2.0`). This feature optionally allows specific types of the application’s network traffic to be bound to subnets that the underlying hardware is connected to. > **Note**: Spaces must be configured in the backing cloud prior to deployment. API endpoints can be bound to distinct network spaces supporting the network separation of public, internal, and admin endpoints. Access to the underlying MySQL instance can also be bound to a specific space using the shared-db relation. For example, providing that spaces ‘public-space’, ‘internal-space’, and ‘admin-space’ exist, the deploy command above could look like this: ``` juju deploy --config cinder.yaml cinder \ --bind "public=public-space internal=internal-space admin=admin-space shared-db=internal-space" ``` Alternatively, configuration can be provided as part of a bundle: ``` cinder: charm: cs:cinder num_units: 1 bindings: public: public-space internal: internal-space admin: admin-space shared-db: internal-space ``` > **Note**: Existing cinder units configured with the `os-admin-network`, > `os-internal-network`, or `os-public-network` options will continue to honour > them. Furthermore, these options override any space bindings, if set. ## Actions This charm supports actions. [Actions](https://juju.is/docs/olm/working-with-actions) allow specific operations to be performed on a per-unit basis. To display actions and their descriptions run `juju actions --schema `. If the application is not deployed then see the charm’s [Actions tab](https://charmhub.io/cinder/actions) in the Charmhub. ## Policy overrides This charm supports the policy overrides feature. Policy overrides allow an operator to override the default policy of an OpenStack service. See [Policy overrides](https://docs.openstack.org/charm-guide/latest/admin/policy-overrides.html) for more information on this feature. # Documentation The OpenStack Charms project maintains two documentation guides: * [OpenStack Charm Guide](https://docs.openstack.org/charm-guide): the primary source of information for OpenStack charms * [OpenStack Charms Deployment Guide](https://docs.openstack.org/project-deploy-guide/charm-deployment-guide): a step-by-step guide for deploying OpenStack with charms # Bugs Please report bugs on [Launchpad](https://bugs.launchpad.net/charm-cinder/+filebug). --- [Help improve this document in the forum](https://discourse.charmhub.io/t/cinder-docs-index/10549) ([guidelines](https://discourse.charmhub.io/t/how-to-write-docs-our-documentation-guidelines-for-contributors/1245)). Last updated 3 years ago.