-
Notifications
You must be signed in to change notification settings - Fork 1.8k
TELCODOCS-2281: Adding siteconfig to clusterinstance API docs #96809
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
Conversation
|
@rohennes: This pull request references TELCODOCS-2281 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
🤖 Tue Sep 30 12:43:36 - Prow CI generated the docs preview: https://96809--ocpdocs-pr.netlify.app/ |
| // * edge_computing/ztp-migrate-clusterinstance.adoc | ||
|
|
||
| :_mod-docs-content-type: PROCEDURE | ||
| [id="ztp-preparing-migrate-clusterinstance_{context}"] |
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.
🤖 [error] OpenShiftAsciiDoc.IdHasContextVariable: ID is missing the '_{context}' variable at the end of the ID.
de07088 to
eb7d799
Compare
|
@rohennes: This pull request references TELCODOCS-2281 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
1 similar comment
|
@rohennes: This pull request references TELCODOCS-2281 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
eb7d799 to
4dba270
Compare
4dba270 to
8e14bc1
Compare
|
@rohennes: This pull request references TELCODOCS-2281 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.20.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
8e14bc1 to
5f753d7
Compare
7e66698 to
d76ad75
Compare
ac3fdcd to
e98b409
Compare
|
|
||
| The migration process involves the following high-level steps: | ||
|
|
||
| . Create a parallel pipeline by preparing a new Git folder in your repository and creating a new Argo CD project and application that monitors this folder. |
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.
I would say, preparing a new Git folder structure. Eventually, you will create a Git structure with all the elements required in your ZTP pipeline. See https://labs.sysdeseng.com/5g-ran-deployments-on-ocp-lab/4.19/deployment-considerations.html#git-repo-structure
|
|
||
| toc::[] | ||
|
|
||
| This content describes how to incrementally migrate {sno} clusters from `SiteConfig` custom resources (CRs) to `ClusterInstance` CRs. During migration, the existing and new pipelines run in parallel, so you can migrate clusters one at a time in a controlled and phased manner. |
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.
It does not have to be one cluster at a time; it can be in groups. The point here is that they do not have to be all of your fleet migrated simultaneously. You can choose what suits you best.
|
|
||
| The following sections describe how to migrate an example cluster, `sno1`, from using a `SiteConfig` CR to a `ClusterInstance` CR. | ||
|
|
||
| The following Git repository folder structure is used a basis for this example migration: |
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.
I would include the site-configs-v2 folder (at the same level as site-configs/). In the following folder structure I only see the old structure for the SiteConfig. In the Argo CD App definition for the ClusterInstance you're defining the root folder as site-configs-v2, so it makes sense to me to be shown here.
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.
Well, in the performing the migration procedure, the first step is to mirror the v1 folder, and I show the v2 folder structure there. So perhaps that's enough. The user can then use this v1 structure as a reference
70db14e to
63303f6
Compare
|
/lgtm |
leo8a
left a comment
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.
hey @rohennes, content looks good to me, just dropped a couple of nits here and there. Thanks for the PR.
|
|
||
| .Prerequisites | ||
| * You have logged in to the hub cluster as a user with `cluster-admin` privileges. | ||
| * All {sno} clusters have been successfully migrated to use `ClusterInstance` CRs and are managed by the another Argo CD application. |
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.
| * All {sno} clusters have been successfully migrated to use `ClusterInstance` CRs and are managed by the another Argo CD application. | |
| * All {sno} clusters have been successfully migrated to use `ClusterInstance` CRs and are managed by another Argo CD application. |
|
|
||
| .. Optionally, use the `siteconfig-converter` tool to automatically convert existing `SiteConfig` CRs to `ClusterInstance` CRs. | ||
|
|
||
| . When you complete the cluster migration, delete the original Argo project and application clean up any related resources. |
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.
| . When you complete the cluster migration, delete the original Argo project and application clean up any related resources. | |
| . When you complete the cluster migration, delete the original Argo project, and the application cleans up any related resources. |
|
|
||
| The following sections describe how to migrate an example cluster, `sno1`, from using a `SiteConfig` CR to a `ClusterInstance` CR. | ||
|
|
||
| The following Git repository folder structure is used a basis for this example migration: |
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 following Git repository folder structure is used a basis for this example migration: | |
| The following Git repository folder structure is used as a basis for this example migration: |
63303f6 to
b5f2048
Compare
|
New changes are detected. LGTM label has been removed. |
|
lgtm |
slovern
left a comment
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.
Lots of work in here. Very clearly structured set of procedures to break down a substantial task.
A few comments to consider / rage against as you see fit
| ==== | ||
| The SiteConfig Operator only reconciles updates for `ClusterInstance` objects. The controller does not monitor or manage deprecated `SiteConfig` objects. | ||
|
|
||
| Use either `SiteConfig` or `ClusterInstance` CRs for cluster definitions in the hub cluster to avoid unintended deployments of managed clusters. |
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.
Is the meaning here "choose either on or the other"?
Or is it "use either one ... makes no difference to me"?
I've a feeling it's the first but I think this could be clearer.
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.
@sudomakeinstall2 - is it better to remove the line "Use either SiteConfig or ClusterInstance CRs for cluster definitions in the hub cluster to avoid unintended deployments of managed clusters."
If we are doing an incremental migration, won't there be both SiteConfig and ClusterInstance CRs in existence at the same time? So this point seems counter-intuitive?
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.
Removed the sentence "Use either SiteConfig or ClusterInstance CRs for cluster definitions in the hub cluster to avoid unintended deployments of managed clusters."
to avoid confusion
| sourceRepos: | ||
| - '*' | ||
| ---- | ||
| <1> The `ClusterInstance` CR manages the `siteconfig.open-cluster-management.io` object instead of the `SiteConfig` CR. |
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.
are we doing callouts or the new approach with bullet points as in line 123 below??
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.
Perhaps let's leave the callouts as they are for now.
|
@rohennes: This pull request references TELCODOCS-2281 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "4.21.0" version, but no target version was set. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
b5f2048 to
bab6f57
Compare
bab6f57 to
f16dff0
Compare
|
@rohennes: all tests passed! Full PR test history. Your PR dashboard. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
/cherrypick enterprise-4.20 |
|
@slovern: new pull request created: #99873 In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
TELCODOCS-2281: Procedure to migrate from clusterinstance to siteconfig
Version(s):
4.20+
Issue:
https://issues.redhat.com/browse/TELCODOCS-2281
Link to docs preview:
https://96809--ocpdocs-pr.netlify.app/openshift-enterprise/latest/edge_computing/ztp-migrate-clusterinstance.html
QE review: