disable cinder LVM on Openstack

charm
,
#1

Hi,

I’ve deployed the Openstack base bundle for a charmed Openstack on Ubuntu 20.04 Focal using the yoga version. I’ve noticed that for some reason an LVM backend is deployed, however, that is not what I want. I want to use a custom storage array that I’ve already configured and is working fine. How can I disable the LVM cinder backend?

itclinux@scmaas01:~$ openstack volume service list ±-----------------±--------------------------±-----±--------±------±---------------------------+ | Binary | Host | Zone | Status | State | Updated At | ±-----------------±--------------------------±-----±--------±------±---------------------------+ | cinder-volume | controller02@LVM | nova | enabled | down | 2023-07-25T16:30:51.000000 | | cinder-scheduler | controller01 | nova | enabled | down | 2023-07-25T16:30:59.000000 | | cinder-volume | controller01@LVM | nova | enabled | down | 2023-07-25T16:30:57.000000 | | cinder-scheduler | controller02 | nova | enabled | down | 2023-07-25T16:30:53.000000 | | cinder-volume | controller03@LVM | nova | enabled | down | 2023-07-25T16:30:51.000000 | | cinder-scheduler | controller03 | nova | enabled | down | 2023-07-25T16:30:53.000000 | | cinder-volume | cinder@cinder-array | nova | enabled | up | 2023-07-26T15:28:25.000000 | | cinder-scheduler | cinder | nova | enabled | up | 2023-07-26T15:28:27.000000 | ±-----------------±--------------------------±-----±--------±------±---------------------------+

#2

Remove the cinder-lvm application and the relation to it, which is:

cinder-lvm:storage-backend cinder:storage-backend
#3

but I don’t have either cinder-lvm application and the storage-backend has no relation with lvm.

Take a look:

$ juju remove-relation cinder-lvm:storage-backend cinder:storage-backend
ERROR relation matching "cinder-lvm:storage-backend cinder:storage-backend" not found (not found)
$ juju remove-application cinder-lvm
removing application cinder-lvm failed: application "cinder-lvm" not found
#4

What is the output to

juju config cinder block-device
#5 
$ juju config cinder block-device
None

it shows none but I still have the LVM backend (it shows as down).

#6

as an update, I’ve checked the /etc/cinder/cinder.conf file and didn’t find any reference to the LVM backend.

#7

Hi @carlosbravo, which backend storage charm are you using, please?

#8

Hi Carlos,

In this output the 3 hosts are reported as “down”, I have some questions

  • is it accurate that those 3 hosts are down?
  • can you share the output of “juju status”?
  • did you have LVM configured at some and you just reconfigured your system later?

Best,

#9

Hi, I’m using a custom storage backend that I’ve developed using your cookiecutter template. I have a Hitachi storage array.

#10

hello Felipe,

  • is it accurate that those 3 hosts are down?

no it isn’t Those nodes are actually up and running.

  • can you share the output of “juju status”?

` Sure, this is the link to the output. https://pastes.io/j7ai82kzn6. As an Important note, the Ceph configuration is only linked to glance with ceph-fs-gw to provide storage space for images. I’m using a storage configuration.

  • did you have LVM configured at some and you just reconfigured your system later?

No I didn’t. I deployed the cloud without a storage backend, then deployed my custom charm and did the cinder relation with that custom charm.

#11

Thanks, Carlos.

I looked into the source code of the charm and I think you may be getting into this section:

            # Use the package default backend to stop the service flapping.
            if not backends:
                backends = ['LVM']

Ref: https://opendev.org/openstack/charm-cinder/src/branch/master/hooks/cinder_contexts.py#L158

Does your custom charm relate to cinder over the storage-backend interface?. The output of juju status --relations cinder cinder-hitachie590 could give us some insights.

#12

Yes, it does relate over the storage-backend interface.

https://pastes.io/upd2hsld4o

How can I deploy my bundle without any backend or LVM so I can later on deploy my custom charm?

#13

Yes, it does relate over the storage-backend interface.

if the custom charm was deployed after (not part of the bundle), then that would be explanation why the LVM backend was enabled, and then disabled when the relation was added.

you can add your custom charm to a bundle with something like this:

applications:
...
  cinder-hitachie590:
    charm: ./cinder-hitachie590.charm
relations:
  - [ cinder-hitachie590, cinder]
...

How can I deploy my bundle without any backend or LVM so I can later on deploy my custom charm?

based on the source code I pointed out, this is not possible, the comment left in that section this is because otherwise the service crashes and gets restarted over and over again. This could be considered as a bug, feel free to file one at https://bugs.launchpad.net/charm-cinder/+filebug

#14

Thank you so much. I deployed my custom charm backend as part of the bundle and that worked perfectly and the LVM backend is gone.

#15

Excellent! And great news of doing the cinder-hitachie590 charm! Is this something you are going to add to the charmhub as a published charm?

#16

I didn’t know that was a possibility. I thought that only Canonical Charmers could do that, but I’m interested on the possibility and learning more about how charms work so if you could point me in the right direction that would be perfect.

Right now the charm shows as waiting, even though everything is working and the /etc/cinder/cinder.conf file has been properly configured.

cinder/0*                              active    idle   0         xxx.xxx.xxx.103   8776/tcp            Unit is ready
  cinder-hacluster/0*                  active    idle             xxx.xxx.xxx.103                       Unit is ready and clustered
  cinder-hitachie590/0*                waiting   idle             xxx.xxx.xxx.103                       Charm configuration in progress
  cinder-mysql-router/0*               active    idle             xxx.xxx.xxx.103                       Unit is ready
#17

I didn’t know that was a possibility.[…]

Anyone can propose new charms, see Adding a charm to the OpenStack ecosystem

You can find us in the openstack-charms at chat.charmhub.io.

Right now the charm shows as waiting, […]

You can implement a handler for the ‘update-status’ event , the handler needs to verify if everything is OK (e.g. is my payload service running?, is there a service listening in a tcp port I manage?, etc), see https://juju.is/docs/sdk/update-status-event