v2.26.2 Armory Enterprise Release (Spinnaker™ v1.26.6)
2021/09/03 Release Notes
Required Halyard or Operator version
To install, upgrade, or configure Armory 2.26.2, use one of the following tools:
Armory-extended Halyard 1.12 or later
- 2.26.x is the last minor release that you can use Halyard to install or manage. Future releases require the Armory Operator. For more information, see Halyard Deprecation.
Armory Operator 1.2.6 or later
For information about upgrading, Operator, see Upgrade the Operator.
Armory scans the codebase as we develop and release software. For information about CVE scans for this release, see the Support Portal. Note that you must be logged in to the portal to see the information.
Java 11.0.11+, TLS 1.1 communication failure
This is an issue between Java 11.0.11 and TLSv1.1. Only installations using TLSv1.1 will encounter communication failures between services when those services upgrade to Java 11.0.11+.
TLSv1.1 was deprecated in March of 2020 and reached end-of-life in March of 2021. You should no longer be using TLSv1.1 for secure communication.
Oracle released Java 11.0.11 in April of 2021. Java 11.0.11 dropped support for TLSv1.1. See the Java release notes for details.
Any services running under Java 11.0.11+ and using TLSv1.1 will encounter a communication failure. For example, you will see a communication failure between an Armory Enterprise service running under Java 11.0.1 and MySQL 5.7 if the MySQL driver is using TLSv1.1.
The version of Java depends on the version used by the Docker container’s OS. Most Armory Enterprise services are using Alpine 3.11 or 3.12, which does not use Java 11.0.11. However, Alpine 3.11 is end-of-life in November of 2021, and 3.12 is end-of-life in May of 2022. There is no guarantee that Java 11.0.11+ won’t be added to those container images by some other manner. You should modify your TLSv1.1 environment now so you don’t encounter communication failures.
Choose the option that best fits your environment.
Disable TLSv1.1 and enable TLSv1.2 (preferred):
Add a query parameter to the MySQL JDBC URIs:
Note that this only fixes communication between Armory Enterprise and MySQL.
See MySQL communication failure when using TSL1.1 for more information.
Kubernetes version for deployment targets
Armory Enterprise 2.26 no longer supports Kubernetes deployment targets prior to version 1.16.
Any Kubernetes deployment target must run version 1.16 or higher. If you try to deploy to clusters older than 1.16, you may see errors like the following in the UI:
Additionally, errors like the following appear in the Clouddriver logs:
2021-05-04 21:17:16.032 WARN 1 --- [0.0-7002-exec-9] c.n.s.c.k.c.ManifestController : Failed to read manifest com.netflix.spinnaker.clouddriver.kubernetes.op.handler.UnsupportedVersionException: No replicaSet is supported at api version extensions/v1beta1 at com.netflix.spinnaker.clouddriver.kubernetes.op.handler.KubernetesReplicaSetHandler.status(KubernetesReplicaSetHandler.java:98) ~[clouddriver-kubernetes.jar:na]
2021-05-05 14:29:09.653 WARN 1 --- [utionAction-538] c.n.s.c.k.c.a.KubernetesCachingAgent : kubernetes/KubernetesCoreCachingAgent[1/1]: Failure adding relationships for service com.netflix.spinnaker.clouddriver.kubernetes.op.handler.UnsupportedVersionException: No replicaSet is supported at api version extensions/v1beta1 at com.netflix.spinnaker.clouddriver.kubernetes.op.handler.KubernetesReplicaSetHandler.getPodTemplateLabels(KubernetesReplicaSetHandler.java:167)
If you are affected by this change, perform the following tasks to update your applications:
- Upgrade the Kubernetes clusters that you are trying to deploy to. They must run version 1.16 or higher.
- If you have manifest files using deprecated APIs, update them to use newer APIs. For more information on which APIs are deprecated in each Kubernetes version and how to migrate, see the Kubernetes Deprecated API Migration Guide.
Introduced in: Armory 2.26.0
Kubernetes infrastructure in the UI
Starting in 2.26, the UI has been updated to more closely follow immutable infrastructure principles.
When you navigate to the Infrastructure tab in the UI for an application that has the Kubernetes provider configured, actions that change the Kubernetes infrastructure (such as Create or Delete), including Clusters, Load Balancers, and Firewalls, are no longer available.
Users do not see these actions in the UI by default. You must configure the UI to display them if you want your users to be able to perform them through the UI.
Whether or not these actions are available in the UI is controlled by the following property in
window.spinnakerSettings.kubernetesAdHocInfraWritesEnabled = <boolean>;
This setting does not completely prevent users from modifying Kubernetes infrastructure through Armory Enterprise. To do so, you must use the Policy Engine and write policies using the
If you use the Policy Engine to control which user roles can see the UI actions and be able to use them, you must set this property to
true. Setting the value to
false hides the buttons for all users regardless of whether you grant specific users access to the buttons through the Policy Engine.
This property affects Kubernetes infrastructure only. The behavior is slightly different depending on if the application has only the Kubernetes provider configured or Kubernetes and other providers, such as AWS.
If the application only has the Kubernetes provider configured, the following applies:
- When set to
true, this property causes the UI to function as it did in previous releases. This allows people to manually create and delete Kubernetes infrastructure from the UI.
- When set to
false, this property causes the actions to be unavailable to users. This prevents users from manually creating and deleting Kubernetes infrastructure from the UI. The users can still view the infrastructure but cannot make changes through the UI.
If the application includes Kubernetes and other providers, the following applies:
- When set to
true, this property causes the UI to function as it did in previous releases. This allows people to manually create and delete Kubernetes infrastructure from the UI. Users can continue to select whether they want to create Kubernetes or other infrastructure in the UI.
- When set to
false, this property causes Kubernetes to be unavailable as an option when trying to modify infrastructure from the UI. Users can still make changes to infrastructure for the application from cloud providers, such as AWS, but not Kubernetes.
Introduced in: Armory 2.26.0
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
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) - 2.26.2 Fixed version: 2.26.3
SpEL expressions and artifact binding
There is an issue where it appears that SpEL expressions are not being evaluated properly in artifact declarations (such as container images) for events such as the Deploy Manifest stage. What is actually happening is that an artifact binding is overriding the image value.
2.27.x or later: Disable artifact binding by adding the following parameter to the stage JSON:
2.26.x or later: Change the artifact binding behavior in
spec.spinnakerConfig.profiles.clouddriver (Operator) or
clouddriver-local.yml (Halyard) to the following, which causes artifacts to only bind the version when the tag is missing:
kubernetes: artifact-binding: docker-image: match-name-only
This setting only binds the version when the tag is missing, such as
image: nginx without a version number.
Affected versions: 2.26.x and later
Lambda icon missing
In the left navigation of the UI, the icon for Lambda functions is missing. This does not affect any functionality.
This release includes the following improvements for git-based artifact providers:
- The GitRepo artifact provider now supports token files. Use the
--token-file(Halyard) parameters to specify a token file.
- The GitHub, GitLab, and GitRepo artifact providers now support token files that are dynamically updated. The token file is automatically reloaded when Armory Enterprise makes a request.
Resolved an issue where the subnets and server groups were not being cached.
These improvements require version 1.0.8 of the AWS Lambda Plugin in addition to Armory Enterprise 2.26.2.
This release includes the following new features and improvements for the Lambda provider:
- Improved cache performance including fixes to cache issues found in 2.24.2
- New configuration properties that give you greater control over how Armory Enterprise behaves when connection or cache issues occur.
Configure the following properties in your Operator manifest (
spinnakerservice.yml by default). Note that all these properties are optional and use the default if omitted.
cloudDriverReadTimeout: Integer. The timeout (in seconds) when attempting to read from Lambda. (Defaults to 60 seconds.)
cloudDriverConnectTimeout: Integer. The connection timeout (in seconds) when trying to connect to AWS Lambda from Clouddriver. (Defaults to 15 seconds.)
cacheRefreshRetryWaitTime: Integer. The time (in seconds) to wait between retries when attempting to refresh the Lambda cache stored in Clouddriver. (Defaults to 15 seconds.)
cacheOnDemandRetryWaitTime: Integer. The time (in seconds) to wait between retries when attempting to refresh the cache on-demand. (Defaults to 15 seconds.)
# This example only shows the location of the properties. The rest of the manifest is omitted for brevity. spec: spinnakerConfig: profiles: orca: lambdaPluginConfig: cloudDriverReadTimeout: 30 cloudDriverConnectTimeout: 10 cacheRefreshRetryWaitTime: 10 CacheOnDemandRetryWaitTime: 10
retry.timeout: Integer. The time (in minutes) that Clouddriver will wait before timing out when attempting to connect to the Lambda client. (Defaults to 15 minutes.)
concurrency.threads: Integer. The maximum number of threads to use for calls to the Lambda client. (Defaults to 10 threads.)
# This example only shows the location of the properties. The rest of the manifest is omitted for brevity. spec: spinnakerConfig: profiles: clouddriver: aws: enabled: true lambda: enabled: true retry: timeout: 10 concurrency: threads: 5
Pipelines as Code
Strict JSON Validation
Pipelines as Code (PaC) will now attempt a strict JSON validation of template modules and pipelines to catch certain syntactical errors sooner. This behavior may break existing users that make heavy use of template language constructs. If you find that behavior has changed and need to revert to the previous parsing behavior, add the
jsonValidationDisabled config to your PaC profile:
spec: spinnakerConfig: profiles: dinghy: jsonValidationDisabled: true
Event notifications honor global config
PaC will now honor configurations that define a self-hosted GitHub Enterprise instance when sending GitHub notifications. No configuration change is necessary for this fix to take effect.
Spinnaker Community Contributions
There have also been numerous enhancements, fixes, and features across all of Spinnaker’s other services. See the Spinnaker v1.26.6 changelog for details.
Bill Of Materials (BOM)
Here’s the BOM for this version.
version: 2.26.2 timestamp: "2021-09-02 18:30:45" services: clouddriver: commit: 942f74be6aa77ebd34f9183437171848e3b9fd35 version: 2.26.19 deck: commit: a2296787ab03efc53c85d03cbf8eecddedab6094 version: 2.26.9 dinghy: commit: 0796be13e88a77c72d94d4e0538a4fab152366b8 version: 2.26.10 echo: commit: b2f76d93f06a0434987fb00daa77a22396c54658 version: 2.26.10 fiat: commit: 6aba766ef74c6fe186d7f047095a775936bef71f version: 2.26.11 front50: commit: 8bdd585434b9bde9834bf580d96fdd42d12dc933 version: 2.26.12 gate: commit: 1d66c8a302ed4bf7ad07ce3944b7d7e43baae0a0 version: 2.26.10 igor: commit: 4f76b327913693263e18a670dc8782d77bbc8ee1 version: 2.26.10 kayenta: commit: 4f668d1297a5d205d516667c1af6902d0d9f380f version: 2.26.11 monitoring-daemon: version: 2.26.0 monitoring-third-party: version: 2.26.0 orca: commit: 6b547ff4ac81742d1c4cb7fab713a16f6deefd34 version: 2.26.16 rosco: commit: 1dfc60f1f70ccdadc2cc03ff9f27b5ca39bb9c39 version: 2.26.14 terraformer: commit: d20745f6ac1fb87b876dbd255b0b26004fb0341a version: 2.26.12 dependencies: redis: version: 2:2.8.4-2 artifactSources: dockerRegistry: docker.io/armory
Armory Fiat - 2.26.10…2.26.11
Armory Front50 - 2.26.11…2.26.12
Terraformer™ - 2.26.9…2.26.12
Armory Clouddriver - 2.26.12…2.26.19
- chore(cd): update base service version to clouddriver:2021.07.28.19.49.01.release-1.26.x (#381)
- chore(cd): update base service version to clouddriver:2021.07.28.23.39.00.release-1.26.x (#382)
- chore(cd): update base service version to clouddriver:2021.07.29.00.03.42.release-1.26.x (#383)
- chore(cd): update base service version to clouddriver:2021.07.29.00.21.10.release-1.26.x (#384)
- chore(cd): update base service version to clouddriver:2021.08.17.07.55.22.release-1.26.x (#396)
- chore(cd): update base service version to clouddriver:2021.08.18.19.46.18.release-1.26.x (#397)
Armory Deck - 2.26.7…2.26.9
- chore(cd): update base deck version to 2021.0.0-20210820171135.release-1.26.x (#1112)
Armory Rosco - 2.26.13…2.26.14
Armory Igor - 2.26.9…2.26.10
Armory Gate - 2.26.9…2.26.10
Armory Kayenta - 2.26.10…2.26.11
Dinghy™ - 2.26.6…2.26.10
- fix(notif): honor github endpoint in notifier constructor (backport #447) (#448)
- fix(build): add dinghy to stackfile (#449)
Armory Orca - 2.26.15…2.26.16
- chore(cd): update base orca version to 2021.08.17.08.55.02.release-1.26.x (#354)
Armory Echo - 2.26.9…2.26.10
Was this page helpful?
Thank you for letting us know!
Sorry to hear that. Please tell us how we can improve.
Last modified April 12, 2022: (24a04f9a)