Define how versions should be managed + Genesis Index should be contacted about genesis HOT 8 CLOSED

Proposal (to go straight into the Readme):

Version Keywords

Genesis allows you to specify some keywords for your release & stemcell
versions, and attempts to make life easier for you where it can. Here's a
run-down of the keywords, and how Genesis helps.

track

Specifying a version of track tells Genesis to fetch the latest version information
from the Genesis Index whenever it's building the manifest. This way you will always
get the latest version.

This keyword is mostly useful for keeping stemcells up-to-date, when not using the
genesis ci pipelines. When you use genesis ci, there is an automated task that
monitors stemcells and propagates upgrades to them through your infrastructure, using
explicit versions.

latest

This piggyback's on BOSH's latest version functionality. When specified, genesis
will simply pass this version on to BOSH, to let BOSH chose the latest uploaded
release/stemcell, and use that.

If the release/stemcell does not exist yet on BOSH, Genesis will contact the Genesis Index
and upload it for you, just-prior to deploying.

x.y.z

If you specify a raw version (3262.12, 241, 1.2.3), Genesis will tell BOSH to use that
version explicitly. If you specify a sha1 and URL for the release/stemcell, BOSH will
include that when it does the deploy. If you do not specify the sha1 or URL, Genesis
will contact the BOSH Director to see if it needs to upload the release using the Genesis Index to find the sha1/URL.

The Genesis Index

The Genesis Index is a service designed to make managing releases and stemcells easier.
It watches new versions of common releases and stemcells, and updates the index with
their metadata. It is only contacted under the following circumstances:

• When generating manifests for each stemcell/release that specified track as its version
• When deploying a manifest which does not have a sha1 or url attribute for a release/stemcell,
  unless that release/stemcell is already present with the correct version on the BOSH director
• When deploying a manifest which specifies latest as the version of a release/stemcell,
  and that stemcell/release is not already present on the BOSH director.

There is a wide range of commonly used releases already present in the Genesis Index.
If you need additional releases, feel free to submit a GitHub issue on the genesis-index repo.
If you have private releases that you wish to manage using the Genesis Index, or cannot
contact the public Genesis Index, you can run your own internally, and specify the $GENESIS\_INDEX
environment variable to override the default index.

from genesis.

I think this covers the most common issues/scenarios. I believe bosh-init deployments will end up always contacting the index when using latest, or if sha1/url aren't specified, since there's no director to search for a version on.

from genesis.

Looks good, with a few corrections.

Genesis does not contact BOSH to determine if the release is present or not; if no URL / SHA1 is specified for the release, Genesis will try the index to get the SHA1 / URL, even if the release has already been uploaded to the director. The BOSH CLI is what makes the final determine on uploading the release or not.

I don't believe Genesis ever contacts the index for "latest", since there is (by definition) no need to upload the release to the BOSH director. If the release isn't already on the director, the deploy will just fail.

from genesis.

It doesn't do those things now. I was approaching the doc from a "this is ideally how I would like it to work" approach.

Sent from my iPhone

On Sep 17, 2016, at 10:55 AM, James Hunt [email protected] wrote:

Looks good, with a few corrections.

Genesis does not contact BOSH to determine if the release is present or not; if no URL / SHA1 is specified for the release, Genesis will try the index to get the SHA1 / URL, even if the release has already been uploaded to the director. The BOSH CLI is what makes the final determine on uploading the release or not.

I don't believe Genesis ever contacts the index for "latest", since there is (by definition) no need to upload the release to the BOSH director. If the release isn't already on the director, the deploy will just fail.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

from genesis.

The only issue I have with this suggestion is:
* When generating manifests for each stemcell/release that specified track as its version

In the context of a genesis managed CI pipeline the track keyword should only take effect in the alpha environment (releases, stemcells) and beta (only for stemcells) otherwise un-vetted releases may end up in production.

from genesis.

@geofffranks ah, that makes more sense.

@bodymindarts is track something you really want to do in a pipeline? stemcells are pretty much orthogonal to the manifest, but releases often include incompatible changes to jobs / properties that require manual intervention to accommodate.

from genesis.

@jhunt wether or not its a good idea to use track in a pipelined context is imo another discussion. If track is a feature we are supporting we should make sure its semantics make sense in both pipelined and non-pipelined contexts. Or explicitly disallow it in pipelines if we don't want to make reasonable guarantees regarding its effects.

I would prefer supporting it in a reasonable fashion and let the end user decide if it makes sense or not to use it.

from genesis.

I agree. +1 for disallowing track in pipelines, explicitly.

from genesis.