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

Support external frr-k8s #483

Closed
wants to merge 4 commits into from
Closed

Conversation

fedepaol
Copy link
Member

Is this a BUG FIX or a FEATURE ?:

Uncomment only one, leave it on its own line:

/kind bug
/kind cleanup
/kind feature
/kind design
/kind flake
/kind failing
/kind documentation
/kind regression

What this PR does / why we need it:

  • Support FRR-K8s externally deployed
  • Enable Openshift cluster network operator to deploy frr-k8s if required

Special notes for your reviewer:

Release note:

Support frr-k8s externally and enable openshift CNO frr-k8s deployment.

@fedepaol fedepaol force-pushed the cnodeploysfrrk8s branch 3 times, most recently from 65f3ec1 to 678466c Compare July 19, 2024 16:53
Signed-off-by: Federico Paolinelli <[email protected]>
@@ -103,6 +104,8 @@ type MetalLBSpec struct {
type FRRK8SConfig struct {
// A list of cidrs we want always to block for incoming routes
AlwaysBlock []string `json:"alwaysBlock,omitempty"`
// The namespace frr-k8s is running on in case of frr-k8s external mode
Copy link
Member

Choose a reason for hiding this comment

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

mind adding something about what happens when this is empty but mode is "external" here?

Copy link
Member Author

Choose a reason for hiding this comment

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

We need to provide a default value to avoid such scenario.

@@ -76,6 +79,9 @@ var FRRK8SChartPath = FRRK8SChartPathController
// +kubebuilder:rbac:groups=apiextensions.k8s.io,resources=customresourcedefinitions,verbs=get;list;watch
// +kubebuilder:rbac:groups=admissionregistration.k8s.io,resources=validatingwebhookconfigurations,verbs=create;delete;get;update;patch;list;watch
// +kubebuilder:rbac:groups="",resources=secrets,verbs=create;delete;get;update;patch;list;watch
// +kubebuilder:rbac:groups=metallb.io,resources=metallbs,verbs=get;list;watch;update;
Copy link
Member

Choose a reason for hiding this comment

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

isn't this redundant with the first one?

// +kubebuilder:rbac:groups=metallb.io,resources=metallbs,verbs=get;list;watch;create;update;patch;delete

Copy link
Member Author

Choose a reason for hiding this comment

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

yep probably the result of a copy-paste

res.MustDeployFRRK8sFromCNO = true
}

res.FRRK8sDefaultNamespace = os.Getenv("FRRK8S_DEFAULT_NAMESPACE")
Copy link
Member

Choose a reason for hiding this comment

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

not sure I understand the rationale (and the naming - something that is "default" being fed from outside) of this env var when there's the namespace in the crd. mind expanding a bit? also what happens when it is empty as the charts don't allow external + empty ns:
- --frrk8s-namespace={{ required "namespace is required when frrk8s is external" .Values.frrk8s.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.

yep we probably need to define the default better

logger := r.Log.WithName("syncMetalLBResources")
logger.Info("Start")

bgpType := params.BGPType(config, r.EnvConfig.IsOpenshift)
if r.EnvConfig.MustDeployFRRK8sFromCNO && r.EnvConfig.IsOpenshift && (bgpType == metallbv1beta1.FRRK8sExternalMode) {
Copy link
Member

Choose a reason for hiding this comment

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

not sure I understand the MustDeployFRRK8sFromCNO env var, I thought "external" in openshift always comes from cno?

Copy link
Member Author

Choose a reason for hiding this comment

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

nope, the user will deploy metallb as always. This is to force the openshift specific behaviour only in ocp and only when the user didn't opt-in to a specific mode.

@fedepaol fedepaol force-pushed the cnodeploysfrrk8s branch 3 times, most recently from 8bd8abf to b76a91f Compare July 22, 2024 10:25
return err
}
}

err := config.Validate()
Copy link
Member

Choose a reason for hiding this comment

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

should we add a validation for external + ns must be specified together?

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 guess, with the premise that with the current defaults, to get into this scenario the user must willingly remove the default env variable and shoot himself in the foot.

We allow setting the external mode from the MetalLB crd, and we also
allow to specify the namespace it is running on.

Signed-off-by: Federico Paolinelli <[email protected]>
Starting from 4.17, the Cluster Network Operator will deploy frr-k8s.
Here we switch external to be the default deployment method in
openshift, and add the code to instruct CNO to deploy frr-k8s (and to
wait until the right version is available).

Signed-off-by: Federico Paolinelli <[email protected]>
Signed-off-by: Federico Paolinelli <[email protected]>
Copy link
Member

@oribon oribon left a comment

Choose a reason for hiding this comment

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

lgtm

@oribon oribon mentioned this pull request Aug 7, 2024
@oribon
Copy link
Member

oribon commented Aug 8, 2024

obsoleted by #487

@oribon oribon closed this Aug 8, 2024
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.

2 participants