-
Notifications
You must be signed in to change notification settings - Fork 53
✨ docs: remove OCM from user-facing docs; point to vcluster for OCM-style workflows #552
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -32,11 +32,8 @@ plane can run pods using worker nodes of the hosting cluster. | |
| - *external*: an external cluster that is imported as a control plane (this | ||
| is in the roadmap but not yet implemented) | ||
|
|
||
| - *ocm*: a control plane that uses the | ||
| [multicluster-controlplane project](https://github.com/open-cluster-management-io/multicluster-controlplane) | ||
| for managing multiple clusters. | ||
| - (Deprecated in docs) Traditional OCM-specific control plane references have been removed from the primary supported list. OCM-style multi-cluster/federation workflows are supported via integrations running on `vcluster` instances when needed. See the `vcluster` type below for details. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The deprecation is not just in the documentation. This type is deprecated, period. |
||
|
|
||
| When using KubeFlex, users interact with the API server | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why delete this line? |
||
| of the hosting cluster to create or delete control planes. | ||
| KubeFlex defines a ControlPlane CRD that represents a Control Plane. | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -341,27 +341,29 @@ the URL for the server as `https://kubeflex-control-plane:<nodeport>` | |
|
|
||
|
|
||
| ## Control Plane Types | ||
|
|
||
| At this time KubFlex supports the following control plane types: | ||
|
|
||
| - k8s: this is the stock Kube API server with a subset of controllers running in the controller manager. | ||
| - ocm: this is the [Open Cluster Management Multicluster Control Plane](https://github.com/open-cluster-management-io/multicluster-controlplane), which provides a basic set of capabilities such as | ||
| clusters registration and support for the [`ManifestWork` API](https://open-cluster-management.io/concepts/manifestwork/). | ||
| - vcluster: this is based on the [vcluster project](https://www.vcluster.com) and provides the ability to create pods in the hosting namespace of the hosting cluster. | ||
| - host: this control plane type exposes the underlying hosting cluster with the same control plane abstraction | ||
| used by the other control plane types. | ||
| - external: this control plane type represents an existing cluster that was not created by KubeFlex and is not the KubeFlex hosting cluster. | ||
| At this time KubeFlex focuses documentation on the following supported control plane types: | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the existing wording ("At this time KubFlex supports the following control plane types") is just fine. We are removing support for the |
||
|
|
||
| - k8s: the stock Kubernetes API server with a subset of controllers active in the controller manager. | ||
| - vcluster: virtual clusters based on the vCluster project that run on the hosting cluster; they can run pods and host integrations. Note: OCM-style multi-cluster/federation workflows (for example ManifestWork-like functionality) are supported by deploying integrations to `vcluster` instances when required. | ||
| - host: exposes the underlying hosting cluster as a control plane using the same abstraction as other types. | ||
| - external: represents an existing cluster that was not created by KubeFlex and is managed by adoption workflows. | ||
| - k8s: this is the stock Kube API server with a subset of controllers running in the controller manager. | ||
| - vcluster: this is based on the [vcluster project](https://www.vcluster.com) and provides the ability to create pods in the hosting namespace of the hosting cluster. Note: OCM-style multi-cluster federation and ManifestWork-like workflows are supported via integrations deployed to `vcluster` instances when needed. | ||
| - host: this control plane type exposes the underlying hosting cluster with the same control plane abstraction | ||
| used by the other control plane types. | ||
| - external: this control plane type represents an existing cluster that was not created by KubeFlex and is not the KubeFlex hosting cluster. | ||
|
Comment on lines
+350
to
+354
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This looks like a copy of the material just above it. |
||
|
|
||
| ## Control Plane Backends | ||
|
|
||
| KubeFlex roadmap aims to provide different types of backends: shared, dedicated, and for | ||
| each type the ability to choose if etcd or sql. At this time only the following | ||
| combinations are supported based on control plane type: | ||
| each type the ability to choose etcd or SQL backends. At this time the following | ||
| combinations are supported: | ||
|
|
||
| - k8s: shared postgresql | ||
| - ocm: dedicated etcd | ||
| - k8s: shared PostgreSQL | ||
| - vcluster: dedicated sqlite | ||
|
|
||
| Note: OCM-specific backends are no longer emphasized in the primary docs; OCM-style federation scenarios should be implemented via integrations running on `vcluster` instances. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. "OCM-specific backends are no longer emphasized in the primary docs" is not strong enough. They are not just "no longer emphasized in the primary docs". This PR should be removing them from all the user-facing documentation, in anticipation of removing them from the implementation. |
||
|
|
||
| ## Creating with a selected control plane type | ||
|
|
||
| If you are using the kflex CLI, you can use the flag `--type` or `-t` to select a particular | ||
|
|
@@ -372,13 +374,6 @@ To create a control plane of type `vcluster` run the command: | |
| ```shell | ||
| kflex create cp2 --type vcluster | ||
| ``` | ||
|
|
||
| To create a control plane of type `ocm` run the command: | ||
|
|
||
| ```shell | ||
| kflex create cp3 --type ocm | ||
| ``` | ||
|
|
||
| To create a control plane of type `host` run the command: | ||
|
|
||
| ```shell | ||
|
|
||
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.
The
vclustertype is described above, not below.