Adding storage-backend relation to subordinate changes `host` identifier of cinder globally
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Cinder Charm |
Triaged
|
Medium
|
Unassigned | ||
OpenStack Cinder-Ceph charm |
Triaged
|
Medium
|
Unassigned |
Bug Description
The `host` option is an opaque identifier. It is not necessarily a host name, FQDN, or IP address. It can also be set individually per backend. Cinder will use the value of this configuration option in combination with `volume_
The default value of `host` is the system hostname. The default value of `volume_
Once a value for the `host` identifier has been chosen it should not be changed lightly as it is referenced by consumers. In the event it is changed any already created volumes will be invalidated until their host reference is updated accordingly.
For direct attached stroage backends like `LVM` the `host` identifier should be unique and persistent on a per unit+backend basis.
For distributed storage backends like `ceph` the `host` identifier should be equal for all cinder unit+backend combinations serving the same view of the distributed storage backend.
Currently when you add a storage-backend subordinate to cinder the principal unit will set a new value for the `host` option globally. This prevents a user from using the same cinder application for serving requests for multiple backends. Examples: directly attached `LVM` and `ceph`, or multiple `ceph` clusters simultaneously.
We should stop doing this and make it the subordinates responsibility to set its per-backend `host` option when sharing configuration data with the principal unit.
summary: |
- Adding storage-backend relation to subordinate changes name of cinder - node globally + Adding storage-backend relation to subordinate changes `host` identifier + of cinder globally |
Changed in charm-cinder-ceph: | |
status: | In Progress → Triaged |
From the cinder perspective "host" option is a global option.
cinder/ common/ config. py HostAddressOpt( 'host',
default= socket. gethostname( ),
help= 'Name of this node. This can be an opaque '
'identifier. It is not necessarily a host name, '
'FQDN, or IP address.'),
cfg.
However, it can be overridden on a per-backend basis via backend_host option:
https:/ /github. com/openstack/ cinder/ blob/stable/ queens/ cinder/ cmd/volume. py#L61- L62 'backend_ host', help='Backend override of host value.') cli_opt( host_opt)
host_opt = cfg.StrOpt(
CONF.register_
https:/ /github. com/openstack/ cinder/ blob/stable/ queens/ cinder/ cmd/volume. py#L88- L91
def _launch_ service( launcher, backend): register_ opt(host_ opt, group=backend) .backend_ host
CONF.
backend_host = getattr(CONF, backend)
host = "%s@%s" % (backend_host or CONF.host, backend)
The current charm implementation relies on cinder-ceph charm populating a context and sending it to cinder via relation data. The cinder charm then renders sections received from a subordinate in a generic way - this could be utilized to properly set backend_host config in the cinder-ceph charm without modifying the cinder charm.