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
{{ message }}
This repository has been archived by the owner on May 3, 2022. It is now read-only.
The user doesn't specify clusters by name. It's Shipper which decides the clusters that a Release should end up on. So, when we are processing an item and a Cluster is not found, one of two things could be happening:
A user or an automated process has messed with our annotations, or
The Cluster object has been removed.
In either case, this object is not valid and should be removed from the queues instead of being retried.
However, in the second case, there is a chance that the Cluster was removed in error. In that case, the Cluster object will be re-created by a user or an automated process. When that Cluster object is added, we can scan the existing Releases, find Releases that had been scheduled on a cluster with the same name, and enqueue those Releases.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The user doesn't specify clusters by name. It's Shipper which decides the clusters that a Release should end up on. So, when we are processing an item and a Cluster is not found, one of two things could be happening:
In either case, this object is not valid and should be removed from the queues instead of being retried.
However, in the second case, there is a chance that the Cluster was removed in error. In that case, the Cluster object will be re-created by a user or an automated process. When that Cluster object is added, we can scan the existing Releases, find Releases that had been scheduled on a cluster with the same name, and enqueue those Releases.
The text was updated successfully, but these errors were encountered: