Skip to content

Conversation

slovern
Copy link
Contributor

@slovern slovern commented Nov 17, 2023

[WIP] [TELCODOCS-1478](https://issues.redhat.com//browse/TELCODOCS-1478) hub-side templating

ON HOLD subject to updates to TALM (https://issues.redhat.com/browse/CNF-9102)

Version(s): TBD

Issue: https://issues.redhat.com/browse/TELCODOCS-1476

Link to docs preview:

About the PolicyGenTemplate CRD (new example PGT added)

Deploying a managed cluster with SiteConfig and GitOps ZTP
(added new optional procedure step 3.e)

QE review:

  • QE has approved this change.

Additional information:

@openshift-ci openshift-ci bot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Nov 17, 2023
@ocpdocs-previewbot
Copy link

ocpdocs-previewbot commented Nov 17, 2023

🤖 Updated build preview is available at:
https://68139--docspreview.netlify.app

Build log: https://circleci.com/gh/ocpdocs-previewbot/openshift-docs/35226

[id="ztp-deploying-siteconfig-hub-side-template_{context}"]
= Deploying a SiteConfig with hub-side templating

The following is an example `SiteConfig` custom resource (CR) that uses the `spec.clusters.siteConfigMap.data` field to specify per-site data to be used in hub side templating.

Choose a reason for hiding this comment

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

Suggested change
The following is an example `SiteConfig` custom resource (CR) that uses the `spec.clusters.siteConfigMap.data` field to specify per-site data to be used in hub side templating.
The following is a `SiteConfig` custom resource (CR) example that includes the new optional `spec.clusters.siteConfigMap` where the `data` field contains per-site data to be used in hub side templating.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

There can be an issue with referring to a feature as "new" or "optional" in product documentation because, as time passes, the feature ceases to be new but the documentation won't be updated to reflect that. Release Notes are the best place to point out the newness of a feature.
I've rephrased though, in order to draw attention to the spec.clusters.siteConfigMap section and mention the data field separately

Choose a reason for hiding this comment

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

Ok, but I think we should still say that it's an optional section, it's not mandatory. 🤔

----
[NOTE]
====
The generated `ConfigMap` CRs follow the naming convention `ztp-site-<cluster_name>-configMap` and are created under the same namespace as the policy resource.
Copy link

@irinamihai irinamihai Nov 17, 2023

Choose a reason for hiding this comment

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

Maybe just leave

The generated ConfigMap CRs follow the naming convention ztp-site-<cluster_name>.

since you're explaining the namespace aspect below?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok. I removed reference to the namespace and left it at ztp-site-<cluster_name>-configMap.

Choose a reason for hiding this comment

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

It should be ztp-site-<cluster-name> though.

====
The generated `ConfigMap` CRs follow the naming convention `ztp-site-<cluster_name>-configMap` and are created under the same namespace as the policy resource.
The `siteConfigMap` section includes the namespace where the `ConfigMap` is to be created.

Choose a reason for hiding this comment

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

Suggested change
The `siteConfigMap` section includes the namespace where the `ConfigMap` is to be created.
The `siteConfigMap` section includes the namespace where the `ConfigMap` is to be created and its name.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

sorry @irinamihai I'm not clear on what the "its" refers to here.
Is "its name" the name of the namespace or the name of the ConfigMap?
The "name of the ConfigMap" doesn't seem right but the "name of the namespace" sounds kinda off too.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

name refers to ConfigMap - add this to the example yaml
Something like
SiteConfigMap
name: site-example-sno

The generated `ConfigMap` CRs follow the naming convention `ztp-site-<cluster_name>-configMap` and are created under the same namespace as the policy resource.
The `siteConfigMap` section includes the namespace where the `ConfigMap` is to be created.
The `siteConfigMap.namespace` you specify must be the same as the namespace used by the `PolicyGenTemplate` resources.

Choose a reason for hiding this comment

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

Suggested change
The `siteConfigMap.namespace` you specify must be the same as the namespace used by the `PolicyGenTemplate` resources.
For a successful integration with the PolicyGenTemplate, the `siteConfigMap.namespace` you specify must be the same as the namespace used by the `PolicyGenTemplate` resources.

----
include::snippets/ztp_example-siteconfig-hub-side-templating.yaml[]
----
[NOTE]
Copy link

@irinamihai irinamihai Nov 17, 2023

Choose a reason for hiding this comment

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

Maybe the section below can be a bit restructured to something like:

Besides the data field, the siteConfigMap section also includes the namespace where the ConfigMap is to be created and its name.

For a successful integration with the PolicyGenTemplate, the siteConfigMap.namespace you specify must be the same as the namespace used by the PolicyGenTemplate resources.

If not specified, siteConfigMap.namespace will default to , and siteConfigMap.namespace to ztp-site-<cluster_name>.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Maybe we could have another look at this together?

.....
----

The following example uses hub-side templating to generate multiple `machineConfigs` from a single {rh-rhacm} policy:

Choose a reason for hiding this comment

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

The following example uses hub side templating to generate PerformanceProfile {rh-rhacm} policies for the cluster that have the following labels: group-du-sno-zone: "zone-1", hardware-type: "dell-poweredge-xr12".

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thanks. I've proposed a change along these lines.

@openshift-ci openshift-ci bot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Nov 21, 2023
Comment on lines 104 to 109
dell-poweredge-xr12-ptpcfgslave-profile-interface: "ens5f0"
dell-poweredge-xr12-cpu-isolated: "2-19,22-39"
dell-poweredge-xr12-cpu-reserved: "0-1,20-21"
dell-poweredge-xr12-hugepages-default: "1G"
dell-poweredge-xr12-hugepages-size: "1G"
dell-poweredge-xr12-hugepages-count: "32"

Choose a reason for hiding this comment

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

Maybe we can remove this and instead include:

sno-1-sriov-network-vlan-1: "140"
sno-1-sriov-network-vlan-2: "150"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

thanks

+
[NOTE]
====
As an alternative to populating the siteConfigMap section in the `SiteConfig` CR you can store site-specific template data in the ZTP GitOps repo, as `ConfigMap` CRs, then push this template data to the hub cluster.

Choose a reason for hiding this comment

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

Suggested change
As an alternative to populating the siteConfigMap section in the `SiteConfig` CR you can store site-specific template data in the ZTP GitOps repo, as `ConfigMap` CRs, then push this template data to the hub cluster.
As an alternative to populating the siteConfigMap section in the `SiteConfig` CR you can store site-specific template data in the ZTP GitOps repo, as `ConfigMap` CRs, and have them synced to the hub cluster.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok

include::snippets/ztp_example-pgt-hub-side-templating.yaml[]
----

Using the `fromConfigMap` function, the file defines site-specific configurations for each cluster defined in the `PolicyGenTemplate`.

Choose a reason for hiding this comment

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

Suggested change
Using the `fromConfigMap` function, the file defines site-specific configurations for each cluster defined in the `PolicyGenTemplate`.
Using the `fromConfigMap` function, site-specific configuration is selected for each cluster defined in the `PolicyGenTemplate`.

----

Using the `fromConfigMap` function, the file defines site-specific configurations for each cluster defined in the `PolicyGenTemplate`.
This example generates policies for clsuters that have the labels:

Choose a reason for hiding this comment

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

Suggested change
This example generates policies for clsuters that have the labels:
This example generates policies for clusters that have the labels:

@slovern slovern force-pushed the TELCODOCS-1476 branch 4 times, most recently from 21d709c to 81a7e64 Compare November 24, 2023 14:56
@openshift-bot
Copy link

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@openshift-ci openshift-ci bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 9, 2024
@openshift-merge-robot openshift-merge-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Apr 12, 2024
@openshift-merge-robot
Copy link

PR needs rebase.

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/test-infra repository.

Copy link

openshift-ci bot commented Apr 12, 2024

@slovern: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/validate-portal 78ef28a link true /test validate-portal

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/test-infra repository. I understand the commands that are listed here.

@openshift-bot
Copy link

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

@openshift-ci openshift-ci bot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels May 13, 2024
@openshift-bot
Copy link

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

@openshift-ci openshift-ci bot closed this Jun 13, 2024
Copy link

openshift-ci bot commented Jun 13, 2024

@openshift-bot: Closed this PR.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. size/M Denotes a PR that changes 30-99 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants