-
Notifications
You must be signed in to change notification settings - Fork 24
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
NETOBSERV-1517: remove IPFIX agent mode #579
Conversation
@jotak: This pull request references NETOBSERV-1517 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 story to target the "4.16.0" version, but no target version was set. In 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. |
Skipping CI for Draft Pull Request. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #579 +/- ##
==========================================
+ Coverage 67.16% 67.42% +0.25%
==========================================
Files 71 65 -6
Lines 8417 7996 -421
==========================================
- Hits 5653 5391 -262
+ Misses 2411 2276 -135
+ Partials 353 329 -24
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
@jotak: This pull request references NETOBSERV-1517 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 story to target the "4.16.0" version, but no target version was set. In 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-1517 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 story to target the "4.16.0" version, but no target version was set. In 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. |
- Remove controller code for OVS configmap / CNO configuration - Remove related tests (and move console plugin related tests to its dedicated file) - Remove FLP ingester reconciler (was only used with ipfix) - Note that the IPFIX api is not removed to not introduce breaking changes in existing API, however it is now documented that using IPFIX would have no effect
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the storage version has recently been changed to v1beta2 can't we get rid of the old IPFIX section + type field in this version ?
I don't think any release has been done in between.
That will help on #569 (comment)
return r.status.Error("ReconcileOVNKFailed", err) | ||
} | ||
} | ||
|
||
// eBPF agent | ||
ebpfAgentController := ebpf.NewAgentController(reconcilersInfo.NewInstance(r.mgr.Config.EBPFAgentImage, r.status)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why not adding a test on agent type here and crash if IPFIX ?
That would be more relevent in case someone still uses this type
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I hesitated between the 2 approaches.. the thing I like with switching automatically to eBPF is that we completely remove any legacy IPFIX stuff from the code (except in the API) even that simple bool check & failure, so the state of the art is now: you have no choice it's eBPF. I have the feeling this is more user friendly than triggering an error & avoids risks of misconfiguration.
// but they would require manual configuration). | ||
// `type` [deprecated (*)] selects the flows tracing agent. The only possible value is `EBPF` (default), to use NetObserv eBPF agent.<br> | ||
// Previously, using an IPFIX collector was allowed, but was deprecated and it is now removed.<br> | ||
// Setting `IPFIX` is ignored and still use the eBPF Agent. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// Setting `IPFIX` is ignored and still use the eBPF Agent. |
// but they would require manual configuration). | ||
// `type` [deprecated (*)] selects the flows tracing agent. The only possible value is `eBPF` (default), to use NetObserv eBPF agent.<br> | ||
// Previously, using an IPFIX collector was allowed, but was deprecated and it is now removed.<br> | ||
// Setting `IPFIX` is ignored and still use the eBPF Agent. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// Setting `IPFIX` is ignored and still use the eBPF Agent. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Changes LGTM, but I think we can simplify it much more now that we don't have IPFIX support. We now have the monolith and the transformer, the monolith is used without kafka and the transformer with kafka.
I think we can merge both and remove the flp_controller wrapper around them.
I am fine doing this later if you prefer.
That would be a breaking change which is forbidden in a version that has already been released. We need to create a new API version in order to remove fields (we should have done that before release v1beta2 the first time). |
Co-authored-by: Olivier Cazade <olivier.cazade@gmail.com>
@OlivierCazade I'm actually removing the monolith reconciler in the other PR with unified agent+FLP (not pushed yet). So yes it's going to be even more simplified but via that other PR :) |
/ok-to-test |
New images:
They will expire after two weeks. To deploy this build: # Direct deployment, from operator repo
IMAGE=quay.io/netobserv/network-observability-operator:bf47945 make deploy
# Or using operator-sdk
operator-sdk run bundle quay.io/netobserv/network-observability-operator-bundle:v0.0.0-bf47945 Or 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-bf47945
displayName: NetObserv development catalog
publisher: Me
updateStrategy:
registryPoll:
interval: 1m |
@jotak: The following test failed, say
Full PR test history. Your PR dashboard. 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 kubernetes/test-infra repository. I understand the commands that are listed here. |
/label qe-approved |
@jotak: This pull request references NETOBSERV-1517 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 story to target the "4.16.0" version, but no target version was set. In 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. |
thanks @Amoghrd ! |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jotak The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Description
Dependencies
n/a
Checklist
If you are not familiar with our processes or don't know what to answer in the list below, let us know in a comment: the maintainers will take care of that.