From 5441b366422e19e9db476361783ddec4e3394a7e Mon Sep 17 00:00:00 2001 From: zachaller Date: Thu, 1 Dec 2022 14:45:57 -0600 Subject: [PATCH 1/6] add WIP release schedule following ArgoCD Signed-off-by: zachaller --- docs/roadmap.md | 138 +++++++++++++++--------------------------------- mkdocs.yml | 2 +- 2 files changed, 45 insertions(+), 95 deletions(-) diff --git a/docs/roadmap.md b/docs/roadmap.md index be63c3637e..7a93de20b0 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -1,117 +1,67 @@ # Roadmap -The item listed here are proposed items for Argo Rollouts and are subject to change. To see where items -may fall into releases, visit the [github milestones](https://github.com/argoproj/argo-rollouts/milestones) -and notice if the item appears in the milestone description. +The Argo Rollouts roadmap is maintained in Github Milestones on the project. -- [Roadmap](#roadmap) - - [Weight Verification](#weight-verification) - - [Istio Canary using DestinationRule subsets](#istio-canary-using-destinationrule-subsets) - - [Webhook Notifications](#webhook-notifications) - - [Rollback Window](#rollback-window) - - [Header Based Routing](#header-based-routing) - - [Shadow Traffic](#shadow-traffic) +## Release Cycle -# v1.0 +### Schedule -## Weight Verification +These are the upcoming releases date estimates: -[Issue #701](https://github.com/argoproj/argo-rollouts/issues/701) +| Release | Release Planning Meeting | Release Candidate 1 | General Availability | +|---------|--------------------------|-----------------------|-------------------------| +| v1.4 | N/A | Monday, Dec. 12, 2022 | Tuesday, Jan. 2, 2023 | +| v1.5 | Monday, Feb. 27, 2023 | Monday, Mar. 13, 2023 | Monday, Apr. 3, 2023 | +| v1.6 | Monday, May 29, 2023 | Monday, Jun. 12, 2023 | Wednesday, Jul. 5, 2023 | +| v1.7 | Monday, Aug. 28, 2023 | Monday, Sep. 11, 2023 | Monday, Oct. 2, 2023 | -When Argo Rollouts adjusts a canary weight, it currently assumes that the adjustment was made and -moves on to the next step. However, for some traffic routing providers, this change can take a long -time to take effect (or possibly never even made) since external factors may cause the change to -become delayed. +### Release Process -This proposal is to add verification to the traffic routers so that after a setWeight step, the -rollout controller could verify that the weight took effect before moving on to the next step. This -is especially important for the ALB ingress controller which are affected by things like rate -limiting, the ALB ingress controller not running, etc... +#### Minor Releases (e.g. 1.x.0) +A minor Argo Rollouts release occurs four times a year, once every three months. Each General Availability (GA) release is +preceded by several Release Candidates (RCs). The first RC is released three weeks before the scheduled GA date. This +effectively means that there is a three-week feature freeze. -## Istio Canary using DestinationRule subsets +These are the approximate release dates: -[Issue #617](https://github.com/argoproj/argo-rollouts/issues/617) +* The first Monday of January +* The first Monday of April +* The first Monday of July +* The first Monday of October -Currently, Rollouts supports only host-level traffic splitting using two Kubernetes Services. -For some use cases (e.g. east-west canarying intra-cluster), this pattern not desirable and traffic -splitting should be achieved using two -Istio [DestinationRule Subsets](https://istio.io/latest/docs/reference/config/networking/destination-rule/#Subset) -instead. +Dates may be shifted slightly to accommodate holidays. Those shifts should be minimal. +#### Patch Releases (e.g. 1.4.x) -## Workload Referencing +Argo Rollouts patch releases occur on an as-needed basis. Only the three most recent minor versions are eligible for patch +releases. Versions older than the three most recent minor versions are considered EOL and will not receive bug fixes or +security updates. -[Issue #676](https://github.com/argoproj/argo-rollouts/issues/676) +#### Minor Release Planning Meeting -Currently, the Rollout spec contains both the deployment strategy (e.g. blueGreen/canary), -as well as the pod template. This proposal is to support a way to reference the pod template -definition from another group/kind (e.g. a Deployment, PodTemplate) so that the rollout strategy -could be separated from the workload definition. This is motivated by the following use cases: +Two weeks before the RC date, there will be a meeting to discuss which features are planned for the RC. This meeting is +for contributors to advocate for certain features. Features which have at least one approver (besides the contributor) +who can assure they will review/merge by the RC date will be included in the release milestone. All other features will +be dropped from the milestone (and potentially shifted to the next one). -* CRDs (e.g. Rollouts) are not supported well in kustomize, and strategic merge patches simply - don't work as expected with a Rollout because lists will be replaced and not merged. By - referencing a native Kubernetes kind, kustomize would work expectedly against the k8s native - referenced object, which is the portion of the spec that users typically want to customize - overlays against. -* During a migration from a Deployment to a Rollout, it has been inconvenient for users to duplicate - the entire Deployment spec to a Rollout, and keeping them always in sync during the transition. - By referencing the definition, we would be able to eliminate the possibility of pod template spec - duplication. +Since not everyone will be able to attend the meeting, there will be a meeting doc. Contributors can add their feature +to a table, and Approvers can add their name to the table. Features with a corresponding approver will remain in the +release milestone. +### Feature Acceptance Criteria -```yaml -apiVersion: argoproj.io/v1alpha1 -kind: Rollout -metadata: - name: guestbook-canary -spec: - replicas: 5 - workloadRef: - apiVersion: apps/v1 - kind: Deployment - name: guestbook - strategy: - canary: - steps: - - setWeight: 20 - - pause: {duration: 1h} - - setWeight: 40 - - pause: {duration: 1h} - - setWeight: 60 - - pause: {duration: 1h} - - setWeight: 80 - - pause: {duration: 1h} -``` +To be eligible for inclusion in a minor release, a new feature must meet the following criteria before the release’s RC +date. -# v1.1+ +If it is a large feature that involves significant design decisions, that feature must be described in a Proposal. -## Webhook Notifications +The feature PR must include: -[Issue #369](https://github.com/argoproj/argo-rollouts/issues/369) +* Tests (passing) +* Documentation +* If necessary, a note in the Upgrading docs for the planned minor release +* The PR must be reviewed, approved, and merged by an Approver. -When a rollout transitions state, such as an aborted rollout due to failed analysis, there is no mechanism to notify an external system about the failure. Instead, users must currently put in place something to monitor the rollout, and notice the condition to take action. Monitoring a rollout is not always an option, since it requires that the external system have access to the Kubernetes API server. - -A webhook notification feature of Rollouts would allow a push-based model where the Rollout controller itself would push an event to an external system, in the form of a webhook/cloud event. - -## Rollback Windows - -[Issue #574](https://github.com/argoproj/argo-rollouts/issues/574) - -Currently, when an older Rollout manifest is re-applied, the controller treats it the same as a spec change, and will execute the full list of steps, and perform analysis too. There are two exceptions to this rule: -1. the controller detects if it is moving back to a blue-green ReplicaSet which exists and is still scaled up (within its scaleDownDelay) -2. the controller detects it is moving back to the canary's "stable" ReplicaSet, and the upgrade had not yet completed. - -It is often undesirable to re-run analysis and steps for a rollout, when the desired behavior is to rollback as soon as possible. To help with this, a rollback window feature would allow users a window indicate to the controller to - -## Header Based Routing - -[Issue #474](https://github.com/argoproj/argo-rollouts/issues/474) - -Users who are using Rollout with a service mesh, may want to leverage some of its more advanced features, such as routing traffic via headers instead of purely by percentage. Header based routing provides the ability to route traffic based on a header, instead of a percentage of traffic. This allows more flexibility when canarying, such as providing session stickiness, or only exposing a subset of users with a HTTP cookie or user-agent. - -## Shadow Traffic - -[Issue #474](https://github.com/argoproj/argo-rollouts/issues/474) - -Some service meshes provide the ability to "shadow" live production traffic. A feature in rollouts could provide a canary step to shadow traffic to the canary stack, to see how it responds to the real-world data. +If these criteria are not met by the RC date, the feature will be ineligible for inclusion in the RC series or GA for +that minor release. It will have to wait for the next minor release. diff --git a/mkdocs.yml b/mkdocs.yml index b58e905cc8..6fa670ffc1 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -121,7 +121,7 @@ nav: - Migrating: migrating.md - FAQ: FAQ.md - Security: security.md -- Roadmap: roadmap.md +- Roadmap/Release Schedule: roadmap.md - Contributing: - Contribution Guide: CONTRIBUTING.md - Environment Setup: getting-started/setup/index.md From 20204f5d10431d28b081559f9bf9a65321f69907 Mon Sep 17 00:00:00 2001 From: zachaller Date: Mon, 5 Dec 2022 09:10:27 -0600 Subject: [PATCH 2/6] update dates Signed-off-by: zachaller --- docs/roadmap.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/roadmap.md b/docs/roadmap.md index 7a93de20b0..97c535e7aa 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -8,12 +8,12 @@ The Argo Rollouts roadmap is maintained in Github Milestones on the project. These are the upcoming releases date estimates: -| Release | Release Planning Meeting | Release Candidate 1 | General Availability | -|---------|--------------------------|-----------------------|-------------------------| -| v1.4 | N/A | Monday, Dec. 12, 2022 | Tuesday, Jan. 2, 2023 | -| v1.5 | Monday, Feb. 27, 2023 | Monday, Mar. 13, 2023 | Monday, Apr. 3, 2023 | -| v1.6 | Monday, May 29, 2023 | Monday, Jun. 12, 2023 | Wednesday, Jul. 5, 2023 | -| v1.7 | Monday, Aug. 28, 2023 | Monday, Sep. 11, 2023 | Monday, Oct. 2, 2023 | +| Release | Release Planning Meeting | Release Candidate 1 | General Availability | | +|---------|--------------------------|-----------------------|--------------------------| +| v2.6 | TBD | Monday, Dec. 19, 2022 | Tuesday, Jan. 9, 2023 | +| v2.7 | Monday, Mar. 6, 2023 | Monday, Mar. 20, 2023 | Monday, Apr. 10, 2023 | +| v2.8 | Monday, Jun. 5, 2023 | Monday, Jun. 19, 2023 | Wednesday, Jul. 12, 2023 | +| v2.9 | Monday, Sep. 4, 2023 | Monday, Sep. 18, 2023 | Monday, Oct. 9, 2023 | ### Release Process From ca67f2454dfbc3f71a20e683a8e45c6bc5b696db Mon Sep 17 00:00:00 2001 From: zachaller Date: Mon, 5 Dec 2022 09:11:52 -0600 Subject: [PATCH 3/6] update dates Signed-off-by: zachaller --- docs/roadmap.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/roadmap.md b/docs/roadmap.md index 97c535e7aa..224ea04d91 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -8,7 +8,7 @@ The Argo Rollouts roadmap is maintained in Github Milestones on the project. These are the upcoming releases date estimates: -| Release | Release Planning Meeting | Release Candidate 1 | General Availability | | +| Release | Release Planning Meeting | Release Candidate 1 | General Availability | |---------|--------------------------|-----------------------|--------------------------| | v2.6 | TBD | Monday, Dec. 19, 2022 | Tuesday, Jan. 9, 2023 | | v2.7 | Monday, Mar. 6, 2023 | Monday, Mar. 20, 2023 | Monday, Apr. 10, 2023 | From 4c028e7b0958edfe79a357e6f7ac1b3aec914088 Mon Sep 17 00:00:00 2001 From: zachaller Date: Mon, 5 Dec 2022 09:12:51 -0600 Subject: [PATCH 4/6] fix versions Signed-off-by: zachaller --- docs/roadmap.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/roadmap.md b/docs/roadmap.md index 224ea04d91..e5ffaa6b6a 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -10,10 +10,10 @@ These are the upcoming releases date estimates: | Release | Release Planning Meeting | Release Candidate 1 | General Availability | |---------|--------------------------|-----------------------|--------------------------| -| v2.6 | TBD | Monday, Dec. 19, 2022 | Tuesday, Jan. 9, 2023 | -| v2.7 | Monday, Mar. 6, 2023 | Monday, Mar. 20, 2023 | Monday, Apr. 10, 2023 | -| v2.8 | Monday, Jun. 5, 2023 | Monday, Jun. 19, 2023 | Wednesday, Jul. 12, 2023 | -| v2.9 | Monday, Sep. 4, 2023 | Monday, Sep. 18, 2023 | Monday, Oct. 9, 2023 | +| v1.4 | TBD | Monday, Dec. 19, 2022 | Tuesday, Jan. 9, 2023 | +| v1.5 | Monday, Mar. 6, 2023 | Monday, Mar. 20, 2023 | Monday, Apr. 10, 2023 | +| v1.6 | Monday, Jun. 5, 2023 | Monday, Jun. 19, 2023 | Wednesday, Jul. 12, 2023 | +| v1.7 | Monday, Sep. 4, 2023 | Monday, Sep. 18, 2023 | Monday, Oct. 9, 2023 | ### Release Process From b7370cb00619d5a2838d65c65bc0ebf8ffb967c8 Mon Sep 17 00:00:00 2001 From: zachaller Date: Tue, 20 Dec 2022 09:19:13 -0600 Subject: [PATCH 5/6] remove planning meeting Signed-off-by: zachaller --- docs/roadmap.md | 13 +------------ 1 file changed, 1 insertion(+), 12 deletions(-) diff --git a/docs/roadmap.md b/docs/roadmap.md index e5ffaa6b6a..621328c854 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -1,6 +1,6 @@ # Roadmap -The Argo Rollouts roadmap is maintained in Github Milestones on the project. +The Argo Rollouts roadmap is maintained in Github Milestones on the Github repository. ## Release Cycle @@ -38,17 +38,6 @@ Argo Rollouts patch releases occur on an as-needed basis. Only the three most re releases. Versions older than the three most recent minor versions are considered EOL and will not receive bug fixes or security updates. -#### Minor Release Planning Meeting - -Two weeks before the RC date, there will be a meeting to discuss which features are planned for the RC. This meeting is -for contributors to advocate for certain features. Features which have at least one approver (besides the contributor) -who can assure they will review/merge by the RC date will be included in the release milestone. All other features will -be dropped from the milestone (and potentially shifted to the next one). - -Since not everyone will be able to attend the meeting, there will be a meeting doc. Contributors can add their feature -to a table, and Approvers can add their name to the table. Features with a corresponding approver will remain in the -release milestone. - ### Feature Acceptance Criteria To be eligible for inclusion in a minor release, a new feature must meet the following criteria before the release’s RC From 7fd4fa9a3c88f0bbe5fe3ac7b44612b2ef1ff7b5 Mon Sep 17 00:00:00 2001 From: zachaller Date: Tue, 20 Dec 2022 11:34:09 -0600 Subject: [PATCH 6/6] remove feature freeze Signed-off-by: zachaller --- docs/roadmap.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/roadmap.md b/docs/roadmap.md index 621328c854..7c3e52dcb9 100644 --- a/docs/roadmap.md +++ b/docs/roadmap.md @@ -20,8 +20,7 @@ These are the upcoming releases date estimates: #### Minor Releases (e.g. 1.x.0) A minor Argo Rollouts release occurs four times a year, once every three months. Each General Availability (GA) release is -preceded by several Release Candidates (RCs). The first RC is released three weeks before the scheduled GA date. This -effectively means that there is a three-week feature freeze. +preceded by several Release Candidates (RCs). The first RC is released three weeks before the scheduled GA date. These are the approximate release dates: