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
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Instead of just aborting on the first encountered error, try to proceed and reconcile the remaining resources. The only thing that currently causes a hard error is UpdateFromResources(), the rest should be logged, reported as an event and ignored.
StackContainer logic has been adjusted to check other stack resources in IsReady() as well to prevent a situation where traffic is directed to a stack that can't be reconciled.
Instead of just aborting on the first encountered error, try to proceed
and reconcile the remaining resources. The only thing that currently
causes a hard error is UpdateFromResources(), the rest should be logged,
reported as an event and ignored.
StackContainer logic has been adjusted to check other stack resources in
IsReady() as well to prevent a situation where traffic is directed to a
stack that can't be reconciled.
Signed-off-by: Alexey Ermakov <alexey.ermakov@zalando.de>
It's clear why the container parameter in ReconcileStackSet(container *core.StackSetContainer) is a pointer (cuz of container.MarkExpiredStacks()), why were the parameters of other methods changed to pointers? Maybe there is a golang best practice I don't know about?
@muaazsaleemReconcileStatuses() is the last call, so there's no point in trying to do anything. It also shouldn't be possible to break it permanently by a user action.
We can't really proceed if UpdateFromResources() fails because the whole state will be completely broken. Note that currently it only fails if it can't parse traffic information, which can only happen if the users deliberately corrupt the annotations. We could implement a fallback strategy for this, but I'm not sure if it's worth it.
It's clear why the container parameter in ReconcileStackSet(container *core.StackSetContainer) is a pointer (cuz of container.MarkExpiredStacks()), why were the parameters of other methods changed to pointers? Maybe there is a golang best practice I don't know about?
I think my question is too generic, I'll follow up with more specific ones if I have them
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Instead of just aborting on the first encountered error, try to proceed and reconcile the remaining resources. The only thing that currently causes a hard error is
UpdateFromResources(), the rest should be logged, reported as an event and ignored.StackContainerlogic has been adjusted to check other stack resources inIsReady()as well to prevent a situation where traffic is directed to a stack that can't be reconciled.