Repository navigation
feat: record events when a feature fails and use the shared event reasons - #2032
Merged
Merged
Conversation
…sons A feature which failed to be deployed, and was retried, only recorded the failure in the ClusterSummary status. An event was recorded only when the failure was not retriable (after the maximum number of consecutive failures, or for a non retriable or template error), so for the first failures a user saw nothing in `kubectl describe clustersummary` or in the events of the namespace. This change records an event when a feature fails and the operation is retried, and moves the events addon-controller already recorded to the reasons defined in libsveltos `lib/eventreasons`. | Reason | When | |---|---| | `FeatureFailed` | A feature failed to be deployed or removed and the operation is retried. | | `LicenseInvalid` | A ClusterSummary targets a SveltosCluster in pull mode which is not covered by a license. One event, instead of one per feature. | `FeatureFailed` is recorded when the failure message persisted in the ClusterSummary changes, so: - the first failure is recorded, an identical retry is not (a retry goes Failed, Provisioning, Failed, and the failure message is kept during the Provisioning step); - a different error is recorded; - a failure after the feature succeeded (the message is cleared) is recorded again. It is not recorded for a failure which already has its own event: a non retriable error, a template error (`FeatureFailedNonRetriable`) and a conflict (`ProfileConflict`). The action of a feature event is a verb followed by the feature (`DeployingHelm`, `RemovingResources`). The events recorder merges events with the same reason, action and regarding object and keeps only the first note, so two features of the same ClusterSummary failing together would otherwise be a single event. No event is recorded for expected states: a paused cluster, a closed active window, the MaxUpdate throttle, a profile waiting on its dependencies, a cluster which is not ready or whose agent is not healthy (sveltoscluster-manager records that one), and a successful removal. The events which already existed use the shared vocabulary. Anyone alerting or filtering on the old reasons needs to update them: | Previous reason | New reason | |---|---| | `Sveltos` (Normal, a feature was deployed) | `FeatureDeployed` | | `FailedNonRetriable` | `FeatureFailedNonRetriable` | | `Conflict` | `ProfileConflict` | The `action` of these events was the kind `ClusterSummary`; it is now a verb followed by the feature, for example `DeployingHelm`. The notes are unchanged.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
A feature which failed to be deployed, and was retried, only recorded the failure in the ClusterSummary status. An event was recorded only when the failure was not retriable (after the maximum number of consecutive failures, or for a non retriable or template error), so for the first failures a user saw nothing in
kubectl describe clustersummaryor in the events of the namespace.This change records an event when a feature fails and the operation is retried, and moves the events addon-controller already recorded to the reasons defined in libsveltos
lib/eventreasons.FeatureFailedFeatureFailedis recorded when the failure message persisted in the ClusterSummary changes, so:It is not recorded for a failure which already has its own event: a non retriable error, a template error (
FeatureFailedNonRetriable) and a conflict (ProfileConflict).The action of a feature event is a verb followed by the feature (
DeployingHelm,RemovingResources). The events recorder merges events with the same reason, action and regarding object and keeps only the first note, so two features of the same ClusterSummary failing together would otherwise be a single event.No event is recorded for expected states: a paused cluster, a closed active window, the MaxUpdate throttle, a profile waiting on its dependencies, a cluster which is not ready or whose agent is not healthy (sveltoscluster-manager records that one), and a successful removal.
The events which already existed use the shared vocabulary. Anyone alerting or filtering on the old reasons needs to update them:
Sveltos(Normal, a feature was deployed)FeatureDeployedThe
actionof these events was the kindClusterSummary; it is now a verb followed by the feature, for exampleDeployingHelm. The notes are unchanged.