You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We would like to ask for an optional feature to have Rollouts produce an AnalysisRun on the first deployment (link to original discussion).
Use Cases
The idea is to use AnalysisRuns as a definitive resource to determine the deployment result of a Rollout. Regardless of rollback behavior or whether it is a first or n-th deployment.
Speaking for the setup I'm working with specifically, this is especially relevant during blue-green cluster upgrades. The idea is to have a fully declaratively defined cluster including the workload that should be deployed to it. Cluster upgrades become very simple using this setup as we do not rely on in-place upgrades.
A very similar setup to ours is outlined in this article in the section "Solution overview":
After creating a new cluster and before routing production traffic to it, our devops teams can confirm everything is working as expected and then route traffic to it. This confirmation step is what's stumping our developers, as they are surprised they are unable to use the same mechanism (AnalysisRuns) for smoke-tests after a blue-green cluster upgrade as they do during regular blue-green application updates.
[...] if the analysis fails what do you expect to happen? There is no previous version to rollback to. Or you expect Rollouts to keep the new version running anyway? Or maybe to shut it down completely?
Personally, I think a safe default would be to maintain the current behavior. Which means the first deployment would remain even in case of a failed AnalysisRun. But it would be nice if this is configurable as this probably differs case-by-case.
Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritize the issues with the most 👍.
The text was updated successfully, but these errors were encountered:
Summary
We would like to ask for an optional feature to have Rollouts produce an AnalysisRun on the first deployment (link to original discussion).
Use Cases
The idea is to use AnalysisRuns as a definitive resource to determine the deployment result of a Rollout. Regardless of rollback behavior or whether it is a first or n-th deployment.
Speaking for the setup I'm working with specifically, this is especially relevant during blue-green cluster upgrades. The idea is to have a fully declaratively defined cluster including the workload that should be deployed to it. Cluster upgrades become very simple using this setup as we do not rely on in-place upgrades.
A very similar setup to ours is outlined in this article in the section "Solution overview":
After creating a new cluster and before routing production traffic to it, our devops teams can confirm everything is working as expected and then route traffic to it. This confirmation step is what's stumping our developers, as they are surprised they are unable to use the same mechanism (AnalysisRuns) for smoke-tests after a blue-green cluster upgrade as they do during regular blue-green application updates.
Considerations
Something to be addressed as pointed out by @kostis-codefresh here:
Personally, I think a safe default would be to maintain the current behavior. Which means the first deployment would remain even in case of a failed AnalysisRun. But it would be nice if this is configurable as this probably differs case-by-case.
Message from the maintainers:
Impacted by this bug? Give it a 👍. We prioritize the issues with the most 👍.
The text was updated successfully, but these errors were encountered: