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

cluster: Allow deploying controller on external cluster #255

Merged
merged 1 commit into from
Nov 7, 2024

Conversation

oshoval
Copy link
Member

@oshoval oshoval commented Sep 30, 2024

What this PR does / why we need it:
Allows to deploy Multus dynamic networks controller on external provider.
Deploys official multus release (doesnt build latest as this repo usually do).

Usage example:

export CLUSTER_TYPE=external
export KUBECONFIG=<kubeconfig>
export IMAGE_REGISTRY=quay.io/<your_quay>
export MULTUS_VERSION=v4.1.1

If CRIO is used, use export CRI=crio (works also for non external clusters).
Note kubevirtci clusters require it.

If You don't want to deploy multus at all use (you must deploy it yourself as the controller depends on it)
export SKIP_MULTUS_DEPLOYMENT=true (supported only for external clusters)

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #252

Special notes for your reviewer (optional):
Can be improved later according needs, for example to support deploying latest Multus,
or to support local registries.

File name is bit tricky as it has the word kind in its name, we can consider adding a new file instead
with those changes for external providers, and source the common functions.

@oshoval oshoval marked this pull request as ready for review October 1, 2024 11:31
@oshoval oshoval requested a review from maiqueb as a code owner October 1, 2024 11:31
@oshoval oshoval changed the title cluster: Allow using kubevirtci external cluster cluster: Allow deploying on external cluster Oct 1, 2024
@oshoval oshoval changed the title cluster: Allow deploying on external cluster cluster: Allow deploying controller on external cluster Oct 1, 2024
@oshoval
Copy link
Member Author

oshoval commented Oct 6, 2024

addressed comments, ptal

@oshoval oshoval requested a review from maiqueb October 8, 2024 13:35
Copy link
Collaborator

@maiqueb maiqueb left a comment

Choose a reason for hiding this comment

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

Just a comment / question.

}

cleanup() {
rm -rf multus-cni
git checkout -- manifests/
}

install_multus() {
if [[ $MULTUS_VERSION == "latest" ]]; then
echo "error: MULTUS_VERSION cant be latest, when using non default CLUSTER_TYPE $CLUSTER_TYPE"
Copy link
Collaborator

Choose a reason for hiding this comment

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

maybe be explicit about what cluster type you need to use here.

Also, why is this limitation in place ?

Copy link
Member Author

@oshoval oshoval Oct 9, 2024

Choose a reason for hiding this comment

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

We reach here only when CLUSTER_TYPE != kind which is the default value.
So the CLUSTER_TYPE is already set correctly, what is not set is MULTUS_VERSION and this what the comment says.

The reason we have it, is that for default CLUSTER_TYPE we use setup_cluster.sh [1] that creates a kind cluster and then build + deploy latest multus-cni.
Here we dont want to create a new cluster (which is the answer for the question), so for now we support deploying an official multus release if desired, by providing its MULTUS_VERSION.

There isn't such thing
https://raw.githubusercontent.com/k8snetworkplumbingwg/multus-cni/latest/deployments/multus-daemonset-thick.yml so this assert the value of the version is valid.

If we would need to also support latest freshly built multus-cni in the future we can but it isnt as straight forward.
This PR is MVP.

[1] https://github.com/k8snetworkplumbingwg/multus-cni/blob/adfb270991d410417a71755d01f53445510ef2a0/e2e/setup_cluster.sh#L25

PR desc has suggested exports.

Copy link
Collaborator

Choose a reason for hiding this comment

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

OK, so change two things in the PR:

  • stop saying "default cluster type". Start saying kind cluster. Be explicit.
  • explain why: when kind is used, it already has the latest multus deployed.

}

cleanup() {
rm -rf multus-cni
git checkout -- manifests/
}

install_multus() {
if [[ $MULTUS_VERSION == "latest" ]]; then
echo "error: MULTUS_VERSION cant be latest, when using non default CLUSTER_TYPE $CLUSTER_TYPE"
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
echo "error: MULTUS_VERSION cant be latest, when using non default CLUSTER_TYPE $CLUSTER_TYPE"
echo "error: kind cluster is already shipping latest multus (built from src). No point installing it

Copy link
Member Author

@oshoval oshoval Oct 9, 2024

Choose a reason for hiding this comment

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

it is not accurate, we reach here only if CLUSTER_TYPE isn't kind
and then we can only use snapshot and not latest
please see https://github.com/k8snetworkplumbingwg/multus-dynamic-networks-controller/pull/255/files#r1793352623

}

cleanup() {
rm -rf multus-cni
git checkout -- manifests/
}

install_multus() {
Copy link
Collaborator

Choose a reason for hiding this comment

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

so this function is only invoked on kind based clusters, right ?

Let's rename it to something that hints this is used to request a particular multus snapshot / release.

Does that make sense to you ?

Copy link
Member Author

@oshoval oshoval Oct 9, 2024

Choose a reason for hiding this comment

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

Copy link
Collaborator

Choose a reason for hiding this comment

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

darn. right. I hate bash.

Allows to deploy Multus dynamic networks controller on external provider.
Deploys fixed multus release (doesnt build latest as this repo usually do).

Usage:

export CLUSTER_TYPE=external
export KUBECONFIG=<kubeconfig>
export IMAGE_REGISTRY=quay.io/<your_quay>
export MULTUS_VERSION=v4.1.1

If CRIO is used, use export CRI=crio (works also for non external clusters).

If You don't want to deploy multus at all use (you must deploy it yourself as the controller depends on it)
export SKIP_MULTUS_DEPLOYMENT=true (supported only for external clusters)

Signed-off-by: Or Shoval <[email protected]>
@oshoval
Copy link
Member Author

oshoval commented Oct 27, 2024

tried to address comments, according the latest discussion, please take a look

@oshoval oshoval requested a review from maiqueb November 7, 2024 07:44
Copy link
Collaborator

@maiqueb maiqueb left a comment

Choose a reason for hiding this comment

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

Did you check this works on crio ?

@oshoval
Copy link
Member Author

oshoval commented Nov 7, 2024

yes, for example kubevirtci has CRIO

@maiqueb maiqueb merged commit 84cf644 into k8snetworkplumbingwg:main Nov 7, 2024
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support cluster-sync on external provider
2 participants