Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: add release schedule #2446

Merged
merged 7 commits into from
Dec 20, 2022
Merged

docs: add release schedule #2446

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
5441b36
add WIP release schedule following ArgoCD
zachaller Dec 1, 2022
20204f5
update dates
zachaller Dec 5, 2022
ca67f24
update dates
zachaller Dec 5, 2022
4c028e7
fix versions
zachaller Dec 5, 2022
58e5eb3
Merge branch 'master' of github.com:argoproj/argo-rollouts into docs-…
zachaller Dec 20, 2022
b7370cb
remove planning meeting
zachaller Dec 20, 2022
7fd4fa9
remove feature freeze
zachaller Dec 20, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
132 changes: 35 additions & 97 deletions docs/roadmap.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,117 +1,55 @@
# 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 Github repository.

- [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 | 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 |

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.

## 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)
### Feature Acceptance Criteria

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:
To be eligible for inclusion in a minor release, a new feature must meet the following criteria before the release’s RC
date.

* 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.
If it is a large feature that involves significant design decisions, that feature must be described in a Proposal.

The feature PR must include:

```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}
```
* 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.

# v1.1+

## Webhook Notifications

[Issue #369](https://github.com/argoproj/argo-rollouts/issues/369)

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.
2 changes: 1 addition & 1 deletion mkdocs.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -125,7 +125,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
Expand Down