feat: bootstrapping framework across all OpenStack charts

[alanmeadows]

This feature requests that we support a consistent bootstrapping request framework across all charts.

Every OpenStack service has resources that can be created within the service once it is actually up. Our charts deploy very vanilla versions of services, and to be sure, this is the correct path for us. However, users wishing to deploy a functional cloud will need some basic items and we want to provide a mechanism to load the items at chart install.

A few examples:

Glance currently deploys with no images and Nova does not deploy with any usable flavors. It should contain a bootstrap section in values.yaml containing the images to inject once the glance server is up (and the appropriate job to perform the action) and Nova should come up with usable flavors for deployment.

This is just an example:

bootstrap:
 images: 
 ubuntu: 
 name: Ubuntu Precise 64-bit
 source: http://cloud-images.ubuntu.com/precise/current/precise-server-cloudimg-amd64-disk1.img
 min_disk: 20
 image_type: qcow

Nova right now has no flavors, a bootstrap section in values.yaml could create the default out of the box flavors OpenStack users expect:

bootstrap:
 flavors:
 m1.tiny:
 name: m1.tiny
 id: auto
 ram: 512
 disk: 20
 vcpus: 1

[intlabs]

In addition, there are other things we should be doing as part of the bootstrap process (off the top of my head):

• Creating and setting Cinder volume types (required for some horizon workflows)
• Loading Glance metadata schema (though we could include this in db migration)
• Create initial external network in Neutron
• Create appropriate initial user roles in Keystone (and stop using admin for service accounts!)

[wilreichert]

So as a matter of consistency is it worth applying a similar approach to the keystone chart? We've been discussing this & can see pros and cons either way. Adding bootstrap functionality means that now there's been an arbitrary determination of 'mandatory' and 'optional' configurations. One needs a nova user for a functioning system but it will operate fine without a cirros image loaded. UNLESS you want to run tempest, in which case that optional image now becomes mandatory. I want to add a selenium helm test to the horizon chart which requires a couple users to exist in keystone, those are now mandatory for us but perhaps no one else. I guess the point is that whats mandatory or not will depend on the environment, so enforcing a strict definition might not make sense.

If we were to follow the current pattern of each chart configuring only the services it needs then we'd be copying and pasting job-g-* yaml into every chart that might want a image created. Currently users are configured in each individual chart and the job-ks* pods are replicated everywhere referencing the helm-toolkit common code. It would make a fair amount of sense to consolidate all the user / role / endpoint configuration to the keystone 'bootstrap:' values.yaml along with the associated templates and pods. This would decrease the startup time for any chart depending on keystone as they would have less to setup & lower the number of overall dependencies overall across the entire system.

To simplify my lengthy blathering stream of conscious - should charts configure themselves or should charts dictate to other charts what their needs are? Doing both on a per-case definitely seems like the wrong answer.

Just thinking out-loud here, curious what others opinions are.

[jeffaugustine]

@larryrensing pointed this out as something I could look at in Openstack-Helm. Following his Nova and Glance PR as examples I have been working on a Cinder bootstrap and learning the Helm development process through it. Once I wrap my head around one I hope to knock them out fast.