Volumes can't be managed (eg. attached) if the cinder-volume host which created them first becomes unavailable

Correct, this is by design at the moment. H/A (active/active or active/passive) volume manager has been talked about but not yet done.

There's a hack where you can force the host field of two volume-manager services to be the same and you sort of get H/A, but this is not a supported/recommended configuration. Google 'ceph cinder H/A' to find details on the hack, if memory serves

Also see https://review.openstack.org/#/c/95022/ which provides support for 'host' customization.

Giulio is correct on that being the host field override review. This will work with some drivers but not with others, and I don't believe there is much/any active testing of this currently. YMMV.

@Duncan
Just curious what you mean by "not a supported/recommended configuration"? In what way is it not supported or recommended? Seems like a great way to achieve the goal if you've set things up properly. Or are you talking about the hack prior to that patch landing (the old DB hack method)?

@john-griffith

As an example, any driver that rely on the locking decorators to provide mutual exclusion on accesses to their backend will suddenly find that doesn't work.

This is a relatively new feature and the sort of bugs it causes are the sort that only show up after lots of run-time. I'm sure some drivers will be absolutely fine, while others might not be, and it changes assumptions that were true at the time drivers were written... it will cause issues with LVM and a shared disk array for a concrete example, since nothing stops two managers trying to update the metadata at the same time, but that bug might not show up in basic testing.

I'm trying to think of a softer version of 'not supported / recommended', but can't come up with a good phrase.

@john-griffith

I've been explaining this problem for sometime now, recently on the phone with you before the summit, and have brought up ideas of using a ring solution to assign things out from the scheduler to help.

I think Harlow is onto a more long term solution though.

https://review.openstack.org/#/c/95037/12

hi Duncan, Mike, just to make sure, are there alternatives to the proposed "host field customization" setting to deploy cinder with some level of redundancy?

I understand there could be issues in an active/active configuration where nodes are not synced on the status of the resources but, do you see any issue with an active/standby configuration?

Giulio, not currently. I have ideas on improving this, but the last time I brought it up, John was concerned on how this fits with lvm driver and the volume group being on the same machine as the cinder-volume machine. I would instead like it so the scheduler just selects a host at the time it picks something from the message queue based on a quick hash ring calculation.

Doing active/passive is hard to get right without using something like pacemaker and STONITH to avoid syncronisation issues, and you can successfully use pacemaker right now with what we have (and a dual interface jbod or similar shared storage).

Related to https://blueprints.launchpad.net/cinder/+spec/cinder-state-enforcer

Closing stale bug. If this is still an issue please reopen.