WARNING: The MEGA team has made some changes to the behaviours and requirements of this tool, we should now consider the cf-deployment README to be the official spec.
This tool will generate manifest(s) referencing the appropriate releases and stemcell, and place manifest files in a given directory. It should have informative messaging to STDOUT and STDERR, but it's just for human convenience, it's not as though the output will be redirected to a file to form a deployment manifest, or anything like that.
./tools/prepare-deployments <aws|bosh-lite|vsphere|openstack> [path_to_config_file]
The config file provides the following values:
cf
: either a path to a directory ofcf-release
, or the string"integration-latest"
etcd
: either a path to a directory ofetcd-release
, a path to a release tarball, the string"director-latest"
, or the string"integration-latest"
stemcell
: either a path to a stemcell tarball, the string"director-latest"
, or the string"integration-latest"
stubs
: a list of paths to stub filesdeployments-dir
: a path to a directory where manifests will be written
All of the above values are technically optional (even the config file itself), they have defaults, but currently no manifests will generate correctly without at least one stub.
--cf
: defaults to"integration-latest"
--etcd
: defaults to"integration-latest"
--stemcell
: defaults to"integration-latest"
--stubs
: defaults to an empty list--deployments-dir
: defaults to./outputs/manifests
- Determine release and stemcell names and versions up front, as well as URLs and SHA1s where relevant:
a. For every given release and stemcell tarball, peek inside the tarball and figure out the version. Theurl
value should be the absolute path of the file, theversion
should be the one determined by peeking, and we can provide thesha1
as well. Thename
of the stemcell should also be determined by peeking. Only accept tarball paths that are absolute. b. For every release or stemcell with the"director-latest"
value, just put"latest"
for the version, with nourl
orsha1
. For stemcells, we will guess thename
based on theinfrastructure
argument and the integration record. c. For every release or stemcell with the"integration-latest"
value:
--> When it's anything other thancf-release
, refer to the integration record incf-deployment
forversion
(as well asname
in the case of stemcell) and includeurl
andsha1
parameters as well, which should already exist in the integration record.
--> When it's cf-release, the integration record will actually have a git commit SHA; we will clone the repo to a temporary location, check out the SHA, run the./update
script (note this is specialcf-release
knowledge), and then we can treat this case the same as when given a path to a directory (see below).
d. For every release given a path to a directory, just put"create"
as theversion
. Forurl
, provide the absolute path of the directory, and don't bother withsha1
. Only accept directory paths that are absolute. - If the
--cf
argument is"integration-latest"
, clone a new copy to some temporary directory, check out the correct SHA, and run the./update
script. - Generate the manifests using the provided infrastructure, generated version/file/directory/URL stub from the previous step, and any additional passed-in stubs. Write them to the
--deployments-dir
location. NOTE: For now, this is just one cf manifest, calledcf.yml
, but I'd like to be able to split out CATS and smoke-tests manifests into separate deployments eventually.