v2.24.1 Armory Release (OSS Spinnaker™ v1.24.4)

Release notes for v2.24.1 Armory Enterprise

2021/03/16 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

To install, upgrade, or configure Armory 2.24.1, use one of the following tools:

Armory-extended Halyard 1.10 or later
Armory Operator 1.2.1 or later

Security

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

Breaking changes

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

Zombie Executions

Starting in Spinnaker 2.23.0, ManifestForceCacheRefreshTask was removed, as Kubernetes manifest related stages now do live lookups. While upgrading to Spinnaker 2.23.0 or later, if there is a running pipeline that contains a Kubernetes manifest related stage, it becomes a zombie execution. This causes Orca, Spinnaker’s orchestration service, to fail to complete any Kubernetes manifest related stage in that pipeline.

Workarounds:

To resolve the issue, cancel any zombie executions. For information about how to cancel them, see the Orca Zombie Execution runbook.

Affected versions: 2.23.0 and later

ManifestForceCacheRefreshTask removed from Orca

When you upgrade to 2.23.0 or later, you might encounter the following error:

2021-01-29 23:57:19.691 ERROR 1 --- [    scheduler-2] c.netflix.spinnaker.q.redis.RedisQueue   : Failed to read message 8f072714f1df6dbf3af93a4f4fe4cae2, requeuing...
com.fasterxml.jackson.databind.JsonMappingException: No task found for 'com.netflix.spinnaker.orca.clouddriver.tasks.manifest.ManifestForceCacheRefreshTask' (through reference chain: com.netflix.spinnaker.orca.q.RunTask["taskType"])

The ManifestForceCacheRefreshTask task is no longer a required task when deploying a manifest. In earlier releases, forcing the cache to refresh was part of the deployment process for manifests. Because of this change, if a task was running or retried before the upgrade, the error shows up in logs as an exception.

Workaround

Before starting, make sure that you have access to the Redis instance that Orca uses.

To resolve this issue, delete the message from the queue:

Verify that there are pipeline execution failure messages that contain ManifestForceCacheRefreshTask:

Redis

hgetall orca.task.queue.messages

The command returns information similar to the following:

1) "93ac65e03399a4cfd3678e1355936ab2"
2) "{\"kind\":\"runTask\",\"executionType\":\"PIPELINE\",\"executionId\":\"01EVFCCDG3Q2209E0Z1QTNC0FS\",   \"application\":\"armoryhellodeploy\",\"stageId\":\"01EVFCCDG3TJ7AFPYEJT1N8RDJ\",\"taskId\":\"5\",\"taskType\":\"com.netflix.spinnaker.   orca.clouddriver.tasks.manifest.ManifestForceCacheRefreshTask\",\"attributes\":[{\"kind\":\"attempts\",\"attempts\":1}],   \"ackTimeoutMs\":600000}"

Delete the message(s):

Redis
```
hdel orca.task.queue.messages 
```
The command returns information similar to the following:
```
93ac65e03399a4cfd3678e1355936ab2
(integer) 1
```

Known issues

Bake failures

The Packer version included with Rosco disregards package overrides that use the -var-file= option. This may cause bakes to fail.

Affected versions: 2.22.2 and later, 2.23.3 and later, 2.24.x, and 2.25.x

Lambda UI issue

There is a UI bug related to the caching agent that prevents Lambda functions from being displayed in the UI when there are no other clusters associated with the Application. In other words, in order for the function to show up in “Functions” tab, there needs to be a cluster (such as an AWS ASG/EC2 instance) deployed for that application.

Affected versions: 2.23.0 (1.23.0) and later

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

Fixed issues

Fixed an issue where pull request comments on GitHub caused the Dinghy pod for Pipelines as Code to crash or report incorrect information.

Highlighted updates

Application metrics for Canary Analysis

Improved how the Kayenta service handles data from Dynatrace. The integration now parses integer and null data points properly.

Security

Resolved CVEs.

Terraform Integration

Named Profiles for static type credentials now support using key/value pairs in a Terraform variable file. You can use these key/value pairs for configs such as secrets.

Spinnaker Community Contributions

There have also been numerous enhancements, fixes, and features across all of Spinnaker’s other services. See the Spinnaker v1.24.4 changelog for details.

Detailed updates

Bill Of Materials (BOM)

Here’s the BOM for this version.

Expand

version: 2.24.1
timestamp: "2021-03-16 11:55:29"
services:
    clouddriver:
        commit: b3e8200e
        version: 2.24.23
    deck:
        commit: 8a779fcb
        version: 2.24.3
    dinghy:
        commit: badda447
        version: 2.24.10
    echo:
        commit: 58e19e4d
        version: 2.24.11
    fiat:
        commit: 5acc8fbc
        version: 2.24.12
    front50:
        commit: 683f90b4
        version: 2.24.12
    gate:
        commit: 162f0379
        version: 2.24.14
    igor:
        commit: 0abefd92
        version: 2.24.9
    kayenta:
        commit: af2612d0
        version: 2.24.14
    monitoring-daemon:
        version: 2.24.0
    monitoring-third-party:
        version: 2.24.0
    orca:
        commit: fa3ca91a
        version: 2.24.13
    rosco:
        commit: 3e3e744c
        version: 2.24.12
    terraformer:
        commit: e2d6b847
        version: 2.24.4
dependencies:
    redis:
        version: 2:2.8.4-2
artifactSources:
    dockerRegistry: docker.io/armory

Armory

Armory Rosco - 2.24.4…2.24.12

chore(build): use armory commons bom (#185) (#186)
chore(build): backport armory-commons changes (#195)

Terraformer™ - 2.24.2…2.24.4

fix(cve): Alpine > 3.13 to fix glib and openssh cves (#328) (#329)
fix(profiles): support passing vars via TF_VAR (#339) (#341)

Armory Clouddriver - 2.24.10…2.24.23

chore(build): use Armory commons BOM, remove some unused constraints (#271) (#272)
chore(dependencies): exclude tencent, huawei, oracle, yandex, move junit/logback to bom (bp #274) (#277)
chore(build): bump google sdk to fix CVEs (#280) (#281)

Armory Orca - 2.24.5…2.24.13

chore(build): use armory commons BOM (#209)
chore(dependencies): use armory commons bom (#212) (#214)

Armory Kayenta - 2.24.7…2.24.14

chore(build): use armory commons BOM (#183) (#184)
chore(build): use armory commons bom (#192)
fix(dynatrace): fix parse of datapoints values (#204) (#205)

Dinghy™ - 2.24.5…2.24.10

feat(Post_multiple_comments_for_lengthy_logs): Breaks up long log messages into multiple GitHub comments to prevent a 422 (#347) (#348)
fix(crash_on_module_updates): adds check to verify a 200 status code on comment post prior to postin the reaction (#358) (#359)
fix(crash_on_module_updates): remove call to log.fatal() (#366) (#367)

Armory Deck - 2.24.1…2.24.3

Armory Echo - 2.24.4…2.24.11

chore(build): use armory-commons BOM (#282) (#283)
chore(dependencies): move junit/logback to bom (#285) (#287)

Armory Front50 - 2.24.4…2.24.12

chore(build): use armory commons BOM (#202) (#203)
chore(dependencies): use armory commons bom (#208) (#210)

Armory Igor - 2.24.5…2.24.9

chore(build): use armory commons bom (#177) (#178)
chore(build): rely on armory-commons (#183) (#184)

Armory Gate - 2.24.4…2.24.14

chore(dependencies): use armory commons bom (bp #223) (#226)

Armory Fiat - 2.24.4…2.24.12

chore(build): use armory commons BOM (#156) (#157)
chore(dependencies): use armory commons bom (#162) (#165)

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 16, 2021: (23e777e)