Juju Charm - Cinder
Go to file
Nobuto Murata 82bc1e227b Make sure iscsid has a unique InitiatorName
os_brick may require InitiatorName in /etc/iscsi/initiatorname.iscsi
before iscsid is invoked via iscsid.socket with iscsiadm. Cloud images
including MAAS ones have "GenerateName=yes" instead of "InitiatorName="
on purpose not to clone the initiator name. Let's initialize it so
Cinder units can be fully ready to accept iSCSI based subordinate and
storage backend charms.

Closes-Bug: 1825809
Change-Id: I413bbb29dd609e0c86ac3691556f37a9fcc13439
(cherry picked from commit bde329d973)
2021-12-01 10:20:55 +00:00
actions Sync libraries & common files prior to freeze 2020-09-28 13:07:05 +01:00
charmhelpers Add xena bundles 2021-09-22 10:31:35 +01:00
files Sync charm/ceph helpers, tox, and requirements 2019-09-30 22:09:55 -05:00
hooks Make sure iscsid has a unique InitiatorName 2021-12-01 10:20:55 +00:00
lib Update tox.ini files from release-tools gold copy 2016-09-09 19:22:01 +00:00
templates Add support for configuring image volume cache 2021-09-16 15:25:13 +08:00
tests 21.10 - Release 2021-10-21 14:57:37 +01:00
unit_tests Make sure iscsid has a unique InitiatorName 2021-12-01 10:20:55 +00:00
.gitignore Switch to using zaza for functional tests 2019-05-24 06:00:09 +00:00
.gitreview 21.10 - Stable cut of charms for testing period 2021-10-13 23:19:26 +01:00
.project Merging python-redux and havana work. 2013-10-17 14:48:08 -07:00
.pydevproject Merging python-redux and havana work. 2013-10-17 14:48:08 -07:00
.stestr.conf Fix lint in unit tests re: py3-first and py2 compat 2018-11-01 21:34:52 -05:00
.zuul.yaml Added tox environment for gathering coverage 2019-03-01 11:10:26 +01:00
LICENSE Re-license charm as Apache-2.0 2016-06-28 12:09:16 +01:00
Makefile Sync helpers for 20.05 2020-05-18 14:40:01 +02:00
README.md Deprecate LVM support and add NetApp support 2021-10-01 14:46:40 -04:00
actions.yaml Add security-checklist action 2019-03-13 10:32:25 +01:00
bindep.txt Process subordinate releases packages map 2021-09-28 10:44:26 +02:00
charm-helpers-hooks.yaml 21.10 - Stable cut of charms for testing period 2021-10-13 23:19:26 +01:00
config.yaml Deprecate LVM support and add NetApp support 2021-10-01 14:46:40 -04:00
copyright Re-license charm as Apache-2.0 2016-06-28 12:09:16 +01:00
hardening.yaml Add hardening support 2016-03-31 10:43:24 +01:00
icon.svg Update charm icon 2017-08-02 18:06:14 +01:00
metadata.yaml Add impish to metadata.yaml 2021-06-03 11:09:46 +02:00
osci.yaml Add xena bundles 2021-09-22 10:31:35 +01:00
pip.sh Add xena bundles 2021-09-22 10:31:35 +01:00
requirements.txt Sync release-tools 2021-07-22 14:53:03 +02:00
revision added postgresql support 2014-03-25 11:34:12 +01:00
setup.cfg setup.cfg: Replace dashes with underscores 2021-05-28 08:39:12 +00:00
test-requirements.txt Drop creation of v2 endpoint from OpenStack Xena+ 2021-11-24 15:33:18 -05:00
tox.ini Add xena bundles 2021-09-22 10:31:35 +01:00

README.md

Overview

The cinder charm deploys Cinder, the Block Storage (volume) service for OpenStack. The charm works alongside other Juju-deployed OpenStack services.

Usage

Configuration

This section covers common and/or important configuration options. See file config.yaml for the full list of options, along with their descriptions and default values. See the Juju documentation for details on configuring applications.

block-device

Specifies the storage source. Setting this option to 'None' will allow for storage to be managed by separate charms. See sections Ceph-backed storage, LVM-backed storage, and NetApp-backed storage.

Important: The practice of setting the block-device option to a local block device is deprecated. Doing so enacts the charm's built-in support for LVM storage. This feature will soon be removed from the charm, along with the option's default value of 'sdb'.

openstack-origin

States the software sources. A common value is an OpenStack UCA release (e.g. 'cloud:bionic-ussuri' or 'cloud:focal-wallaby'). See Ubuntu Cloud Archive. The underlying host's existing apt sources will be used if this option is not specified (this behaviour can be explicitly chosen by using the value of 'distro').

Deployment

This section includes two different deployment scenarios, each of which requires these 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 is used, otherwise it is mysql-innodb-cluster. In the example deployment below mysql-innodb-cluster has been chosen.

Ceph-backed storage

Cinder can be backed by Ceph, which provides volumes with scalability and redundancy.

Note: Ceph is the recommended storage method for production Cinder deployments.

These instructions assume a pre-existing Ceph cluster.

File cinder.yaml contains the following:

    cinder:
        block-device: None

Option block-device must be set to 'None' to disable the local block device.

Here, Cinder is deployed to a container on machine '1' and related to the Ceph cluster via the cinder-ceph subordinate charm:

juju deploy --to lxd:1 --config cinder.yaml cinder
juju deploy cinder-ceph
juju add-relation cinder-ceph:storage-backend cinder:storage-backend
juju add-relation cinder-ceph:ceph ceph-mon:client
juju add-relation cinder-ceph:ceph-access nova-compute:ceph-access

Proceed with a group of commands common to both scenarios:

juju add-relation cinder:identity-service keystone:identity-service
juju add-relation cinder:cinder-volume-service nova-cloud-controller:cinder-volume-service
juju add-relation cinder:amqp rabbitmq-server:amqp

juju deploy mysql-router cinder-mysql-router
juju add-relation cinder-mysql-router:db-router mysql-innodb-cluster:db-router
juju add-relation cinder-mysql-router:shared-db cinder:shared-db

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 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 subordinate charm.

High availability

When more than one unit is deployed with the hacluster application the charm will bring up an HA active/active cluster.

There are two mutually exclusive high availability options: using virtual IP(s) or DNS. In both cases the hacluster subordinate charm is used to provide the Corosync and Pacemaker backend HA functionality.

See OpenStack high availability in the OpenStack Charms Deployment Guide for details.

Network spaces

This charm supports the use of Juju 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 section covers Juju actions supported by the charm. Actions allow specific operations to be performed on a per-unit basis. To display action descriptions run juju actions --schema cinder. If the charm is not deployed then see file actions.yaml.

  • openstack-upgrade
  • pause
  • remove-services
  • rename-volume-host
  • resume
  • security-checklist
  • volume-host-add-driver

Policy overrides

Policy overrides is an advanced feature that allows an operator to override the default policy of an OpenStack service. The policies that the service supports, the defaults it implements in its code, and the defaults that a charm may include should all be clearly understood before proceeding.

Caution: It is possible to break the system (for tenants and other services) if policies are incorrectly applied to the service.

Policy statements are placed in a YAML file. This file (or files) is then (ZIP) compressed into a single file and used as an application resource. The override is then enabled via a Boolean charm option.

Here are the essential commands (filenames are arbitrary):

zip overrides.zip override-file.yaml
juju attach-resource cinder policyd-override=overrides.zip
juju config cinder use-policyd-override=true

See Policy overrides in the OpenStack Charms Deployment Guide for a thorough treatment of this feature.

Documentation

The OpenStack Charms project maintains two documentation guides:

Bugs

Please report bugs on Launchpad.