Cinder / Nova - Select cinder backend based on nova availability zone?

Tony Pearce tony.pearce at cinglevue.com
Mon Feb 24 08:49:33 UTC 2020


Apologies in advance if this seems trivial but I am looking for some
direction on this and I may have found a bug while testing also.

Some background - I have 2 physical hosts which I am testing with (host1,
host2) and I have 2 separate cinder backends (backend1, backend2). Backend1
can only be utilised by host1. Same for backend2 - it can only be utilised
by host2. So they are paired together like: host1:backend1 host2:backend2

So I wanted to select a Cinder storage back-end based on nova availability
zone and to do this when creating an instance through horizon (not creating
a volume directly). Also I wanted to avoid the use of metadata input on
each instance create or by using metadata from images (such as
cinder_img_volume_type) [2] . Because I can foresee a necessity to then
have a number of images which reference each AZ or backend individually.


   - Is it possible to select a backend based on nova AZ? If so, could
   anyone share any resources to me that could help me understand how to
   achieve it?

Because I failed at achieving the above, I then decided to use one way
which had worked for me in the past, which was to use the image metadata
"cinder_img_volume_type". However I find that this is not working. The
“default” volume type is selected (if cinder.conf has it) or if no default,
then `__DEFAULT__` is being selected. The link at [2] states that first, a
volume type is used based on the volume type selected and if not chosen/set
then the 2nd method is "cinder_img_volume_type" from the image metadata and
then the 3rd and final is the default from cinder.conf.


I have tested with fresh deployment using Kayobe as well as RDO’s
packstack.

Openstack version is *Train*

Steps to reproduce:
1. Install packstack

2. Update cinder.conf with enabled_backends and the [backend]

3. Add the volume type to reference the backend (for reference, I call this
volume type `number-1`)

4. Upload an image and add metadata `cinder_img_volume_type` and the name
as mentioned in step 3: number-1

5. Try and create an instance using horizon. Source = image and create new
volume

6. Result = volume type / backend as chosen in the image metadata is not
used and instance goes into error status.

After fresh-deploying the RDO Packstack, I enabled debug logs and tested
again. In the cinder-api.log I see “"volume_type": null,” and then the next
debug log immediately after logged as “Create volume request body:” has
“volume_type': None”.

I was searching for a list of the supported image metadata, in case it had
changed but the pages seem empty one rocky/stein/train [3] or not yet
updated.


Selecting backend based on nova AZ::

I was searching how to achieve this and I came across this video on the
subject of AZs [1]. Although it seems only in the context of creating
volumes (not with creating instances with volume from an image, for
example).

I have tried creating a host aggregate in nova, with AZ name `host1az`.
I've also created a backend in Cinder (cinder.conf) with
`backend_availability_zone = host1az`. But this does not appear to achieve
the desired result, either and the cinder api logs are showing
“"availability_zone": null” during the volume create part of the launch
instance from Horizon.

I also tried setting RESKEY [3] in the volume type, but again similar
situation seen; although I dont think this option is the correct context
for what I am attempting.

Could anyone please nudge me in the right direction on this? Any pointers
appreciated at this point. Thanks in advance.

References:

[1] https://www.youtube.com/watch?v=a5332_Ew9JA

[2] https://docs.openstack.org/cinder/latest/cli/cli-manage-volumes.html

[3]
https://docs.openstack.org/cinder/train/contributor/api/cinder.api.schemas.volume_image_metadata.html


[4]
https://docs.openstack.org/cinder/rocky/admin/blockstorage-availability-zone-type.html


Regards,

Tony Pearce
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20200224/a9dad5bb/attachment-0001.html>


More information about the openstack-discuss mailing list