Add support for Cinder fake backend

[wilkers-steve]

Use Cinder fake backend over Ceph for developer mode. This allows
developers to create volumes and get logging information for
testing purposes

What is the purpose of this pull request?: Enable developers to use the Fake cinder backend driver for development purposes. This eliminates reliance on Ceph for development

What issue does this pull request address?: Partially addresses #258

Notes for reviewers to consider:

Specific reviewers for pull request: @alanmeadows @v1k0d3n @intlabs

[v1k0d3n]

i'd like to see what @alanmeadows recommends, but i would imagine a structure that could allow for multiple backends to be enabled simultaneously would be desired, like:

backends:
  fake:
    enabled: true
  rdb1:
    enabled: true
    secret: null
    user: "admin"
    pool: "volumes"
  lvm:
    enabled: true
...

[wilkers-steve]

I agree it looks a little unwieldy in its current state here. It can support multiple backends as is, but a developer would have to add another entry under the current 'enabled:' list. Currently there's a function in Helm-toolkit that handles dissecting these lists and entering them in the service configuration files, which relies on them being scoped how they are now. I can look into handling them in the manner you suggest because I agree, it does appear more readable.

[v1k0d3n]

yup, ok...i get it. so a good thing to do would be to document the plans for how to use backends more generally (for anything). let me come up with a doc structure that i think would cover this well, and then we can tackle it more generally. sound good?

[v1k0d3n]

i'd like to see a simpler one liner for development as an example (something cut and paste for developers), i.e.:

helm install --name cinder --set backend.fake.enabled=true --set backend.rdb1.enabled=false local/cinder --namespace=openstack

it just makes things so much easier for developers who are looking for quick cut/paste instructions.

[wilkers-steve]

Ok. Sounds good

[v1k0d3n]

@wilkers-steve what's your plans with this? i think we need to still have the fake backend; it's just not something we're using as expected. is this a correct assumption? this way developers could use openstack-helm for development of backends, etc...like you brought up the other day.

if this work is scoped small, then we can open up a separate PR for LVM. i think this is how you were going to manage these; is that a correct assumption? if that is the case, let me know when you're ready to have this reviewed and I'll look it over again.

[wilkers-steve]

After fiddling with the fake backend, I'm curious if it is necessary. From what I've seen, it's used primarily for unit testing. If a cinder developer wanted to develop a new backend, they'd do their cinder development then enable their new backend driver to test whether it works. As far as I can tell, the fake backend wouldn't be necessary here

[wilkers-steve]

The more important part for developing new backends here would be the docs you mentioned above and how to handle enabling multiple or different backends. Forgot to add that part 🙂

[v1k0d3n]

well, if you want...we can close this out in favor of the LVM piece. your call on how you want to split out or drop the work.

[wilkers-steve]

I'd be okay with dropping this PR in favor of LVM. It'll give us more functionality and shouldn't be an insurmountable amount of work

[v1k0d3n]

i'm ok with closing this in favor of switching to LVM. the main goal is to increase the capabilities of development mode, so if LVM opens that door...I'm all for it.

[v1k0d3n]

just submit an issue/PR for LVM, and document how it can be used to improve development mode.