Web Operations/Reference Specification/Discussion Pages/golden images

Overview

Some notes around our vision for golden images, versioning, upgrades, etc...

Golden Image

We will be baking near golden images. These are not real golden images in the sense that they will not be baked per application or per service. These will be basically simple distribution images but they will include some extra pieces. We are calling them golden images because they will include a specific release of our puppet tree. They will also have the same version number in their name. In this way we will be able to provide users of the platform with a guaranteed repeatable deployment.

Versioning

We will be versioning the entire platform, as far as practicable, to ensure repeatability in deployments. Basically this means that if a user chooses a version to deploy, they can be assured that this will be exactly the same when the go to prod, be that in one week or after several months of development.

This versioning must therefore occur at several levels. As puppet is the underlying configuration management tool, it is the logical place to start the versioning. The main ref-spec puppet tree will be tagged for release at a certain point (version). As this includes the PuppetFile, we can pin all of the underlying provider modules at a specific point within that file. Thereby ensuring that the exact same provider modules are delivered in that tagged release. Further, all of the front end modules (FEM) will be shipped in this same repository, therefore they will be pinned at that release point as well.

This entire puppet tree is baked into the aforementioned golden image at the tagged release point. This creates a method of versioning the golden images to a configuration point as well.

Currently there is one missing piece to the versioning model. We do not have a good way to version the virtual front end modules (VFEM). We have been in contact with one of the the lead HEAT developers and we are confident that we can get this piece sorted in due time. These VFEMs should actually be quite stable and therefore we are comfortable going into a v1 release without them being versioned. The plan is to take them and bundle them as the 'default' or initial release once the versioning exists.

Release numbering

The release number should be a three octet system (0.1.1). The first octet will be the major release number and will identify major changes to the system. What constitutes a major change has yet to be clearly defined. THe second octet denotes a minor release. This is intended to denote the addition of components (a new database type) or feature enhancements. The third octet is reserved for security releases. This should only be in case of a major security issue (heartblead) that requires immediate patching.

Upgrading

We will guarantee a major release will be supported for a period of time. This time has yet to be determined. There will need to be some agreement with the users of the platform that they will upgrade within a certain time. They should have upgraded prior to the version they are running reaching end of life. We need to have a discussion around what to do with non-compliant applications/users.

The intention is that users should be able to upgrade within a minor (feature enhancement) release with little issue. We should not be changing the base OS nor major packages (python versions etc) during these releases. Users should expect that a major release upgrade will likely cause breakage and require some break/fix work.

A security release is intended to be a non-optional release. There is currently no way for us to force the upgrade of even a security release as the release is tied to the image which is defined in the user controlled YAML file. This is another place we need to have an agreement with the users beforehand. Additionally we need to have a discussion to devise some policy around this to include disabling sites that are beyond some criteria. We imagine that the security team will be closely consulted and likely making the decisions around this point, but this should be determined during discussions with them.