v2.19.7 Armory Continuous Deployment Release (Spinnaker Release 1.19.5)

Release notes for Armory Continuous Deployment v2.19.7

04/20/20 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.

Breaking Changes

Required Halyard version

Armory 2.19.x requires Armory-extended Halyard 1.8.3 or later.

HTTP sessions for Gate

This version includes an upgrade to the Spring Boot dependency. This requires you to flush all the Gate sessions for your Spinnaker deployment. For more information, see Flushing Gate Sessions.

Scheduled Removal of Kubernetes V1 Provider

The Kubernetes V1 provider will be removed in Spinnaker 1.21. Please see the RFC for more details.

Breaking change: Kubernetes accounts with an unspecified providerVersion will now default to V2. Update your Halconfig to specify providerVersion: v1 for any Kubernetes accounts you are currently using with the V1 provider.

Known Issues

Dynamic Accounts for Kubernetes

Fixed in: 2.21

There is an issue with Dynamic Accounts for Kubernetes where the following issues occur:

  • Agents get removed but still run on schedule.
  • Force cache refresh times out.
  • If you have the clean up agent setup, your data randomly disappears and reappears.

These issues do not occur immediately, and you may even see modified accounts appear.

Plugins

There is a known issue with the Plugins framework in Armory 2.17.7. If you want to build or use plugins, do not use this version. Use Armory 2.17.8 or later.

Highlighted Updates

Armory

Highlighted Updates describe some of the major changes in this release. Highlights specific to Armory for this release include:

Service Accounts using Fiat

This version includes a cherry picked commit that fixes an issue with creating or updating service accounts. The issue caused pipeline permissions to not work.

Policy Engine

Armory’s Policy Engine for the SDLC now also performs Runtime validation on Spinnaker pipelines. This means that when a pipeline runs, the Policy Engine evaluates the pipeline. This validation only operates on tasks that you have explicitly created policies for. For more information, see Policy Engine.

CVEs

Addressed a number of CVEs found within the Spinnaker services.

Plugins

This release supports Plugin deployment using Armory-extended Halyard or the Armory Operator. Consult the open source Plugin docs for Halyard usage or the Plugins Operator Reference for a manifest example.

Additionally, this version of Spinnaker includes updates to how Deck is built. Previously, Deck’s builds were non-deterministic, causing issues with loading plugins into the UI. Deck’s builds are now deterministic and support UI plugins.

Managed Pipeline Templates v2 UI

Armory 2.19.x contains the latest version of Managed Pipeline Templates v2 (MPTv2), which is the default pipeline templating solution offered in Spinnaker.

Armory recommends using Armory’s Pipeline as Code feature instead of MPTv2 because it offers the following benefits:

  • Integration with GitHub, GitLab and BitBucket enabling teams to store pipelines with application code
  • Templates and access to the templates can be stored and managed separately from pipelines
  • The ability to compose complex templates and pipelines from modules

Note that Armory’s Pipeline as Code and the open source Managed Pipeline Templates are not integrated and do not work together.

By default, the MPTv2 UI is disabled in Armory 2.19.6. Leaving the UI disabled maintains the same experience you had with Armory 2.18.x (OSS 1.18.x).

If you want to enable the MPTv2 UI, see Enabling the Managed Pipeline Templates UI.

Spinnaker Community Contributions

The following highlights describe some of the major changes from the Spinnaker community for Spinnaker Release 1.19.5, which is included in this release of Armory 2.19:

Java 11

The migration to Java 11 continues. This should not affect Spinnaker users. If you extend Spinnaker, this change may affect you.

The Java 11 JRE runs Spinnaker when deployed to a Kubernetes cluster using Halyard (or if you consume the official containers in some other way). If this causes problems, or your organization isn’t ready to run Java 11 in production, you can specify deploymentEnvironment.imageVariant: JAVA8 (or UBUNTU_JAVA8) in your Halyard config. Please notify sig-platform@spinnaker.io if you run into issues and decide to downgrade.

All users need to switch to a Java 11 JRE by Spinnaker 1.21, which is scheduled to be released in early July. Please see the RFC for the full schedule and more details. We encourage everyone to start testing Spinnaker under a Java 11 JRE now in preparation for the cutover. If you have any concerns about the migration timeline, please reach out to sig-platform@spinnaker.io.

IAM service-linked roles for ECS

The ECS provider now requires IAM service-linked roles for use with ECS and Application Auto Scaling. Deployments to AWS accounts that do not already have service-linked roles for these AWS services may see failed deployments after upgrading to Spinnaker 1.19. To create the required service-linked roles, run the following:

aws iam create-service-linked-role --aws-service-name ecs.amazonaws.com
aws iam create-service-linked-role --aws-service-name ecs.application-autoscaling.amazonaws.com

Visit the ECS service-linked role documentation and the Application Auto Scaling service-linked role documentation for information on the permissions in these roles.

Changes to default settings for non-Halyard users

In order to make default settings consistent whether deploying using Halyard or manually, the following properties of Orca and Clouddriver have had their defaults changed. This change does not affect users who deploy using Halyard, as Halyard was already setting these properties to the new values.

  • Clouddriver
    • shutdown-wait-seconds, which sets the number of seconds Clouddriver waits for outstanding work to complete when shutting down, will now default to 600 seconds.
  • Orca
    • Orca will no longer consider the environment variable REDIS_URL when setting the connection to Redis.
    • The setting echo.enabled now defaults to true.
    • The bakery.extractBuildDetails setting now defaults to true.


Detailed Updates

Bill of Materials

Here’s the bom for this version.

Expand 
version: 2.19.7-rc.1
timestamp: "2020-04-21 03:33:51"
services:
  clouddriver:
    commit: ef9da881
    version: 2.19.7
  echo:
    commit: 43e1966a
    version: 2.19.8
  fiat:
    commit: 8494a0c4
    version: 2.19.5
  front50:
    commit: eaeb2a64
    version: 2.19.5
  gate:
    commit: 61291021
    version: 2.19.4
  igor:
    commit: 8cbc70d2
    version: 2.19.5
  orca:
    commit: 85dbdae9
    version: 2.19.8
  rosco:
    commit: 2bb01d9e
    version: 2.19.5
  deck:
    commit: 4f6b2719
    version: 2.19.7
  dinghy:
    commit: ef444037
    version: 2.19.5
  terraformer:
    commit: f3edd3da
    version: 1.0.6
  kayenta:
    commit: c04d2e7c
    version: 2.19.4
  monitoring-daemon:
    version: 0.16.1-7d506f0-rc1
  monitoring-third-party:
    version: 0.16.1-7d506f0-rc1
dependencies:
  redis:
    version: 2:2.8.4-2
artifactSources:
  dockerRegistry: docker.io/armory

Armory

Armory Fiat - a955c640…8494a0c4

Spinnaker Community Contributions

See the Open Source Spinnaker Release Notes for the versions included in this release:

Spinnaker Community Contributions

See the Open Source Spinnaker Release Notes for the versions included in this release:

Armory 2.19.7 cherry-picks spinnaker/fiat/pull/656, which resolves an issue with Fiat and service accounts.


Last modified March 3, 2023: (22c29bf4)