feat:Introduce 'development mode' consistently across all charts

[wilkers-steve]

Is this a bug report or feature request? (choose one): Feature request

Kubernetes Version (output of kubectl version): Any

Helm Client and Tiller Versions (output of helm version): Any

Development or Deployment Environment?: Development

Release Tag or Master:

Expected Behavior: Ability to consistently set flags across all charts for developer mode to control the number of replicas where necessary and to circumvent the need for PVCs

What Actually Happened:

How to Reproduce the Issue (as minimally as possible):

Any Additional Comments:

While some charts have the ability to set a development mode flag, others do not. In order to maintain a positive developer experience for OpenStack-Helm going forward, we should consistently apply the ability to set a development mode flag across all future charts.

[wilkers-steve]

I'll pick this up

[v1k0d3n]

sounds good, it's yours. for item #111 that's already out there...are you going to take this on, or are we asking @intlabs to rebase one more time?

[wilkers-steve]

@v1k0d3n, we can handle it however @intlabs wishes to -- if he'd like to walk it to completion, I'll exclude it from the work I'll submit against this issue. If he'd like to avoid another rebase and not finish up #111, I'll add it to the list.

[wilkers-steve]

While working on developer mode for the remainder of the service charts, I realized I wasn't entirely sure how to handle a developer mode setting for Cinder (admittedly, I'm not too familiar with Cinder) outside of spinning up a different replica count with a development flag.

Is there a way to handle developer mode here with hostPaths or emptyDirs that makes sense? I know Cinder needs a backend/backends enabled (whether it's Ceph, LVM, or something else), so would either of those two methods even work in this situation?

Tagging @v1k0d3n @alanmeadows @intlabs for this one

[alanmeadows]

@wilkers-steve I think development mode might be a good place to leverage the "Fake" backend:

https://github.com/openstack-dev/devstack/blob/master/lib/cinder_backends/fake

which simply logs the requests and allows you to create resources.

The other alternative, offering slightly more functionality (e.g. you can write bits and attach it to VMs if we eventually get nova working in development mode -- which is useful, albeit more effort to write, especially since someone pointed out this wasn't working at one point) would be using the LVM driver.

You would have to feed the fact that development mode is enabled down into the container (all the scripts are templates anyways, no big deal there), and conditionally based on that, create a temporary file, a loopback device from that file, and pvcreate/vgcreate on top of it and feed those to cinder. This does assume that lvm tools and loopback utilities are in the container image. Perhaps this would be a phase II?

If we have development mode reliance on ceph, I think it will make small footprints of this stack difficult (e.g. normal laptops).

[wilkers-steve]

@alanmeadows Thanks for the feedback. I didn't know the Fake backend existed, so it's nice to learn something new. I think using Fake for now while working on future LVM support separately for developer mode might be a good approach. Since nova and cinder seem to require more work for true development mode, I think there might be some value in handling those separately. What are your thoughts?

[alanmeadows]

I would do fake for both cinder, nova, and anything else that supports it (neuron I believe as well) as a phase one.

Phase two--separate future effort--and taking cinder as an example, would be using LVM over files or something similar as mentioned above. Glance is a perfect example of something that's in 'Phase 2' right now. You can actually store images in it because it supports simple file mode and we pass it a directory. These other services such as cinder, nova and so on are a bit more difficult to get to the same base-non-production functionality for testing so fake across the board where we can't approach it simply like glance makes good sense as a first step to me.

[v1k0d3n]

so i would split this out into two phases, documenting each and creating issues (future blueprints) to cover each scenario, similar to what Alan is eluding too.

this is what I would like to see:

phase I:

• look for fake drivers for each of the projects (cinder and nova are good examples), and use that method to start with. this is a large portion of "phase I", because development mode across the project really needs to be broken up. it's not an easy ask, but it provides a high level of value for developers. this is why we wanted it before moving to OpenStack proper. glance is actually already using local hostDir, so it meets a P2 approach.
• ensure that backends declarations are consistent for each of the charts (cinder looks good, but perhaps @alanmeadows can shed some light, i think some logical reordering could help. logically a developer would read values.yaml as: development.enabled > backends > [backend] (i.e. ceph).

development:
  enabled: true
  storage_path: 

backends:
  enabled:
  - rbd1
  - fake
  rbd1:
    secret: null
    user: "admin"
    pool: "volumes"

ceph:
  enabled: false
  monitors: []
  cinder_user: "admin"
  # a null value for the keyring will
  # attempt to use the key from
  # common/secrets/ceph-client-key
  cinder_keyring: null

fake:
  enabled: true
...
...

• a document outlining a "helm-stack" (devstack equivalent for our project), with vision = phase I approach vs future-state phase 2 (fake driver usage vs real storage attempts), examples of over-rides, etc.

phase II:

• move to simulate storage attempts for running small workloads for each of the services, expansion of driver/backend support.
• update docs for phase II vision, over-ride updates, etc.

[wilkers-steve]

@alanmeadows @v1k0d3n Thanks for the feedback. 👍

[wilkers-steve]

After chewing on this issue some more, I think we should revisit which charts we target with development mode. With glance being the exception, current development mode for our charts would just be limiting replicas of the services to 1.

Some of the services discussed here make sense (ie: storage options currently to eliminate reliance on ceph), but outside of that -- is there a real, pressing need? If LVM support gets added and nova can rely on volumes other than ceph backed storage, is there a need for a "development mode" flag, or can we handle it a different way? We could override replicas where necessary for development purposes, but some development might occur outside of Minikube where we'd like more than one replica of a service. I think it'd be better to handle this with the override approach than have a development mode that varies chart to chart, and we can document this in the docs going forward appropriately.

@v1k0d3n @alanmeadows what are your thoughts?