Skip to content

Commit 2d50dff

Browse files
lahinsonlahinson
authored
Merge pull request #83206 from krishnanshruthi/OSDOCS-12033
IBMZ updates for HCP 4.17
2 parents 99f7f81 + ed234c5 commit 2d50dff

10 files changed

+269
-77
lines changed

‎_topic_maps/_topic_map.yml

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2482,6 +2482,8 @@ Topics:
24822482
File: hcp-deploy-dc-virt
24832483
- Name: Deploying hosted control planes on bare metal in a disconnected environment
24842484
File: hcp-deploy-dc-bm
2485+
- Name: Deploying hosted control planes on IBM Z in a disconnected environment
2486+
File: disconnected-install-ibmz-hcp
24852487
- Name: Monitoring user workload in a disconnected environment
24862488
File: hcp-dc-monitor
24872489
- Name: Updating hosted control planes

‎hosted_control_planes/hcp-disconnected/disconnected-install-ibmz-hcp.adoc

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,37 @@
1+
:_mod-docs-content-type: ASSEMBLY
2+
[id="disconnected-install-ibmz-hcp"]
3+
include::_attributes/common-attributes.adoc[]
4+
= Deploying {hcp} on {ibm-z-title} in a disconnected environment
5+
:context: disconnected-install-ibmz-hcp
6+
7+
toc::[]
8+
9+
{hcp-capital} deployments in disconnected environments function differently than in a standalone {product-title}.
10+
11+
{hcp-capital} involves two distinct environments:
12+
13+
* Control plane: Located in the management cluster, where the {hcp} pods are run and managed by the Control Plane Operator.
14+
* Data plane: Located in the workers of the hosted cluster, where the workload and a few other pods run, managed by the Hosted Cluster Config Operator.
15+
16+
The `ImageContentSourcePolicy` (ICSP) custom resource for the data plane is managed through the `ImageContentSources` API in the hosted cluster manifest.
17+
18+
For the control plane, ICSP objects are managed in the management cluster. These objects are parsed by the HyperShift Operator and are shared as `registry-overrides` entries with the Control Plane Operator. These entries are injected into any one of the available deployments in the {hcp} namespace as an argument.
19+
20+
To work with disconnected registries in the {hcp}, you must first create the appropriate ICSP in the management cluster. Then, to deploy disconnected workloads in the data plane, you need to add the entries that you want into the `ImageContentSources` field in the hosted cluster manifest.
21+
22+
.Prerequisites to deploy {hcp} on {ibm-z-title} in a disconnected environment
23+
24+
* You set up the mirror registry. For more information, see "Creating a mirror registry with mirror registry for Red Hat OpenShift".
25+
* You mirrored an image for a disconnected installation. For more information, see "Mirroring images for a disconnected installation using the oc-mirror plugin".
26+
27+
include::modules/hcp-ibmz-adding-credentials-registry.adoc[leveloffset=+1]
28+
29+
include::modules/hcp-ibmz-update-reg-ca.adoc[leveloffset=+1]
30+
31+
include::modules/hcp-ibmz-adding-reg-ca-hostedcluster.adoc[leveloffset=+1]
32+
33+
[role="_additional-resources"]
34+
.Additional resources
35+
* xref:../../disconnected/mirroring/installing-mirroring-creating-registry.adoc#mirror-registry-introduction_installing-mirroring-creating-registry[Creating a mirror registry with mirror registry for Red Hat OpenShift]
36+
37+
* xref:../../disconnected/mirroring/installing-mirroring-disconnected.adoc#installing-mirroring-disconnected[Mirroring images for a disconnected installation using the oc-mirror plugin]

‎modules/destroy-hc-ibmz-cli.adoc

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -17,6 +17,10 @@ To destroy a hosted cluster and its managed cluster on `x86` bare metal with {ib
1717
$ oc -n <hosted_cluster_namespace> scale nodepool <nodepool_name> --replicas 0
1818
----
1919
+
20+
After the `NodePool` object is scaled to `0`, the compute nodes are detached from the hosted cluster. In {product-title} version 4.17, this function is applicable only for {ibm-z-title} with KVM. For z/VM and LPAR, you must delete the compute nodes manually.
21+
+
22+
If you want to re-attach compute nodes to the cluster, you can scale up the `NodePool` object with the number of compute nodes that you want. For z/VM and LPAR to reuse the agents, you must re-create them by using the `Discovery` image.
23+
+
2024
[IMPORTANT]
2125
====
2226
If the compute nodes are not detached from the hosted cluster or are stuck in the `Notready` state, delete the compute nodes manually by running the following command:

‎modules/hcp-bm-autoscale.adoc

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -99,3 +99,10 @@ $ oc --kubeconfig ./hostedcluster-secrets -n <namespace> delete deployment <depl
9999
----
100100
$ oc --kubeconfig ./hostedcluster-secrets get nodes
101101
----
102+
103+
[NOTE]
104+
====
105+
For {ibm-z-title} agents, compute nodes are detached from the cluster only for {ibm-z-title} with KVM agents. For z/VM and LPAR, you must delete the compute nodes manually.
106+
107+
Agents can be reused only for {ibm-z-title} with KVM. For z/VM and LPAR, re-create the agents to use them as compute nodes.
108+
====

‎modules/hcp-ibmz-adding-credentials-registry.adoc

Lines changed: 65 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,65 @@
1+
:_mod-docs-content-type: CONCEPT
2+
[id="hcp-ibmz-adding-credentials-registry_{context}"]
3+
= Adding credentials and the registry certificate authority to the management cluster
4+
5+
To pull the mirror registry images from the management cluster, you must first add credentials and the certificate authority of the mirror registry to the management cluster. Use the following procedure:
6+
7+
.Procedure
8+
9+
. Create a `ConfigMap` with the certificate of the mirror registry by running the following command:
10+
11+
+
12+
[source,terminal]
13+
----
14+
$ oc apply -f registry-config.yaml
15+
----
16+
+
17+
.Example registry-config.yaml file
18+
[source,yaml]
19+
----
20+
apiVersion: v1
21+
kind: ConfigMap
22+
metadata:
23+
name: registry-config
24+
namespace: openshift-config
25+
data:
26+
<mirror_registry>: |
27+
-----BEGIN CERTIFICATE-----
28+
-----END CERTIFICATE-----
29+
----
30+
. Patch the `image.config.openshift.io` cluster-wide object to include the following entries:
31+
32+
+
33+
[source,yaml]
34+
----
35+
spec:
36+
additionalTrustedCA:
37+
- name: registry-config
38+
----
39+
. Update the management cluster pull secret to add the credentials of the mirror registry.
40+
.. Fetch the pull secret from the cluster in a JSON format by running the following command:
41+
+
42+
[source,terminal]
43+
----
44+
$ oc get secret/pull-secret -n openshift-config -o json | jq -r '.data.".dockerconfigjson"' | base64 -d > authfile
45+
----
46+
.. Edit the fetched secret JSON file to include a section with the credentials of the certificate authority:
47+
+
48+
[source,terminal]
49+
----
50+
"auths": {
51+
"<mirror_registry>": { // <1>
52+
"auth": "<credentials>", // <2>
53+
"email": "you@example.com"
54+
}
55+
},
56+
----
57+
<1> Provide the name of the mirror registry.
58+
<2> Provide the credentials for the mirror registry to allow fetch of images.
59+
60+
.. Update the pull secret on the cluster by running the following command:
61+
+
62+
[source,terminal]
63+
----
64+
$ oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=authfile
65+
----

‎modules/hcp-ibmz-adding-reg-ca-hostedcluster.adoc

Lines changed: 48 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,48 @@
1+
:_mod-docs-content-type: CONCEPT
2+
[id="hcp-ibmz-adding-registry-ca-hostedcluster_{context}"]
3+
= Adding the registry certificate authority to the hosted cluster
4+
5+
When you are deploying {hcp} on {ibm-z-title} in a disconnected environment, include the `additional-trust-bundle` and `image-content-sources` resources. Those resources allow the hosted cluster to inject the certificate authority into the data plane workers so that the images are pulled from the registry.
6+
7+
. Create the `icsp.yaml` file with the `image-content-sources` information.
8+
+
9+
The `image-content-sources` information is available in the `ImageContentSourcePolicy` YAML file that is generated after you mirror the images by using `oc-mirror`.
10+
+
11+
.Example ImageContentSourcePolicy file
12+
[source,terminal]
13+
----
14+
# cat icsp.yaml
15+
- mirrors:
16+
- <mirror_registry>/openshift/release
17+
source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
18+
- mirrors:
19+
- <mirror_registry>/openshift/release-images
20+
source: quay.io/openshift-release-dev/ocp-release
21+
----
22+
23+
. Create a hosted cluster and provide the `additional-trust-bundle` certificate to update the compute nodes with the certificates as in the following example:
24+
+
25+
[source,terminal]
26+
----
27+
$ hcp create cluster agent \
28+
--name=<hosted_cluster_name> \ // <1>
29+
--pull-secret=<path_to_pull_secret> \ // <2>
30+
--agent-namespace=<hosted_control_plane_namespace> \ // <3>
31+
--base-domain=<basedomain> \ // <4>
32+
--api-server-address=api.<hosted_cluster_name>.<basedomain> \
33+
--etcd-storage-class=<etcd_storage_class> \ // <5>
34+
--ssh-key <path_to_ssh_public_key> \ // <6>
35+
--namespace <hosted_cluster_namespace> \ // <7>
36+
--control-plane-availability-policy SingleReplica \
37+
--release-image=quay.io/openshift-release-dev/ocp-release:<ocp_release_image> \ // <7>
38+
--additional-trust-bundle <path for cert> \ // <8>
39+
--image-content-sources icsp.yaml
40+
----
41+
<1> Replace `<hosted_cluster_name>` with the name of your hosted cluster.
42+
<2> Replace the path to your pull secret, for example, `/user/name/pullsecret`.
43+
<3> Replace `<hosted_control_plane_namespace>` with the name of the hosted control plane namespace, for example, `clusters-hosted`.
44+
<4> Replace the name with your base domain, for example, `example.com`.
45+
<5> Replace the etcd storage class name, for example, `lvm-storageclass`.
46+
<6> Replace the path to your SSH public key. The default file path is `~/.ssh/id_rsa.pub`.
47+
<7> Replace with the supported {product-title} version that you want to use, for example, `4.17.0-multi`.
48+
<8> Replace the path to Certificate Authority of mirror registry.

‎modules/hcp-ibmz-lpar-agents.adoc

Lines changed: 12 additions & 56 deletions
Original file line numberDiff line numberDiff line change
@@ -33,77 +33,33 @@ random.trust_cpu=on rd.luks.options=discard
3333
<3> For installations on DASD-type disks, use `rd.dasd` to specify the DASD where {op-system-first} is to be installed. For installations on FCP-type disks, use `rd.zfcp=<adapter>,<wwpn>,<lun>` to specify the FCP disk where {op-system} is to be installed.
3434
<4> Specify this parameter when you use an Open Systems Adapter (OSA) or HiperSockets.
3535

36-
. Generate the `.ins` and `initrd.img.addrsize` files.
36+
. Download the `.ins` and `initrd.img.addrsize` files from the `InfraEnv` resource.
3737
+
38-
The `.ins` file includes installation data and is on the FTP server. You can access the file from the HMC system. The `.ins` file contains details such as mapping of the location of installation data on the disk or FTP server, the memory locations where the data is to be copied.
38+
By default, the URL for the `.ins` and `initrd.img.addrsize` files is not available in the `InfraEnv` resource. You must edit the URL to fetch those artifacts.
3939
+
40-
[NOTE]
41-
====
42-
In {product-title} 4.16, the `.ins` file and `initrd.img.addrsize` are not automatically generated as part of boot-artifacts from the installation program. You must manually generate these files.
43-
====
44-
45-
.. Run the following commands to get the size of the `kernel` and `initrd`:
46-
+
47-
[source,yaml]
48-
----
49-
KERNEL_IMG_PATH='./kernel.img'
50-
INITRD_IMG_PATH='./initrd.img'
51-
CMDLINE_PATH='./generic.prm'
52-
kernel_size=$(stat -c%s $KERNEL_IMG_PATH )
53-
initrd_size=$(stat -c%s $INITRD_IMG_PATH)
54-
----
55-
56-
.. Round the `kernel` size up to the next MiB boundary. This value is the starting address of `initrd.img`.
57-
+
58-
[source,terminal]
59-
----
60-
offset=$(( (kernel_size + 1048575) / 1048576 * 1048576 ))
61-
----
62-
63-
.. Create the kernel binary patch file that contains the `initrd` address and size by running the following commands:
64-
+
65-
[source,terminal]
66-
----
67-
INITRD_IMG_NAME=$(echo $INITRD_IMG_PATH | rev | cut -d '/' -f 1 | rev)
68-
KERNEL_OFFSET=0x00000000
69-
KERNEL_CMDLINE_OFFSET=0x00010480
70-
INITRD_ADDR_SIZE_OFFSET=0x00010408
71-
OFFSET_HEX=$(printf '0x%08x\n' $offset)
72-
----
73-
74-
.. Convert the address and size to binary format by running the following command:
40+
.. Update the kernel URL endpoint to include `ins-file` by running the followign command:
7541
+
7642
[source,terminal]
7743
----
78-
$ printf "$(printf '%016x\n' $initrd_size)" | xxd -r -p > temp_size.bin
44+
$ curl -k -L -o generic.ins "< url for ins-file >"
7945
----
80-
81-
.. Merge the address and size binaries by running the following command:
8246
+
83-
[source,terminal]
47+
.Example URL
48+
[source,yaml]
8449
----
85-
$ cat temp_address.bin temp_size.bin > "$INITRD_IMG_NAME.addrsize"
50+
https://…/boot-artifacts/ins-file?arch=s390x&version=4.17.0
8651
----
87-
88-
.. Clean up temporary files by running the following command:
8952
+
90-
[source,terminal]
91-
----
92-
$ rm -rf temp_address.bin temp_size.bin
93-
----
94-
95-
.. Create the `.ins` file. The file is based on the paths of the `kernel.img`, `initrd.img`, `initrd.img.addrsize`, and `cmdline` files and the memory locations where the data is to be copied.
53+
.. Update the `initrd` URL endpoint to include `s390x-initrd-addrsize`:
9654
+
55+
.Example URL
9756
[source,yaml]
9857
----
99-
$KERNEL_IMG_PATH $KERNEL_OFFSET
100-
$INITRD_IMG_PATH $OFFSET_HEX
101-
$INITRD_IMG_NAME.addrsize $INITRD_ADDR_SIZE_OFFSET
102-
$CMDLINE_PATH $KERNEL_CMDLINE_OFFSET
58+
https://…./s390x-initrd-addrsize?api_key=<api-key>&arch=s390x&version=4.17.0
10359
----
10460

105-
. Transfer the `initrd`, `kernel`, `generic.ins`, and `initrd.img.addrsize` parameter files to the file server. For more information about how to transfer the files with FTP and boot, see _Installing in an LPAR_.
61+
. Transfer the `initrd`, `kernel`, `generic.ins`, and `initrd.img.addrsize` parameter files to the file server. For more information about how to transfer the files with FTP and boot, see "Installing in an LPAR".
10662

10763
. Start the machine.
10864

109-
. Repeat the procedure for all other machines in the cluster.
65+
. Repeat the procedure for all other machines in the cluster.

‎modules/hcp-ibmz-update-reg-ca.adoc

Lines changed: 63 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,63 @@
1+
:_mod-docs-content-type: CONCEPT
2+
[id="hcp-ibmz-update-registry-ca_{context}"]
3+
= Update the registry certificate authority in the AgentServiceConfig resource with the mirror registry
4+
5+
When you use a mirror registry for images, agents need to trust the registry's certificate to securely pull images. You can add the certificate authority of the mirror registry to the `AgentServiceConfig` custom resource by creating a `ConfigMap`.
6+
7+
.Prerequisites
8+
9+
* You must have installed {mce}.
10+
11+
.Procedure
12+
13+
. In the same namespace where you installed {mce-short}, create a `ConfigMap` resource with the mirror registry details. This `ConfigMap` resource ensures that you grant the hosted cluster workers the capability to retrieve images from the mirror registry.
14+
+
15+
.Example ConfigMap file
16+
[source,yaml]
17+
----
18+
apiVersion: v1
19+
kind: ConfigMap
20+
metadata:
21+
name: mirror-config
22+
namespace: multicluster-engine
23+
labels:
24+
app: assisted-service
25+
data:
26+
ca-bundle.crt: |
27+
-----BEGIN CERTIFICATE-----
28+
-----END CERTIFICATE-----
29+
registries.conf: |
30+
31+
[[registry]]
32+
location = "registry.stage.redhat.io"
33+
insecure = false
34+
blocked = false
35+
mirror-by-digest-only = true
36+
prefix = ""
37+
38+
[[registry.mirror]]
39+
location = "<mirror_registry>"
40+
insecure = false
41+
42+
[[registry]]
43+
location = "registry.redhat.io/multicluster-engine"
44+
insecure = false
45+
blocked = false
46+
mirror-by-digest-only = true
47+
prefix = ""
48+
49+
[[registry.mirror]]
50+
location = "<mirror_registry>/multicluster-engine" # <1>
51+
insecure = false
52+
----
53+
+
54+
<1> Where: `<mirror_registry>` is the name of the mirror registry.
55+
56+
. Patch the `AgentServiceConfig` resource to include the `ConfigMap` resource that you created. If the `AgentServiceConfig` resource is not present, create the `AgentServiceConfig` resource with the following content embedded into it:
57+
+
58+
[source,terminal]
59+
----
60+
spec:
61+
mirrorRegistryRef:
62+
name: mirror-config
63+
----

‎modules/hosted-control-planes-version-support.adoc

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -36,3 +36,5 @@ You can use the `hcp` CLI to create hosted clusters.
3636
You can use the `hypershift.openshift.io` API resources, such as, `HostedCluster` and `NodePool`, to create and manage {product-title} clusters at scale. A `HostedCluster` resource contains the control plane and common data plane configuration. When you create a `HostedCluster` resource, you have a fully functional control plane with no attached nodes. A `NodePool` resource is a scalable set of worker nodes that is attached to a `HostedCluster` resource.
3737

3838
The API version policy generally aligns with the policy for link:https://kubernetes.io/docs/reference/using-api/#api-versioning[Kubernetes API versioning].
39+
40+
Updates for {hcp} involve updating the hosted cluster and the node pools. For more information, see "Updates for hosted control planes".

0 commit comments

Comments
 (0)