awels
commented
1 year ago /test pull-csi-driver-split-k8s-suite-k8s-1.23
Closed awels closed 1 year ago
awels
commented
1 year ago /test pull-csi-driver-split-k8s-suite-k8s-1.23
awels
commented
1 year ago So I went back and forth on this, even going as far as to create a make generate-dev-overlay locally that essentially just generates the overlay yamls but doesn't apply it. The reason I eventually rejected this is because I am not guaranteed that all the information is static in the dev environment. It would be nice to haven an overlay example (which is generated on the fly) already in the overlay directory, so that people can then create their own overlay for whatever environment they have.
I was hoping a make cluster-sync would be able to generate the overlay for any cluster, but I am not sure how feasible this is.
I am using only the most basic kustomize stuff, no generators or transformers, which might be better, so we can get some of the logic out of the bash scripts and into there. But I wanted to start simple, and make it more complicated from there.
awels
commented
1 year ago Yes, good point also give me an opportunity to give some examples of the overlays. Let me update the PR to include this.
awels
commented
1 year ago @davidvossel I updated the README, hopefully it is understandable on what to do.
kubevirt-bot
commented
1 year ago [APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: davidvossel
The full list of commands accepted by this bot can be found here.
The pull request process is described here
Signed-off-by: Alexander Wels awels@redhat.com
What this PR does / why we need it: there are 3 directories:
tenant: This contains common objects deployed to the tenant cluster. node daemonset, namespace, roles, etc.controller-tenant: This is used with deploying the controller in the tenant cluster. This requires a secret in the tenant cluster, so it can do things in the infra clustercontroller-infra: This is used when the controller is deployed in the infra cluster.The following environment variables allow you to modify behavior of the deployment:
TENANT_CLUSTER_NAMESPACEThis is the namespace the tenant cluster VMs are deployed in, in the infra cluster defaults to 'kvcluster' if unsetCSI_DRIVER_NAMESPACEThis is the namespace the csi driver is installed in the tenant cluster. Defaults to 'kubevirt-csi-driver' if unsetINFRA_STORAGE_CLASSThis is the infra storage class used for backing the storage provided to the tenant cluster. Defaults to 'local' if unsetINFRA_REGISTRYThis is the name of the registry used for the controller image when the controller is installed in the infra cluster. Defaults to 'registry:5000' if unset. If REGISTRY is set, it will use the value of REGISTRY instead. This is so an external registry can be used for both infra and tenant clustersREGISTRYThis is the name of the registry used when deploying the daemonset (and the controller if the controller is deployed in the tenant cluster). Defaults to '192.168.66.2:5000' if unset (this is the exposed registry on the default kubevirtci dev cluster)TARGET_NAMEThis is the name of the image inside the specified registry. Defaults to 'kubevirt-csi-driver' if unset.TAGThis is the tag for both the controller deployment and node\ daemonset. Defaults to 'latest' if unset.REGISTRY/TARGETNAME:TAG is used by make to build the image and push it to the registry as well. This should allow one to build and generate the appropriate overlay for an external registry and cluster.
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 #Special notes for your reviewer: I think this will completely break the bin_data integration since I moved around all the files.
Also I noticed that the config map is deployed to tenant in split mode, and I don't think the nodes actually care about the config map so I see no reason to deploy the config map, just wanted to verify this is an accurate observation.
Release note: