docs(fix): change red/black to blue/green (#333)

* docs(fix): change red/black to blue/green

* commit to trigger Netlify build

* add migration details to changelog

README.md

@@ -141,3 +141,4 @@ text = "Spinnaker Summit is co-located with KubeCon this year! Join us on Oct 23
 ctaLink = "http://go.armory.io/ss22"
 ctaText = "Register"
 label = "UPCOMING EVENT"
+

content/en/changelogs/1.30.0-changelog.md

@@ -63,6 +63,7 @@ If you have a pipeline with multiple triggers using different artifact constrain
 
 ![Artifact constraints](../assets/1.30.0/artifact_constraints.png)
 
+
 In this example, even though each trigger has its own artifact(s) defined, when one of the artifacts is present, all of the defined artifact constraints on all triggers are evaluated. If _any_ of them are missing, the pipeline will not trigger. This is [fixed](https://github.com/spinnaker/orca/pull/4322) in Spinnaker 1.30 to only consider the artifacts that are defined on the triggered trigger (there's [an exeption](https://github.com/spinnaker/orca/pull/4397/files#diff-b25c50ecaceee2f8b0ae1ddc77fc92d48d16fb7ff9d15d27612685f1985b2a1eR241-R243) for artifacts that have defined a default artifact or use prior execution; they will always be considered). If you've relied on this bug, you'll need to add manually add all the artifact constraints to all triggers to replicate the previous behavior.
 
 #### Binding inline artifacts
@@ -103,12 +104,18 @@ With https://github.com/spinnaker/clouddriver/pull/5846 and https://github.com/s
 
 ### Kubernetes
 
-Users coming to Spinnaker are now more familiar with Blue/Green industry terminology than the Netflix specific phrasing Red/Black
+Users coming to Spinnaker are now more familiar with Blue/Green industry terminology than the Netflix-specific phrasing Red/Black.
 
 - The Red/Black rollout strategy is marked as deprecated in the UI. Change done [here](https://github.com/spinnaker/deck/pull/9911)
-- A Blue/Green rollout strategy is added that is functionally equivalent to the Red/Black rollout strategy. Changes done in [clouddriver](https://github.com/spinnaker/clouddriver/pull/5811) and [orca](https://github.com/spinnaker/orca/pull/4332)
+- A Blue/Green rollout strategy is added that is functionally equivalent to the Red/Black rollout strategy. Changes done in [Clouddriver](https://github.com/spinnaker/clouddriver/pull/5811) and [Orca](https://github.com/spinnaker/orca/pull/4332)
 - Introduce a pipeline validator in Front50 that validates if red/black is used when creating/updating a Kubernetes pipeline. For now, it is logging a warning, but it will fail when we remove the red/black Kubernetes traffic management strategy. Change done [here](https://github.com/spinnaker/front50/pull/1176)
 
+**Red/Black to Blue/Green migration details**: 
+
+- Front50 already supports migrations but **you need to be enable it by adding `migrations.enabled=true` in your Front50 config**. When Front50 starts, it automatically migrates existing pipelines using red/black to blue/green.
+- If you do not enable migration, red/black continues to work until the Spinnaker community decides to remove red/black.
+
+
 ### Gate
 
 https://github.com/spinnaker/gate/pull/1610 expands support for adding request headers to the response header. Previously limited to `X-SPINNAKER-REQUEST-ID`, it's now possible to specify any fields with a `X-SPINNAKER` prefix via the new `interceptors.responseHeader.fields` configuration property. The default value is `X-SPINNAKER-REQUEST-ID` to preserve the previous functionality.

content/en/docs/concepts/_index.md

@@ -109,7 +109,7 @@ A *Task* in Spinnaker is an automatic function to perform.
 
 ![](deployment-strategies.png)
 
-Spinnaker treats cloud-native deployment strategies as first class constructs, handling the underlying orchestration such as verifying health checks, disabling old server groups and enabling new server groups. Spinnaker supports the red/black (a.k.a. blue/green) strategy, with rolling red/black and canary strategies in active development.
+Spinnaker treats cloud-native deployment strategies as first class constructs, handling the underlying orchestration such as verifying health checks, disabling old server groups and enabling new server groups. Spinnaker supports the blue/green strategy, with rolling blue/green and canary strategies in active development.
 
 > Learn more about deployment management on the [Pipelines](/docs/concepts/pipelines/) page.
 
@@ -121,11 +121,11 @@ format.
 
 It allows you to declare the _desired state_ of your application in terms of logical _environments_
 (think `test` and `prod`) where your cloud infrastructure resources exist (e.g. compute clusters),
-and where your _software artifacts_ (think Debian package or Docker image) are deployed. 
+and where your _software artifacts_ (think Debian package or Docker image) are deployed.
 Spinnaker automatically detects when a new version of your code is available for deployment and
 satisfies any deployment constraints you may have configured, or when your infrastructure resources
-diverge from the desired state, and acts upon that information to reconcile the current with the 
-desired state. 
+diverge from the desired state, and acts upon that information to reconcile the current with the
+desired state.
 
 For more details on the inspiration and guiding principles behind
 Managed Delivery, check out [our blog](https://blog.spinnaker.io/managed-delivery-evolving-continuous-delivery-at-netflix-eb74877fb33c),

content/en/docs/concepts/pipelines/_index.md

@@ -19,13 +19,13 @@ You can view pipeline execution history, which serves as a means to introspect d
 
 ![](pipelines.png)
 
-Automation does not end with orchestrating only the high-level steps of your release process. Each of these operational steps often corresponds to a sequence of calls to the cloud platform, each of which needs to be remediated in failure scenarios. The red/black Deploy stage is an example of how Spinnaker fully supports this notion:
+Automation does not end with orchestrating only the high-level steps of your release process. Each of these operational steps often corresponds to a sequence of calls to the cloud platform, each of which needs to be remediated in failure scenarios. The Blue/Green Deploy stage is an example of how Spinnaker fully supports this notion:
 
 ![](pipeline-tasks.png)
 
-* The Red/Black Deploy stage in Spinnaker actually entails a sequence of steps
+* The Blue/Green Deploy stage in Spinnaker actually entails a sequence of steps
 
-* Each given step is actually a set of tasks that need polling, remediation to ensure requisite state is reached prior to proceeding
+* Each given step is actually a set of tasks that need polling; remediation to ensure requisite state is reached prior to proceeding
 
 * A given task often entails multiple API calls to the specific cloud platform, cognizant of expected response codes and remediating actions in failure
 

content/en/docs/guides/tutorials/codelabs/gce-source-to-prod/index.md

@@ -6,7 +6,7 @@ description: >
 ---
 
 
-In this codelab, you will create a cohesive workflow which takes source code and builds, tests and promotes it to production. You can also watch a video of this codelab in this [Youtube playlist](https://www.youtube.com/watch?v=N9VnJlKn734&list=PL4yLrwUObNkttE526AAj_ykc5UlIPjz8m&index=1).
+In this codelab, you create a cohesive workflow which takes source code and builds, tests and promotes it to production. You can also watch a video of this codelab in this [Youtube playlist](https://www.youtube.com/watch?v=N9VnJlKn734&list=PL4yLrwUObNkttE526AAj_ykc5UlIPjz8m&index=1).
 
 This will be accomplished via 3 pipelines:
 
@@ -311,7 +311,7 @@ We deploy the image that was picked, to the prod cluster.
 * In the *Server group* section, click *Add server group*.
 * In the dialog that appears, click *Continue without a template*.
 * In the Basic Settings section, enter "prod" in the *Stack* field.
-* For Strategy, select “Red/Black”.
+* For Strategy, select “Red/Black”. Note: Blue/Green replaces Red/Black in Spinnaker v1.30+.
 * Enter "2" as the *Maximum number of server groups to leave*
 * In the Load Balancers section, add your load balancer ("codelab-prod").
 * and click the *Instance Type* tab on the left.
@@ -340,13 +340,13 @@ In the CLUSTERS tab, you can see that a server group has been deployed to the pr
 
 ![](2-clusters.png)
 
-Because we selected the red/black deployment strategy for the deployment, there should always be only one enabled/active server group resident in the prod cluster cluster, with previous ones disabled (grey), even after successive runs of this pipeline. Try it out by manually invoking the promotion pipeline again.
+Because we selected the red/black (blue/green) deployment strategy for the deployment, there should always be only one enabled/active server group resident in the prod cluster cluster, with previous ones disabled (grey), even after successive runs of this pipeline. Try it out by manually invoking the promotion pipeline again.
 
 ## Extra stuff
 
 ### Roll back
 
-Sometimes things go wrong and you need to roll prod back to the previous release. We employed the red/black strategy, which disables the previous server group. In practice, this is disassociating the server group from the load balancer so it takes no traffic, while keeping the nodes in the server group up, standing by.
+Sometimes things go wrong and you need to roll prod back to the previous release. We employed the red/black (blue/green) strategy, which disables the previous server group. In practice, this is disassociating the server group from the load balancer so it takes no traffic, while keeping the nodes in the server group up, standing by.
 
 To roll back back to the previous server group, first kick off another instance of the Promote to Prod pipeline so that you have a previous disabled server group in the PROD cluster to roll back to. When this pipeline completes, navigate to the CLUSTERS tab and click the active server group.
 

content/en/docs/guides/tutorials/codelabs/oci-source-to-prod/index.md

@@ -293,7 +293,9 @@ The second pipeline, named “Validate Test”, is a simple one-stage placeholde
 ![](2-workflow.png)
 
 
-Furthermore, we configure the prod deployment to implement the red/black strategy (a.k.a. blue/green), which means that upon verifying health of the new server group it will immediately disable the previous server group in the same cluster. Here we disable rather than destroy, so that rollbacks can be quickly accomplished simply by re-enabling the old server group.
+Furthermore, you configure the prod deployment to implement the red/black (blue/green) strategy, which means that upon verifying health of the new server group, Spinnaker immediately disables the previous server group in the same cluster. Here you disable rather than destroy, so that rollbacks can be quickly accomplished simply by re-enabling the old server group.
+
+Note: Blue/Green replaces Red/Black in Spinnaker v1.30+.
 
 ### Set up pipeline: “Validate Test”
 

content/en/docs/guides/tutorials/codelabs/safe-deployments/index.md

@@ -31,7 +31,7 @@ Clone this server group:
 
 1. Select the server group
 1. Click on _actions_, then select _clone server_ group in the dropdown.
-1. In the new dialog, select _Red/Black push_ as the strategy.
+1. In the new dialog, select _Red/Black push_ (or Blue/Green push) as the strategy. (Note: Blue/Green replaces Red/Black in Spinnaker v1.30+.)
 1. Click _CREATE_.
 
 ![](images/rollback2.png)

content/en/docs/guides/user/kubernetes-v2/rollout-strategies/index.md

@@ -2,14 +2,13 @@
 title: "Rollout Strategies"
 linkTitle: "Rollout Strategies"
 description: >
- Use a dark, Highlander, or red/black rollout strategy in the Kubernetes provider.
+ Use a dark, Highlander, or blue/green rollout strategy in the Kubernetes provider.
 ---
 
 This guide describes how to take advantage of the
-[Kubernetes](/docs/setup/install/providers/kubernetes-v2) provider's first-class support
-for common rollout strategies, including dark, highlander, and red/black rollouts.
+[Kubernetes](/docs/setup/install/providers/kubernetes-v2) provider's first-class support for common rollout strategies, including dark, highlander, and blue/green rollouts.
 
-> **Note:** The implementation of these rollout strategies currently leverages Spinnaker's existing [traffic management strategy](/docs/guides/user/kubernetes-v2/traffic-management/) and so is [valid for ReplicaSets only](/docs/guides/user/kubernetes-v2/traffic-management/#you-must-use-replica-sets).
+>The implementation of these rollout strategies currently leverages Spinnaker's existing traffic management strategy and is valid for ReplicaSets only. See [traffic management]({{< ref "docs/guides/user/kubernetes-v2/traffic-management/index.md" >}}) for more information.
 
 ## Rollout Strategy Options
 
@@ -65,18 +64,17 @@ Example configuration:
 
 {{< figure src="./highlander.png" >}}
 
-### Red/Black Rollouts
+### Red/Black (Blue/Green) Rollouts
 
-Use a red/black rollout to deploy a new version of your application alongside the existing
-version(s), send client traffic to the new version, and then disable existing versions
-in the cluster.
+Use a red/black (blue/green) rollout to deploy a new version of your application alongside the existing version(s), send client traffic to the new version, and then disable existing versions in the cluster.
 
 Optionally, add subsequent Destroy (Manifest) stages to clean up any unwanted workloads in the
 cluster.
 
-Alternately, easily roll back to a previous version by configuring an Enable (Manifest) stage or
-using an ad-hoc Enable operation from the Clusters tab.
+Alternately, easily roll back to a previous version by configuring an Enable (Manifest) stage or using an ad-hoc Enable operation from the Clusters tab.
 
 Example configuration:
 
 {{< figure src="./redblack.png" >}}
+
+>Blue/Green replaces Red/Black in Spinnaker v1.30+.

content/en/docs/reference/pipeline/stages/_index.md

@@ -56,10 +56,7 @@ any of the properties of the original Server Group when creating the new one.
 
 ### Deploy
 Deploy the previously baked or found image using the specified deployment
-strategy. Spinnaker provides built-in support for both red/black (also known as
-blue/green) and Highlander deployment strategies. You can also choose to deploy
-with no impact on existing Server Groups, or build your own custom deployment
-strategy.
+strategy. Spinnaker provides built-in support for both blue/green (formerly known as red/black) and Highlander deployment strategies. You can also choose to deploy with no impact on existing Server Groups, or build your own custom deployment strategy.
 
 ### Destroy Server Group
 Delete a Server Group and its resources from the specified Cluster. You must

content/en/docs/reference/providers/kubernetes.md

@@ -5,7 +5,7 @@ description: Learn how Spinnaker concepts map to Kubernetes.
 ---
 
 > ⚠️ Spinnaker's legacy Kubernetes provider (V1) is [scheduled for removal](https://github.com/spinnaker/governance/blob/master/rfc/eol_kubernetes_v1.md) in Spinnaker 1.21.
-> We recommend using the [standard provider (V2)](/docs/reference/providers/kubernetes-v2) instead. 
+> We recommend using the [standard provider (V2)](/docs/reference/providers/kubernetes-v2) instead.
 
 If you are not familiar with Kubernetes or some of the Kubernetes terminology used below, please read the [reference documentation](https://kubernetes.io/docs/home).
 
@@ -75,7 +75,7 @@ There are two things to take note of here:
  mechanism, this is an apt mapping.
 2. This mapping is optional because Spinnaker's orchestration capabilities do
  not require Deployment objects to exist to handle updates. In fact, one
- __should not__ attempt to let Spinnaker's orchestration (Red/Black,
+ __should not__ attempt to let Spinnaker's orchestration (Blue/Green,
  Highlander) manage Server Groups handled by Kubernetes' orchestration
  (Rolling Update), since they do not, and are not intended to work together.
 
@@ -205,7 +205,7 @@ When deploying a Replica Set, Spinnaker sets all labels as described in the
 [Server Group](#server-group) and [Load Balancer](#load-balancer) sections
 above, adds the necessary `ImagePullSecrets` for your desired docker
 containers, and then creates the Replica Set with all properties you've
-specified. 
+specified.
 
 When deploying a Replica Set with a Deployment, and the Deployment doesn't
 exist, Spinnaker first creates the Replica Set with `replicas: 0`, and then

content/en/docs/setup/install/providers/kubernetes-v2/_index.md

@@ -197,7 +197,7 @@ reasons:
 - The V2 provider encourages you to leverage the Kubernetes native deployment
  orchestration (e.g.
  [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/))
- instead of the Spinnaker red/black, where possible.
+ instead of the Spinnaker blue/green (red/black), where possible.
 
 - The initial operations available on Kubernetes manifests (e.g. scale, pause
  rollout, delete) in the V2 provider don't map nicely to the operations in the

content/en/docs/setup/install/providers/kubernetes-v2/k8s-provider.md

@@ -164,7 +164,7 @@ reasons:
 * The V2 provider encourages you to leverage the Kubernetes native deployment
  orchestration (e.g.
  [Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/))
- instead of the Spinnaker red/black, where possible.
+ instead of the Spinnaker blue/green (red/black), where possible.
 
 * The initial operations available on Kubernetes manifests (e.g. scale, pause
  rollout, delete) in the V2 provider don't map nicely to the operations in the

content/en/docs/setup/productionize/persistence/clouddriver-sql.md

@@ -70,7 +70,7 @@ sql:
  # read-only boolean toggles `SELECT` or `DELETE` health checks for all pools.
  # Especially relevant for clouddriver-ro and clouddriver-ro-deck which can
  # target a SQL read replica in their default pools.
- read-only: false 
+ read-only: false
  taskRepository:
  enabled: true
  cache:
@@ -83,7 +83,7 @@ sql:
  writeBatchSize: 300
  scheduler:
  enabled: true
- # Enable clouddriver-caching's clean up agent to periodically purge old 
+ # Enable clouddriver-caching's clean up agent to periodically purge old
  # clusters and accounts. Set to true when using the Kubernetes provider.
  unknown-agent-cleanup-agent:
  enabled: false
@@ -243,5 +243,5 @@ The following steps were taken to live migrate Clouddriver in the Netflix produc
  dualTaskRepository:
  enabled: false
  ```
-7. The disabled Redis-backed Clouddriver instances were verified as idle and the new configuration deployed via a red/black.
+7. The disabled Redis-backed Clouddriver instances were verified as idle and the new configuration deployed via a blue/green.
 8. The temporary migration clusters were disabled and then terminated 5 minutes later.

data/about_copy.yaml

@@ -10,7 +10,7 @@ automated_releases_row:
  alt: 'Automated Releases Logo'
 best_practices_row:
  title: Built-in Deployment Best Practices
- excerpt: 'Create and deploy immutable images for faster rollouts, easier rollbacks, and the elimination of hard to debug configuration drift issues. Leverage an immutable infrastructure in the cloud with built-in deployment strategies such as red/black and canary deployments.'
+ excerpt: 'Create and deploy immutable images for faster rollouts, easier rollbacks, and the elimination of hard to debug configuration drift issues. Leverage an immutable infrastructure in the cloud with built-in deployment strategies such as blue/green and canary deployments.'
  image_path: assets/images/best-practices.svg
  image_class: best_practices_img
  alt: 'Best Practices Logo'

data/features.yaml

@@ -9,7 +9,7 @@ cli_feature:
  content: 'Install, configure, and update your Spinnaker instance with halyard, Spinnaker’s CLI tool.'
 deployment_strategies_feature:
  title: Deployment Strategies
- content: 'Configure pipelines with built-in deployment strategies such as highlander and red/black, with rolling red/black and canary in active development, or define your own custom strategy.'
+ content: 'Configure pipelines with built-in deployment strategies such as highlander and blue/green, with rolling blue/green and canary in active development, or define your own custom strategy.'
 vm_bakery_feature:
  title: VM Bakery
  content: 'Bake immutable VM images via Packer, which comes packaged with Spinnaker and offers support for Chef and Puppet templates.'