Skip to content

Comments

telco-hub: add first set of reference templates for the cluster-compare tool#110

Merged
openshift-merge-bot[bot] merged 25 commits intoopenshift-kni:mainfrom
jmontesi:telco-hub-kube-compare
Aug 5, 2025
Merged

telco-hub: add first set of reference templates for the cluster-compare tool#110
openshift-merge-bot[bot] merged 25 commits intoopenshift-kni:mainfrom
jmontesi:telco-hub-kube-compare

Conversation

@jmontesi
Copy link
Contributor

@jmontesi jmontesi commented Feb 18, 2025

The templates cover the reference CRs for the following operators:

  • LSO
  • ODF
  • TALM
  • ACM
  • Cluster logging

Also, a make recipe to prevent any mismatch between the templates and the reference CRs is included.

…re tool

The templates cover the reference CRs for:
* LSO
* ODF
* TALM
* ACM (without the observability configuration)
* Cluster logging
* Quay

The ACM MultiClusterHub is also updated to include the SiteConfig
Operator.
@openshift-ci openshift-ci bot requested review from MarSik and lack February 18, 2025 14:33
@openshift-ci
Copy link

openshift-ci bot commented Feb 18, 2025

Hi @jmontesi. Thanks for your PR.

I'm waiting for a openshift-kni member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

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.

@openshift-ci openshift-ci bot added the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label Feb 18, 2025
@imiller0
Copy link
Collaborator

/ok-to-test

@openshift-ci openshift-ci bot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Feb 18, 2025
name: version
status:
desired:
version: {{ template "versionMatch" (list .status.desired.version "4.18") }}
Copy link
Collaborator

Choose a reason for hiding this comment

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

Current "main" branch should be 4.19

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The reference-crs still point to channel versions related to 4.18. I guess both the reference-crs and the templates should be updated at once.

Copy link
Member

Choose a reason for hiding this comment

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

Main has moved on to 4.20 ;)

Copy link
Collaborator

Choose a reason for hiding this comment

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

There are a couple of changes for 4.19 which are pending based on testing. Until we merge those we are trying to keep main at 4.19 to make things easier.

allOrNoneOf:
- path: optional/logging/clusterLogNS.yaml
- path: optional/logging/clusterLogOperGroup.yaml
- path: optional/logging/clusterLogSubscription.yaml
Copy link
Collaborator

Choose a reason for hiding this comment

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

Should include ClusterLogForwarder here as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The ClusterLogForwarder CR is not present in the reference-crs, so I think that CR along with its template should be added in another PR.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Agreed. In reality it is almost entirely customer specific so it can be considered part of their custom overlay and not vetted by the cluster-compare.

Comment on lines 67 to 75
- name: optional-quay
description: |-
TODO: Link to Hub RDS Quay section when published
components:
- name: quay-operator
allOrNoneOf:
- path: optional/quay/quayNS.yaml
- path: optional/quay/quayOperatorGroup.yaml
- path: optional/quay/quaySubscription.yaml
Copy link
Collaborator

Choose a reason for hiding this comment

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

Quay is not yet published in the RDS. Let's omit it here until it is published.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done. Removed the reference to the Quay operator CR templates.

Comment on lines 6 to 7
annotations:
workload.openshift.io/allowed: management
Copy link
Collaborator

Choose a reason for hiding this comment

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

We do not enable workload partitioning for the hub cluster. This annotation should be optional.
One option is we can remove it here entirely and add it to the global ignored list.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

{{- range .spec.storageClassDevices }}
- storageClassName: {{ .storageClassName }}
forceWipeDevicesAndDestroyAllData: true
volumeMode: Block
Copy link
Collaborator

Choose a reason for hiding this comment

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

Block or Filesystem is ok.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done. Both options allowed in the template.

@@ -0,0 +1,7 @@
---
Copy link
Collaborator

Choose a reason for hiding this comment

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

Omit all quay until published.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have omitted the Quay operator check by removing it from the metadata.yaml. As the source-crs are present in the repo I assume it's also ok to have the templates.

Copy link
Collaborator

Choose a reason for hiding this comment

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

There is a pending PR to remove quay from the repo until we've verified. We should remove it here too.

- ReadWriteOnce
resources:
requests:
storage: 20Gi
Copy link
Collaborator

Choose a reason for hiding this comment

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

These storage values should check for compliance against a minimum value. (here and 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.

I'm not sure how to enforce this condition with the options currently available in the cluster-compare tool. If it was just a number a logical "greater/lower than" could be used but the fact that different capacity units can be used requires more involved processing. Any idea on how to check this?

Copy link
Member

Choose a reason for hiding this comment

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

We don't have any "easy" way to do this, but it may not be too hard to write a helper template to do it. In the short term, it's better to just "allow any value" if this is something customers will be customizing, and open up a new story &PR to restrict the value to a minimum value.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Modified to allow any value.

Comment on lines 32 to 38
# Replace <http-server-address:port> with the address of the local web server that stores the RHCOS images.
# The images can be downloaded from "https://mirror.openshift.com/pub/openshift-v4/x86_64/dependencies/rhcos/".
- cpuArchitecture: "x86_64"
openshiftVersion: "4.17"
rootFSUrl: {{ (index .spec.osImages 0).rootFSUrl }}
url: {{ (index .spec.osImages 0).url }}
version: "417.94.202409121747-0"
Copy link
Collaborator

Choose a reason for hiding this comment

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

We should allow any content here. The specific set of versions they will deploy will vary.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

labels:
app: assisted-service
data:
{{- .data | toYaml | nindent 2 }}
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
{{- .data | toYaml | nindent 2 }}
{{- .data | toYaml | nindent 2 }}

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

Copy link
Member

Choose a reason for hiding this comment

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

(technically was not needed because {{- ... eats all whitespace and the later nindent 2 adds the proper carriage return and indentation)

watchAllNamespaces: true
# some servers do not support virtual media installations
# when the image is served using the https protocol
# disableVirtualMediaTLS: true
Copy link
Collaborator

Choose a reason for hiding this comment

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

Make this field optional so that an installation which includes it is ok.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

- pathToKey: metadata.ownerReferences
- pathToKey: spec.finalizers
allowStatusCheck:
- include: defatuls
Copy link
Member

Choose a reason for hiding this comment

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

Typo

Suggested change
- include: defatuls
- include: defaults

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

Copy link
Member

@lack lack left a comment

Choose a reason for hiding this comment

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

I added a couple minor coments throughout, but I think one big problem I see is that there's no CI step to ensure that these templates match the actual source-crs in source control. Take a look at how the telco-ran area does this as a good example. Without CI enforcement, you'll get drift as the source-crs and/or cluster-compare templates change over time.

@lack
Copy link
Member

lack commented Jun 20, 2025

The other thing I'd recommend before committing this is to run it against a real cluster (or a few real clusters) to make sure you're starting with a fairly clean set of templates that don't have any obvious false-positives to start with.

@jmontesi
Copy link
Contributor Author

I added a couple minor coments throughout, but I think one big problem I see is that there's no CI step to ensure that these templates match the actual source-crs in source control. Take a look at how the telco-ran area does this as a good example. Without CI enforcement, you'll get drift as the source-crs and/or cluster-compare templates change over time.

That's right. I will have a look. In any case I think it's better to open a new PR for this.

@jmontesi
Copy link
Contributor Author

The other thing I'd recommend before committing this is to run it against a real cluster (or a few real clusters) to make sure you're starting with a fairly clean set of templates that don't have any obvious false-positives to start with.

I've tested it against a Hub cluster that I've deployed in the lab. That should provide a fairly clean baseline.

@lack
Copy link
Member

lack commented Jun 24, 2025

I added a couple minor coments throughout, but I think one big problem I see is that there's no CI step to ensure that these templates match the actual source-crs in source control. Take a look at how the telco-ran area does this as a good example. Without CI enforcement, you'll get drift as the source-crs and/or cluster-compare templates change over time.

That's right. I will have a look. In any case I think it's better to open a new PR for this.

I understand the reasoning here, but if you don't add enforcement right away, all the other outstanding PRs (#111 #232 #208) will suddenly make these templates out-of-sync.

@lack
Copy link
Member

lack commented Jul 15, 2025

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Jul 15, 2025
@imiller0
Copy link
Collaborator

/ok-to-test

@jmontesi
Copy link
Contributor Author

/retest

@openshift-ci openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Jul 17, 2025
@imiller0
Copy link
Collaborator

/ok-to-test

Copy link
Member

@lack lack left a comment

Choose a reason for hiding this comment

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

Looking good! My only concern is that we should not duplicate the CI scripts.

Copy link
Member

Choose a reason for hiding this comment

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

Now that we have 2 areas that do the same check (here and telco-ran), maybe we should consider putting more of the logic in a shared helper script instead of copying it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

To be implemented in a follow-up PR as discussed.

Copy link
Member

Choose a reason for hiding this comment

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

Likewise, let's share the same compare.sh with telco-ran as opposed to making a copy.

Copy link
Contributor Author

@jmontesi jmontesi Jul 20, 2025

Choose a reason for hiding this comment

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

To be implemented in a follow-up PR as discussed.

name: version
status:
desired:
version: {{ template "versionMatch" (list .status.desired.version "4.19") }}
Copy link
Member

Choose a reason for hiding this comment

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

HEAD is currently 4.20, isn't it?

Copy link
Collaborator

Choose a reason for hiding this comment

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

Currently 4.19 which will very soon get copied back to release-4.19 and then main updated to 4.20

- name: version-check
description: |-
A mismatch here means you may be using the wrong reference.
This reference was designed for OpenShift 4.18.
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
This reference was designed for OpenShift 4.18.
This reference was designed for OpenShift 4.20

@imiller0
Copy link
Collaborator

/ok-to-test

Copy link
Collaborator

@imiller0 imiller0 left a comment

Choose a reason for hiding this comment

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

Two minor comments, otherwise LGTM


.PHONY: sync
sync: convert
@./compare.sh --sync "../reference-crs" renderedv1 No newline at end of file
Copy link
Collaborator

Choose a reason for hiding this comment

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

Fix newline please

sync_cr "$RENDERDIR" "$SOURCEDIR" compare_ignore
else
compare_cr "$RENDERDIR" "$SOURCEDIR" compare_ignore
fi No newline at end of file
Copy link
Collaborator

Choose a reason for hiding this comment

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

Fix newline please

@lack
Copy link
Member

lack commented Jul 25, 2025

/ok-to-test

Copy link
Collaborator

@imiller0 imiller0 left a comment

Choose a reason for hiding this comment

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

/lgtm

@openshift-ci openshift-ci bot added lgtm Indicates that a PR is ready to be merged. approved Indicates a PR has been approved by an approver from all required OWNERS files. labels Aug 4, 2025
@imiller0
Copy link
Collaborator

imiller0 commented Aug 4, 2025

/ok-to-test

@openshift-ci openshift-ci bot removed the lgtm Indicates that a PR is ready to be merged. label Aug 5, 2025
Copy link
Collaborator

@imiller0 imiller0 left a comment

Choose a reason for hiding this comment

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

/lgtm

@openshift-ci openshift-ci bot added the lgtm Indicates that a PR is ready to be merged. label Aug 5, 2025
@openshift-ci
Copy link

openshift-ci bot commented Aug 5, 2025

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: imiller0, jmontesi

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@imiller0
Copy link
Collaborator

imiller0 commented Aug 5, 2025

/ok-to-test

@openshift-merge-bot openshift-merge-bot bot merged commit d14dcfb into openshift-kni:main Aug 5, 2025
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. ok-to-test Indicates a non-member PR verified by an org member that is safe to test.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants