v2.26.1 Armory Continuous Deployment Release (Spinnaker™ v1.26.6)
2021/07/22 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.
For information about what Armory supports for this version, see the Armory Continuous Deployment v2.26 compatibility matrix.
Required Halyard or Operator version
To install, upgrade, or configure Armory 2.26.0, 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.
Security
Armory scans the codebase as we develop and release software. Contact your Armory account representative for information about CVE scans for this release.
Upcoming potential breaking change
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.
Impact
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 CD 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 CD 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.
Fix
Choose the option that best fits your environment.
Disable TLSv1.1 and enable TLSv1.2 (preferred):
See Knowledge Base articles Disabling TLS 1.1 in Spinnaker and Specifying the Protocols to be used and How to fix TLS error “Reason: extension (5) should not be presented in certificate_request”.
Add a query parameter to the MySQL JDBC URIs:
?enabledTLSProtocols=TLSv1.2
Note that this only fixes communication between Armory CD and MySQL.
See MySQL communication failure when using TSL1.1 for more information.
Breaking changes
Breaking changes are kept in this list for 3 minor versions from when the change is introduced. For example, a breaking change introduced in 2.21.0 appears in the list up to and including the 2.24.x releases. It would not appear on 2.25.x release notes.
Suffixes for the Kubernetes Run Job stage
The kubernetes.jobs.append-suffix
parameter no longer works. The removal of this parameter was previously announced as part of a breaking change in Armory 2.22.
To continue adding a random suffix to jobs created by the Kubernetes Run Job stage, use the metadata.generateName
field in your Kubernetes job manifests. For more information, see Generated values.
Kubernetes version for deployment targets
Armory CD 2.26 no longer supports Kubernetes deployment targets prior to version 1.16.
Impact
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)
Workaround
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 CD 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.
Impact
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.
Workaround
Whether or not these actions are available in the UI is controlled by the following property in settings-local.yml
:
window.spinnakerSettings.kubernetesAdHocInfraWritesEnabled = <boolean>;
This setting does not completely prevent users from modifying Kubernetes infrastructure through Armory CD. To do so, you must use the Policy Engine and write policies using the spinnaker.http.authz
package.
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 CD 2.26.0
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
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.
Workaround:
2.27.x or later: Disable artifact binding by adding the following parameter to the stage JSON: enableArtifactBinding: false
.
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
Highlighted updates
AWS Cloudwatch
You can now configure the Kayenta service to assume a role when connecting to AWS Cloudwatch:
kayenta:
aws:
enabled: true
accounts:
- name: monitoring
region: <your-region>
iamRoleArn: <your-role-ARN> # For example arn:aws:iam::042225624470:role/theRole
# iamRoleExternalId: Optional. For example 12345
iamRoleArnTarget: <your-role-ARN-target> # For example arn:aws:iam::042225624470:role/targetcloudwatchaccount
# iamRoleExternalIdTarget: <your-ExternalID> # Optional. For example 84475
supportedTypes:
- METRICS_STORE
Pipelines-as-Code
Ignore file
Pipelines-as-Code now supports using an ignore file for GitHub repos to ignore certain files in a repo that it watches. To use this feature, create a file named .dinghyignore
in the root directory of the repo.
You can add specific filenames, filepaths, or glob-style paths. For example, the following .dinghyignore
file ignores the file named README.md
, all the files in the milton
directory, and all .pdf
files:
README.md
milton/
*.pdf
JSON validation
In 2.26.0, strict JSON validation was on by default. In 2.26.1, it is now configurable as a boolean in spec.spinnakerConfig.profiles.dinghy.jsonValidationDisabled
:
spec:
spinnakerConfig:
profiles:
dinghy:
jsonValidationDisabled: <boolean>
The config is optional. If omitted, strict validation is on by default.
When strict validation is on, existing pipelines may fail if any JSON is invalid.
pipelineID
Fixed an issue where the pipelineID
function did not work, leading to situations where pipelines did not get updated after a change.
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.
Detailed updates
Bill Of Materials (BOM)
Here’s the BOM for this version.
Expand
version: 2.26.1
timestamp: "2021-07-20 19:04:54"
services:
clouddriver:
commit: 58e826ca
version: 2.26.12
deck:
commit: 09f8ec58
version: 2.26.7
dinghy:
commit: 33f6f14c
version: 2.26.6
echo:
commit: 3cdb74fa
version: 2.26.9
fiat:
commit: b2360f92
version: 2.26.10
front50:
commit: d3dfd429
version: 2.26.11
gate:
commit: ec2ae48c
version: 2.26.9
igor:
commit: a9b45bca
version: 2.26.9
kayenta:
commit: 1d27eaf7
version: 2.26.10
monitoring-daemon:
version: 2.26.0
monitoring-third-party:
version: 2.26.0
orca:
commit: 69f66bf3
version: 2.26.15
rosco:
commit: 1dfc60f1
version: 2.26.13
terraformer:
commit: "540902e6"
version: 2.26.9
dependencies:
redis:
version: 2:2.8.4-2
artifactSources:
dockerRegistry: docker.io/armory
Armory
Armory Echo - 2.26.5…2.26.9
Armory Rosco - 2.26.8…2.26.13
Armory Clouddriver - 2.26.6…2.26.12
Armory Deck - 2.26.5…2.26.7
Armory Gate - 2.26.5…2.26.9
Armory Kayenta - 2.26.5…2.26.10
- feat(cloudwatch): add assume role feat and cleanup dependencies (#233) (#270)
Armory Igor - 2.26.6…2.26.9
Dinghy™ - 2.26.1…2.26.6
- fix(local_modules_not_working_in_template_repo): updating internal bu… (backport #429) (#430)
- fix(parsing_errors_when_using_yaml): upgrade to version of OSS dinghy that includes this fix BOB-30150 (#436) (#438)
- feat(add_dinghyignore): upgrade oss dinghy version (#439) (#440)
- feat(add_flag_for_json_validation): upgrade to latest version of OSS dinghy PUX-405 (#441) (#442)
Armory Fiat - 2.26.6…2.26.10
Armory Front50 - 2.26.7…2.26.11
Armory Orca - 2.26.12…2.26.15
Terraformer™ - 2.26.3…2.26.9
Feedback
Was this page helpful?
Thank you for letting us know!
Sorry to hear that. Please tell us how we can improve.
Last modified May 26, 2023: (a7d5a9eb)