-
Notifications
You must be signed in to change notification settings - Fork 110
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.
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
allow to continue on a Conflict #742
Comments
This issue is being marked as stale due to a long period of inactivity and will be closed in 5 days if there is no response. |
This issue is being marked as stale due to a long period of inactivity and will be closed in 5 days if there is no response. |
/remove stale |
possibly related to #746 |
This issue is being marked as stale due to a long period of inactivity and will be closed in 5 days if there is no response. |
We would like Kapp to continue the rollout even on a
Conflict
so that the resources are rolled out in best effort. Related to #573 however we need the ability not to fail instantly in such occasions.Background
We are using Kapp to deploy whole cluster including apps using the Kapp gitOps style deployment. It sums up to 800 resources for a new cluster. (This ability of Kapp to have the whole cluster in a desired state is so powerful for us that we switched our tooling completely on Kapp - amazing work done here and we love Kapp for that!)
Since the rollout of so many resources takes time, there is a good chance to run into an error like
the object has been modified; please apply your changes to the latest version and try again (reason: Conflict)
for various resources. Some of them are mere conflicts with the AWS EKS internal bootstrapping where Kapp might arrive too early, others are due to status updates happening in meantime btw. the two Kapp stages.What happened:
Please see following examples of Kapp failing instantly.
Unavoidable race condition with AWS EKS internal bootstrapping
Race condition with AWS EKS internal bootstrapping
Race condition - probably a bug?
A controller update in meantime
Another status update
a status update bug?
What did you expect:
Kapp to finish up the rollout with the remaining resources. In our full-cluster desired state that can be critical, fatal ones and hundreds of other resources that are getting out of relation, that is deployment order.
IMHO those cases do not require that Kapp stopps immediately its run, it would be totally sufficient to finish up the remaining deployments.
Ideas to solve, ordered by simplicity
continueOnConflict
to log out only instead of raising an error.Anything else you would like to add:
We are deploying all cluster resources as one Kapp App. We've decided to go that route because we get the "world view" of Kapp, we can define easily the dependencies where necessary, and we have a desired state in the cluster, cleaning up removed deployments.
Environment:
Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help working on this issue.
The text was updated successfully, but these errors were encountered: