v3.0.12

Bug Fixes

• Fixed a bug where pipeline deploys would block on outdated releases. When
  using the genesis deploy command, you can pass in the --yes option to
  automatically answer "yes" to all prompts, including setting the BOSH_NON_INTERACTIVE
  environment variable to "true" so that BOSH would also not prompt.
  However, only the BOSH_NON_INTERACTIVE environment variable was being set, but
  not bypassing the other confirmation prompts in Genesis. This has been fixed.

v3.0.11

Bug Fixes

• Fixed detection of Perl-based hooks. This was broken when Perl-based addon hook support was added.

Pipeline Improvements and Bug Fixes

• These were ported forward from 2.8.13 to resolve some issues with the Genesis deployment pipelines:

  • The pipelines have removed support for hipchat and stride messaging, but since these services have been shut down by their provider (Atlassian) ages ago, no one should still be using them

  • Switched the default pipeline task image to genesiscommunity/concourse from starkandwayne/concourse. This is to reflect the new location of the official Concourse task image.

  • The pipeline now has a new key, require-passed-caches, which is a boolean value. If true, the pipeline will require that the previous environment successfully deployed before deploying the next environment (the classic and currently default behavior).

    If set to false, the pipeline will be loosely coupled to the previous environment deployment, relying on the updates it does to the cache in the git resource to trigger the next environment. This will become the default behavior in the future, but for now it is opt-in.

    The reason for this change is because previously the pipeline would push versions to the passed cache resource that would not actually satisfy the file path updates that it filters on, meaning that if the configuration of the resource changes, the versions would not be detected as a passed resource, and the pipeline would not allow the next environment to deploy.

  • Fixes the generation of the cache resource in the pipeline definition. The previous implementation was using the input to the bosh-deploy task, but that wasn't available in the generate-cache task, but instead got the previous cache passed in as the 'out' input (confusing, I know).

  • This also triggers a check of the cache resources for each following environment, so changes pushed to git that match the file filters on the caches will be immediately available to the next environment, rather than waiting for the resource check period to expire.

  • Added version_depth to git resource in ci.yml. This allows for retrieving more than one commit from the git repository. This is important in the case where the git resource gets reset due to its configuration changing, such as rotating credentials, and the pipeline losing references to commits that last passed the various bosh-deployment jobs.

v2.8.13

This release is all about the Deployment Pipelines

"Breaking" Changes

• The pipelines have removed support for hipchat and stride messaging, but since these services have been shut down by their provider (Atlassian) ages ago, no one should still be using them

Bug Fixes

• Switched the default pipeline task image to genesiscommunity/concourse from starkandwayne/concourse. This is to reflect the new location of the official Concourse task image.

• The pipeline now has a new key, require-passed-caches, which is a boolean value. If true, the pipeline will require that the previous environment successfully deployed before deploying the next environment (the classic and currently default behavior).

  If set to false, the pipeline will be loosely coupled to the previous environment deployment, relying on the updates it does to the cache in the git resource to trigger the next environment. This will become the default behavior in the future, but for now it is opt-in.

  The reason for this change is because previously the pipeline would push versions to the passed cache resource that would not actually satisfy the file path updates that it filters on, meaning that if the configuration of the resource changes, the versions would not be detected as a passed resource, and the pipeline would not allow the next environment to deploy.

• Fixes the generation of the cache resource in the pipeline definition. The previous implementation was using the input to the bosh-deploy task, but that wasn't available in the generate-cache task, but instead got the previous cache passed in as the 'out' input (confusing, I know).

• This also triggers a check of the cache resources for each following environment, so changes pushed to git that match the file filters on the caches will be immediately available to the next environment, rather than waiting for the resource check period to expire.

Improvements

• Added version_depth to git resource in ci.yml. This allows for retrieving more than one commit from the git repository. This is important in the case where the git resource gets reset due to its configuration changing, such as rotating credentials, and the pipeline losing references to commits that last passed the various bosh-deployment jobs.

v3.0.10

Improvements

• Added genesis secrets command to list secrets in an environment with
  optional filtering. If no paths are specified, all secrets will be
  listed. If filters are specified, only secrets that match the filter
  will be listed. Filters can be a full or partial path, a property
  expression, or a regular expression.

  The command supports the --verbose option to list each item, with
  its associated metadata. The --relative option will list the secrets
  relative to the secrets path, rather than the full path. The --json
  option will return the secrets in JSON array format. If the
  --verbose option is specified, the JSON will include the metadata
  for each secret as an array of hash objects. It will also include the
  value of the secret if the --verbose option is specified more than
  once.

v3.0.9

Bug Fixes

• Genesis will no longer try to build the manifest if the check for
  prerequisites fails, such as cloud config or secrets are missing.

• When running compile-kit (ck) from a deployments directory, it would
  look in the dev directory for the kit contents. However, if the dev
  directory was a symlink, it would not follow the correctly dereference
  the symlink, resulting in a compiled kit that just contained a symlink.

• This fixes a bug where when not using the self-signed haproxy certs in the cf
  kit, the user would be prompted for the haproxy_ca:certificate and
  haproxy_ca:key secrets, even though they are not used.

  The code that accepted the user input was also broken, and did not
  store the user input correctly.

• The upstream cf-app-autoscaler does not specify alternative names for
  the certificate, so we need to use the common name as the only
  alternative name.

• Fixes issue when generating a self-signed certificate, the CA
  certificate was not being returned.

Improvements

• The upstream autoscaler uses an esoteric syntax for variable
  references that prefixes the variable name with a ! after the double
  parenthesis. This change allows the vaultification process to detect
  and handle these references.

• If using search target mode, and you provide an exact match to the
  desired deployment name, it will now only match that deployment
  instead of listing all deployments that contain the given name. If
  still using the -deployments suffix, this will be considered an exact
  match without having to provide the suffix.

  Deployment matches that contain wildcards will still list all matching
  deployments.

v3.0.8

Bug Fixes

• When entombment was added, we spawned a local vault to store the
  credhub references to the secrets, so that spruce would merge the
  references into the manifest instead of the actual secrets. This
  had the side effect of changing the system safe target to the local
  vault, which could cause issues if the user ran another genesis
  command while the local vault was running, which unfortunately was
  probable because it was left running across the deploy command which
  can take hours to complete.

  This change resolves the issue in two ways:

  • The local vault is now shut down after the manifest is merged, which
    takes only a few seconds usually, and no longer continues existing
    across the deploy command.

  • The default safe target is immediately reset to the previous target
    after the local vault is started, so that the system target is not
    altered by the local vault. This happens in less than a few milliseconds.

v3.0.7

Bug Fixes

• Added missing credhub root path when the genesis.bosh_env is set in the environment YAML file. This resolves the uninitialized value in concatenation error when reading or writing credhub secrets.

v3.0.6

Bug Fixes

• Honour the exodus vault and path supplied as part of the bosh_env when accessing the exodus data for a bosh director or credhub instance of the parent (director) environment. This allows for the exodus data to be stored in a different vault than the environment's vault.

• There were some internal mismatches in the path handling for Vault get/set/has operations. This was causing some issues with paths that had double slashes in them. This has been fixed.

• Credhub doesn't have crl or serial values for CAs, so we no longer require them when using Credhub as a source.

Improvements

• When using genesis edit, if you specify a kit that is not available locally, you will now be prompted to download it. This will allow you to continue editing the environment file without having to abort, manually download the kit, and then re-run the genesis edit command.

v3.0.6-rc.1

This is a prerelease - please see commit messages for changes

v3.0.5

Bug Fixes

• Fix x509 import from credhub when the certificate is a CA. The import
  was failing because the stored value was being lost when the
  certificate was reloaded after generating the serial and crl, which is
  missing from the credhub response.

Improvements

• Allow genesis.minimum_version to be used as an alias for
  genesis.min_version. While this does allow for a more natural
  use of language, please be aware that the genesis.min_version
  key is still the canonical key, and if present in the hierarchy,
  will take precedence over genesis.minimum_version.

• When using search mode targeting (i.e. genesis @<env>[:<type>]), the
  default bosh target is now set to parent if a type is specified, and self
  if no type is specified because not specifying the type implies that the
  target is the bosh director of the environment being targeted, whereas
  if a type is specified, the target is the deployment, and thus the
  bosh director desired is the parent of the deployment.