Create reusable image definitions

At present the definition of the seed, undercloud and overcloud
images are embedded in the varying devtest_* scripts that build the
images.

This makes the reuse of these definitions inflexible and difficult
for 3rd party tooling.

This proposal moves the definition of these base images into elements
to promote their reuse by 3rd party tools and provide an easy way
of tracking a base image and layering extra components on top.

This also enables a mechanism to have build time image verification
with regards to including all of the elements needed in a particular
image.

Change-Id: Icc99d8c396741b8cfa5e74e300dbe2e803bb9a72

specs/juno/tripleo-reusable-image-definition.rst

@@ -0,0 +1,194 @@
+..
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
+ License.
+
+ http://creativecommons.org/licenses/by/3.0/legalcode
+
+==========================
+Reusable Image Definitions
+==========================
+
+https://blueprints.launchpad.net/tripleo/+spec/tripleo-reusable-image-definition
+
+The tripleo-incubator scripts are an opinionated way of installing Openstack
+through the use of TripleO.  They define the images required, how to build those
+images, and also how to deploy those images.  If these image definitions were
+reusable and extensible outside of the tripleo-incubator scripts it would allow
+3rd party tooling to specialise the default and opinionated tripleo configuration
+and installation for specific operator use cases.
+
+Problem Description
+===================
+
+There are a large number of valid Openstack deployment scenarios.  The default
+TripleO configuration is one such scenario.  Deployers of Openstack may want to
+use that configuration, or a small variation thereof.
+
+At present the definition of the seed, undercloud and overcloud images are
+embedded in the varying devtest_* scripts that build the images.  This makes the
+reuse of these definitions inflexible and difficult for 3rd party tooling.
+
+By defining a reusable methodology for image definition the reuse of existing
+image definitions can be promoted, and by making said definition extensible will
+allow for greater sharing and reuse of stock image definitions for deploying
+known good Openstack configurations.
+
+This will also make it easier for deployers to validate their image
+configuration, as they can select from more descriptive and higher-level
+components to create their own deployment images.
+
+Proposed Change
+===============
+
+There is existing tooling in diskimage-builder that can be used for the
+definition of images, namely creating an element that has dependencies on all
+of the required elements to make that image complete and fit for purpose.
+
+This will allow reuse of image definitions as dependencies in other elements and
+also allows for customisation of images through the use of the standard
+diskimage-builder tools and mechanisms, as defined in the diskimage-builder
+README.
+
+Any deployer can then choose the base image definitions and combine them as
+dependencies in their own elements, with any changes in the elements performed
+by scripts in the depending element.
+
+Through the use of the "provides" functionality in diskimage-builder the base
+images can be made OS-agnostic (requiring an "operating-system", but not
+prescribing one), and that pattern can be reused for all of the options
+available to the consumer of the image element - the deployer.
+
+A sample implementation was prepared to show this construct:
+https://review.openstack.org/#/c/85776/3/
+
+This is an early example of the type of elements that can be created to
+represent images.
+
+Alternatives
+------------
+
+Independent configuration definitions/repositories.
+
+The configuration of images could be held in a separate repository in some other
+format.  For example currently the definition of the images is held in the
+tripleo-incubator repository as a set of arguments to diskimage-builder.  The
+definition could also be created as something like a json data file that
+described the elements and their metadata that would be read by
+diskimage-builder, or a different tool, in order to create the images required.
+
+Currently the definition of the images is not easily reusable/extensible by 3rd
+party tooling, hence this spec.
+
+If the configuration were in a separate repository or configuration directory,
+then it could potentially be reused by 3rd party tooling.  The disadvantage to
+this is that tooling would need to be created around the use of this new data
+format, and the new data format would have to be defined and unhderstood by the
+deployers, *in addition* to understanding the actual elements themselves.
+
+Security Impact
+---------------
+
+None
+
+Other End User Impact
+---------------------
+
+None
+
+Performance Impact
+------------------
+
+None
+
+Other Deployer Impact
+---------------------
+
+Discuss things that will affect how you deploy and configure OpenStack
+that have not already been mentioned, such as:
+
+* What config options are being added? Should they be more generic than
+  proposed (for example a flag that other hypervisor drivers might want to
+  implement as well)? Are the default values ones which will work well in
+  real deployments?
+
+* Is this a change that takes immediate effect after its merged, or is it
+  something that has to be explicitly enabled?
+
+* Please state anything that those doing continuous deployment, or those
+  upgrading from the previous release, need to be aware of. Also describe
+  any plans to deprecate configuration values or features.  For example, if we
+  change the directory name that instances are stored in, how do we handle
+  instance directories created before the change landed?  Do we move them?  Do
+  we have a special case in the code? Do we assume that the operator will
+  recreate all the instances in their cloud?
+
+Developer Impact
+----------------
+
+Discuss things that will affect other developers working on OpenStack.
+
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+
+Primary assignee:
+    https://launchpad.net/~jonpaul-sullivan
+
+Work Items
+----------
+
+Work items or tasks -- break the feature up into the things that need to be
+done to implement it. Those parts might end up being done by different people,
+but we're mostly trying to understand the timeline for implementation.
+
+
+Dependencies
+============
+
+* Include specific references to specs and/or blueprints in tripleo, or in other
+  projects, that this one either depends on or is related to.
+
+* If this requires functionality of another project that is not currently used
+  by Tripleo (such as the glance v2 API when we previously only required v1),
+  document that fact.
+
+* Does this feature require any new library dependencies or code otherwise not
+  included in OpenStack? Or does it depend on a specific version of library?
+
+
+Testing
+=======
+
+Please discuss how the change will be tested.
+
+Is this untestable in CI given current limitations (specific hardware /
+software configurations available)? If so, are there mitigation plans (3rd
+party testing, gate enhancements, etc).
+
+
+Documentation Impact
+====================
+
+What is the impact on the docs? Don't repeat details discussed above, but
+please reference them here.
+
+
+References
+==========
+
+Please add any useful references here. You are not required to have any
+reference. Moreover, this specification should still make sense when your
+references are unavailable. Examples of what you could include are:
+
+* Links to mailing list or IRC discussions
+
+* Links to notes from a summit session
+
+* Links to relevant research, if appropriate
+
+* Related specifications as appropriate (e.g.  if it's an EC2 thing, link the EC2 docs)
+
+* Anything else you feel it is worthwhile to refer to