v2.22.2 Armory Release (OSS Spinnaker™ v1.22.2)

Release notes for Armory Enterprise v2.22.2

2020/10/21 Release Notes

Note: If you’re experiencing production issues after upgrading Spinnaker, rollback to a previous working version and please report issues to http://go.armory.io/support.

Required Halyard or Operator version

Armory Spinnaker 2.22.1 requires one of the following:

Armory Halyard 1.9.4 or later.
Armory Spinnaker Operator 1.0.3 or later.

Breaking changes

Kubernetes deployment namespace

Upgrading to 2.20x or later introduces a breaking change in the Kubernetes provider for Spinnaker. Spinnaker now correctly interprets the namespace declared in your kubeconfig file and uses that namespace. Previously, Spinnaker deployed to the default namespace called default because of an error in how Spinnaker interpreted the namespace in the Kubernetes context.

Solutions

Armory recommends using one of the following methods, which involve explicitly setting the namespace:

In your deployment manifests, declare the namespace you want to deploy to. Set to default if you want to maintain the previous behavior:

apiVersion: batch/v1
kind: Job
metadata:
 generateName: <someName>
 # Set namespace to default if you want to maintain the previous behavior.
 namespace: <targetNamespace>

In your kubeconfig, declare the namespace you want to deploy to. Set to default if you want to maintain the previous behavior:

contexts:
- context:
  cluster: <someCluster>
  # Set namespace to default if you want to maintain the previous behavior.
  namespace: <targetNamespace>

For more information, see the following links:

OSS Spinnaker issue #5731
Armory KB article

Introduced in: Armory 2.20

Suffix no longer added to jobs created by Kubernetes Run Job stage

Spinnaker no longer automatically appends a unique suffix to the name of jobs created by the Kubernetes Run Job stage. Prior to this release, if you specified metadata.name: my-job, Spinnaker updates the name to my-job-[random-string] before deploying the job to Kubernetes. As of this release, the job’s name will be passed through to Kubernetes exactly as supplied.

To continue having a random suffix added to the job name, set the metadata.generateName field instead of metadata.name, which causes the Kubernetes API to append a random suffix to the name.

This change is particularly important for users who are using the preconfigured job stage for Kubernetes or are sharing job stages among different pipelines. In these cases, jobs often running concurrently, and it is important that each job have a unique name. In order to retain the previous behavior, manually update your Kubernetes job manifests to use the generateName field.

Previously, this behavior was opt-in.

Impact

As of Armory 2.22, this behavior is the default. Users can still opt out of the new behavior by setting kubernetes.jobs.append-suffix: true in clouddriver-local.yml. This causes Spinnaker to continue to append a suffix to the name of jobs as in prior releases.

The ability to opt out of the new behavior will be removed in Armory 2.23 (OSS 1.23). The above setting will have no effect, and Spinnaker will no longer append a suffix to job names. We recommended that 2.22 users note which jobs are using the old behavior and prepare to remove the setting before upgrading to Armory 2.23 in the future.

Introduced in: Armory 2.22

Spinnaker metrics

Metrics data, specifically the metric names, for Spinnaker changed in 2.20. These changes are not backwards compatible and may result in broken third-party dashboards, such as Grafana dashboards.

Workarounds:

Observability plugin: Armory is working on updates to the Observability plugin to remedy this issue. The plugin currently supports New Relic & Prometheus. Note that this resolution requires you to make updates to use the new metric names.

For information about how to install a plugin, see Plugin Users Guide.
Update existing dashboards: Change your dashboards and alerts to use the new metric names.

Although both workarounds involve updating your dashboards to use the new metric names, Armory recommends switching to the Observability plugin. Due to changes the Spinnaker project is making, the Observability plugin provides a long-term solution.

This release note will be updated once the updated plugin is available.

Affected versions: 2.20 and later

Known issues

Orca Plugins using Plugin SDK

If you use or are developing a plugin that is deployed on Orca and injects the PluginSdks interface, do not upgrade to 2.22. There is a known issue where Orca cannot process messages in its queue, and the following error occurs:

com.fasterxml.jackson.databind.exc.InvalidTypeIdException: Could not resolve type id 'startExecution' as a subtype of `com.netflix.spinnaker.q.Message`: known type ids = []
...

This results in pipelines not starting.

No workaround exists for plugin consumers. The V2 Plugins Framework will address this issue and be available in a later Armory version.

Plugin developers targeting 2.22 have a few options. The PluginSdks interface allows developers to inject common utilities, like an HTTP client, into their plugins. Developers can supply their own implementations of these utilities instead of using PluginSdks. Alternatively, they can build a Spring-based plugin using Kork’s kork-plugins-spring-api package that relies on the parent Spinnaker service to inject these utilities.

Affected versions: 2.22.x

GCE predictive autoscaling exception

An exception occurs in the Spinnaker UI (Deck) if the GCE provider is enabled but predictive autoscaling is not enabled.

Workaround

Add the following property to your settings.js:

window.spinnakerSettings.providers.gce.feature = {};

For more information, see this OSS Pull Request: 8585.

Affected versions: 2.22.x

Spinnaker liveManifestCalls set to `true` can cause major pipeline errors

Enabling liveManifestCalls: true causes the environment to exhibit odd behaviors. Resources that have been deployed/changed in previous stages are not being taken in to consideration in current stages, leading to errors and issues in the pipeline deployment.

This can be especially detrimental to any pipelines that use a rollout strategy along with a strategy.spinnaker.io/max-version-history annotation, which causes inconsistent deployment target state as well as pipeline failures.

Workaround

Consult the KB Article detailing solutions on this issue for how to work around this issue.

Impact

This issue has existed for a while, but has only been documented recently. A fix has been added to OSS 1.23 and will be available in Armory 2.23.x once it is released.

Armory Support recommends turning off lifeManifestCalls by setting liveManifestCalls: false if you have any dynamic lookups in your pipelines.

Introduced In: OSS 1.12

Pipelines as Code fails unexpectedly when updating modules

The container for the Dinghy service that Pipelines as Code uses fails when updating pipelines using modules stored in GitHub. The error you encounter references a failure related to GitHub, such as one of the following:

422 Validation Failed [{Resource:CommitComment Field:body Code:custom Message:body is too long (maximum is 65536 characters)}]

422 No commit found for SHA: <SHA for a commit> []

This results in only some pipelines in your deployment getting updated when a module gets updated.

Workaround:

Use the arm CLI to render the JSON for your dinghyfiles.
Update pipelines manually using the UI.

Affected versions: 2.22.x, 2.23.x, 2.24.0 Fixed versions: 2.25.0

Highlighted updates

Deployment targets

Pivotal Cloud Foundry

This release includes the following improvements to the PCF provider:

Fixes a regression that caused deployments to fail
Improves performance in the Spinnaker UI when viewing PCF clusters

Security

Armory scans the codebase as we develop and release software. For information about CVE scans for this release, contact your Armory account representative.

Spinnaker community contributions

There have also been numerous enhancements, fixes and features across all of Spinnaker’s other services. See their changes here:
Spinnaker v1.22.2

Detailed Updates

Bill of Materials

Here’s the bom for this version.

Expand

version: 2.22.2
timestamp: "2020-10-21 11:45:26"
services:
    clouddriver:
        commit: dcfd57fc
        version: 2.22.11
    deck:
        commit: 3c7cd857
        version: 2.22.7
    dinghy:
        commit: ad5418ab
        version: 2.22.0
    echo:
        commit: d200e4b8
        version: 2.22.2
    fiat:
        commit: 6419cd67
        version: 2.22.3
    front50:
        commit: 703ae67d
        version: 2.22.2
    gate:
        commit: 971be7fc
        version: 2.22.3
    igor:
        commit: ebceb417
        version: 2.22.3
    kayenta:
        commit: 4ffa74d8
        version: 2.22.3
    monitoring-daemon:
        version: 2.22.0
    monitoring-third-party:
        version: 2.22.0
    orca:
        commit: d0d067ac
        version: 2.22.2
    rosco:
        commit: 72ee6ba5
        version: 2.22.5
    terraformer:
        commit: e2d395ce
        version: 2.22.2
dependencies:
    redis:
        version: 2:2.8.4-2
artifactSources:
    dockerRegistry: docker.io/armory

Armory

Armory Igor - 2.22.2…2.22.3

Armory Kayenta - 2.22.2…2.22.3

Armory Rosco - 2.22.3…2.22.5

fix(kustomize): Update kustomize with latest bug fixes (#113) (#115)

Terraformer™ - 2.22.2…2.22.2

Armory Gate - 2.22.2…2.22.3

Armory Clouddriver - 2.22.10…2.22.11

Armory Front50 - 2.22.1…2.22.2

Dinghy™ - 2.22.0…2.22.0

Armory Orca - 2.22.1…2.22.2

Armory Fiat - 2.22.2…2.22.3

Armory Deck - 2.22.5…2.22.7

fix(typo): an egregious typo in the Terraform help text (#669) (#672)

Armory Echo - 2.22.1…2.22.2

Feedback

Was this page helpful?

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.

Last modified March 4, 2021: (d84aa0d)