[OSDOCS-19523]: Setting up a management cluster for HCP on Azure

[lahinson]

Version(s): 4.22+

Issue: https://redhat.atlassian.net/browse/OSDOCS-19523

Link to docs preview: https://112346--ocpdocs-pr.netlify.app/openshift-enterprise/latest/hosted_control_planes/hcp-deploy/hcp-deploy-azure.html#hcp-azure-mgmt-cluster_hcp-deploy-azure

QE review:

• SME has approved this change. (Bryan)
• QE has approved this change. (Alessandro)

Additional information:

[ocpdocs-previewbot]

🤖 Fri Jun 05 17:45:12 - Prow CI generated the docs preview:

https://112346--ocpdocs-pr.netlify.app/openshift-enterprise/latest/hosted_control_planes/hcp-deploy/hcp-deploy-azure.html

[lahinson]

@bryan-cox @Nirshal I thought the code on lines 76 - 79 looked a little unusual, so I searched the openshift-docs repo, and I don't see any other examples where we define an array like that in the official docs. Is there another way to create an array?

[Nirshal]

I don't know... I was following the upstream doc on that, it seemed a reasonable approach at the time. I think we need to wait for Bryan on that.

[lahinson]

Similar to my earlier comment, the code on lines 86 - 92 looks unconventional for the official docs. Suggestions for alternatives are appreciated.

[Nirshal]

The user should be made aware that if --external-dns-domain matches {cluster-name}.{base-domain}, the CPO creates a private DNS zone that shadows the cluster domain, causing *.apps DNS resolution to fail (console and ingress become unavailable). See hypershift#8480 for details.

@bryan-cox do you think it's worth adding a caveat here about DNS zone naming to help users avoid this condition? Or is this better covered in the private clusters doc?

[lahinson]

I plan to add the private clusters procedures in a separate PR, so that caveat will be covered there. If you'd like me to to mention it here, too, let me know.

[Nirshal]

The procedure creates the K8s secret but there doesn't seem to be a step that configures the HyperShift Operator to actually use external DNS. When I set up external DNS via MCE for ACM-30209 testing, I had to apply a ConfigMap to pass the install flags to the operator:

apiVersion: v1
kind: ConfigMap
metadata:
  name: hypershift-operator-install-flags
  namespace: local-cluster
data:
  installFlagsToAdd: "--external-dns-provider=azure --external-dns-credentials <secret> --external-dns-domain-filter <dns-zone>"
  installFlagsToRemove: ""

Without this, I suspect the HO wouldn't pick up the external DNS configuration and the external-dns pod from the verification step wouldn't be running. @bryan-cox can you confirm?

[lahinson]

I'll wait for Bryan's confirmation, but I have no problem adding those details if they are needed.

[Nirshal]

The upstream HyperShift docs (hypershift#8566) treat external DNS as optional. It might help to clarify upfront whether this entire procedure can be skipped if the user doesn't need external DNS, or if it's considered the recommended path for self-managed Azure.

[lahinson]

The upstream HyperShift docs (openshift/hypershift#8566) treat external DNS as optional. It might help to clarify upfront whether this entire procedure can be skipped if the user doesn't need external DNS, or if it's considered the recommended path for self-managed Azure.

Good point, @Nirshal. For the downstream docs, I think the assumption is that users are working in production environments, so we want to suggest that external DNS is the recommended path.

@bryan-cox keep me honest if that's incorrect :)

[openshift-ci]

@lahinson: all tests passed!

Full PR test history. Your PR dashboard.

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

[jeana-redhat]

The branch/enterprise-5.0 label has been added to this PR.

This is because your PR targets the main branch and is labeled for branch/enterprise-4.22. And any PR going into main must also target the latest version branch (branch/enterprise-5.0).

If the update in your PR does NOT apply to version 5.0 onward, please re-target this PR to go directly into the appropriate enterprise- version branch or branches instead of main.