Skip to content
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-220 implement ovn-kubernetes reconciler #97

Merged
merged 3 commits into from
May 19, 2022

Conversation

jotak
Copy link
Member

@jotak jotak commented May 6, 2022

It's creating a new reconciler for upstream ovn-k daemonset config

@openshift-ci
Copy link

openshift-ci bot commented May 6, 2022

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

@jotak
Copy link
Member Author

jotak commented May 6, 2022

cc @eranra

@jotak jotak changed the title WIP make it work with kind WIP make it work better with kind May 6, 2022
@eranra
Copy link
Contributor

eranra commented May 8, 2022

@jotak let me know if and how this needs to be connected to #65 . I ended up removing the kind script from #65 and used the simulator to generate flow logs.

I believe that providing upstream operator with kind support is important (if this is doable for us) .

@jotak jotak changed the title WIP make it work better with kind NETOBSERV-220 implement ovn-kubernetes reconciler May 10, 2022
@jotak jotak mentioned this pull request May 11, 2022
Comment on lines 180 to 181
HostNetwork: hostNetwork,
DNSPolicy: corev1.DNSClusterFirst,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As already commented in another thread:

@jotak jotak marked this pull request as ready for review May 17, 2022 16:36
@jotak jotak requested a review from mariomac May 17, 2022 17:14
if err := ovsConfigController.Reconcile(ctx, desired, gfReconciler.GetServiceName(desired.Spec.Kafka)); err != nil {
return ctrl.Result{},
fmt.Errorf("failed to reconcile ovs-flows-config ConfigMap: %w", err)
if desired.Spec.ClusterNetworkOperator.Namespace != "" {
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe I should replace the namespace check with something more explicit like a new field Spec.ClusterNetworkOperator.Enabled to switch between ovn-k and CNO

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To avoid user intervention by means of configuration, in some other parts of the we try to discover if components are enabled by fetching concrete ApiService, e.g:

I don't know if this could be useful also in this case.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I see that you are already using discovery here.

Can we assume that any OpenShift cluster with OVN-K will have the CNO already installed?

Off-topic: as a future task, it would be nice to discover OVN-K or another CNI and then deploy IPFIX or eBPF by default.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 let me rework that

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So I'm using the discovery client to check for presence of the CNO now.
I haven't done the ebpf switch as you suggest although I agree it will be nice

Copy link
Contributor

@mariomac mariomac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall looks fine. ATM I have only tested it in downstream OpenShift, to verify that we don't break anything.

@@ -110,26 +110,17 @@ Note that the `FlowCollector` resource must be unique and must be named `cluster

## Enabling OVS IPFIX export

If you use OpenShift 4.10, you don't have anything to do: the operator will configure OVS *via* the Cluster Network Operator. Else, some manual steps are still required:
If you use OpenShift 4.10 or the upstream ovn-kubernetes without OpenShift, you don't have anything to do: the operator will configure OVS *via* OpenShift Cluster Network Operator, or the ovn-kubernetes layer directly.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd create a new JIRA issue to document eBPF as an alternative to IPFIX that is not restricted to OVN and might work out of the box with OpenShift 4.8/4.9

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh yes exactly, I wanted to ask you if you had that planned already :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if err := ovsConfigController.Reconcile(ctx, desired, gfReconciler.GetServiceName(desired.Spec.Kafka)); err != nil {
return ctrl.Result{},
fmt.Errorf("failed to reconcile ovs-flows-config ConfigMap: %w", err)
if desired.Spec.ClusterNetworkOperator.Namespace != "" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To avoid user intervention by means of configuration, in some other parts of the we try to discover if components are enabled by fetching concrete ApiService, e.g:

I don't know if this could be useful also in this case.

if err := ovsConfigController.Reconcile(ctx, desired, gfReconciler.GetServiceName(desired.Spec.Kafka)); err != nil {
return ctrl.Result{},
fmt.Errorf("failed to reconcile ovs-flows-config ConfigMap: %w", err)
if desired.Spec.ClusterNetworkOperator.Namespace != "" {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I see that you are already using discovery here.

Can we assume that any OpenShift cluster with OVN-K will have the CNO already installed?

Off-topic: as a future task, it would be nice to discover OVN-K or another CNI and then deploy IPFIX or eBPF by default.

)

const (
// Make configurable?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should find a way, with the difficulty that the default value would be openshift-ovn-kubernetes for downstream OpenShift and ovn-kubernetes for upstream OVN-K.

But I don't think it's something mandatory right now.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done, there's a new entry in CR now to define upstream ovnk setup
I don't think it's very useful to handle the upstream ovnk case with openshift, I guess we can assume that the CNO will be used in that case.

return err
}

ovnkubeNode := reconcilers.FindContainer(&current.Spec.Template.Spec, "ovnkube-node")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

instead of the literal, shall you use the constant ovnkDSName?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually introduced it as a config

Distinct case openshift / other for hostnetwork

- With Openshift use its SCC API
- Else use pod's spec hostnetwork

Update documentation
- Configure ovnk (namespace, daemonset, container name). Defaults should
  work in most cases.
- Detect CNO presence to switch between CNO or upstream ovnk
- Merge the existing Console detection in a new "AvailableAPIs"
  mechanism in the existing dicover package
@@ -0,0 +1,51 @@
package discover
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! In a future patch I'll merge here the Openshift/Vanilla kubernetes

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah I wasn't sure if your permissions code could be merged or if there was some additional logic

Comment on lines 258 to 260
if !apis.HasCNO() {
log.Info("CNO not detected: using ovnKubernetes config and reconciler")
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the intention here only to log a message?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, I find it useful while checking the logs :)

@openshift-ci openshift-ci bot added the lgtm label May 19, 2022
@jotak
Copy link
Member Author

jotak commented May 19, 2022

thanks @mariomac !
/approve

@openshift-ci
Copy link

openshift-ci bot commented May 19, 2022

[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 /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-merge-robot openshift-merge-robot merged commit 64b0d2e into netobserv:main May 19, 2022
@jotak jotak deleted the kind-wip branch December 7, 2022 04:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants