NETOBSERV-2375: make consistent status handling#2520
Conversation
|
@jotak: This pull request references NETOBSERV-2375 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "4.22.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
@jotak: This pull request references NETOBSERV-2375 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "4.22.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
@jotak: This pull request references NETOBSERV-2375 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "4.22.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
Address some old "TODOs" in status management. All statuses now follow this pattern: - They are initialized unknown - When controller found unused, status set to unused - At any point, if an error occurs, it's set with that error - Deployment/DaemonSet check progress set status either as InProgress, or Ready - New Degraded condition can be optionally set; a degraded status does not prevent it from being "ready". Make the LokiStack status fit in this model (it was previously using an entirely different pattern) Also, previously, in 2 different places LokiStack was fetched to get its status (for propagating status into FlowCollector status and into console plugin config) Now consolidated into a single entry point to get the loki status. Status changes: - New status: EBPFAgents - New status: WebConsole - New status: DemoLoki - New status: LokiStack - Renamed status: FlowCollectorLegacy => FlowCollectorController - Removed: LokiIssue and LokiWarning
| // Set status failure unless it was already set | ||
| if !r.status.HasFailure() { | ||
| r.status.SetFailure("FlowCollectorGenericError", err.Error()) | ||
| r.status.SetFailure("ChildReconcilerError", err.Error()) |
There was a problem hiding this comment.
I'm not convinced by this namming but I don't know what could be better here actually 🤔
There was a problem hiding this comment.
"SubReconcilerError" ? "DelegateReconcilerError" ? "DependentReconcilerError" ?
jpinsonneau
left a comment
There was a problem hiding this comment.
Nice work ! That will help a lot the users to have a clear view of what's going on !
Thanks @jotak
|
/ok-to-test |
|
New images: quay.io/netobserv/network-observability-operator:542cb66
quay.io/netobserv/network-observability-operator-bundle:v0.0.0-sha-542cb66
quay.io/netobserv/network-observability-operator-catalog:v0.0.0-sha-542cb66They will expire in two weeks. To deploy this build: # Direct deployment, from operator repo
IMAGE=quay.io/netobserv/network-observability-operator:542cb66 make deploy
# Or using operator-sdk
operator-sdk run bundle quay.io/netobserv/network-observability-operator-bundle:v0.0.0-sha-542cb66Or as a Catalog Source: apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
name: netobserv-dev
namespace: openshift-marketplace
spec:
sourceType: grpc
image: quay.io/netobserv/network-observability-operator-catalog:v0.0.0-sha-542cb66
displayName: NetObserv development catalog
publisher: Me
updateStrategy:
registryPoll:
interval: 1m |
|
@jotak PR looks good overall except I am not able to simulate a degraded state.
So let me know how do I hit the degraded state scenario |
|
@Amoghrd the degraded condition should show up in the same conditions that previously would trigger a "LokiWarning" condition, so if you had tests previously with LokiWarning, you should be able to reuse the same. It's currently the only thing that triggers degraded. Looking at the unit tests, an example of issue that triggers it is this one:
would be good to check if it's a regression of this PR; if not, we should open a bug |
|
/label qe-approved |
|
@jotak: This pull request references NETOBSERV-2375 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "4.22.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
Yup the eBPF with nodeSelector bug is a regression, created a bug https://redhat.atlassian.net/browse/NETOBSERV-2674 |
Description
Address some old "TODOs" in status management. All statuses now follow this pattern:
Make the LokiStack status fit in this model (it was previously using an entirely different pattern)
Also, previously, in 2 different places LokiStack was fetched to get its status (for propagating status into FlowCollector status and into console plugin config) Now consolidated into a single entry point to get the loki status.
Status changes:
Dependencies
Checklist