Skip to content
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.

Sign up for GitHub

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

Add high level documentation for disconnected envs #1253

Merged
merged 1 commit into from
Jan 13, 2025
+52 −0
Merged

Add high level documentation for disconnected envs #1253

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
50 changes: 50 additions & 0 deletions docs/assemblies/proc_deploying-in-disconnected-environments.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
[id="proc_deploying-in-disconnected-environments"]
= Deploying OpenStack in a disconnected environment

[role="_abstract"]
== Process
Deploying in disconnected environments can be achieved largely by following the OpenShift documentation for mirroring OLM Operators: https://docs.openshift.com/container-platform/4.16/installing/disconnected_install/installing-mirroring-installation-images.html#olm-mirror-catalog_installing-mirroring-installation-images
knoha-rh marked this conversation as resolved.
Show resolved Hide resolved

== Technical Implementation
The details provided in this section are for informational purposes only. Users should not need to interact with anything additional after completing the above mentioned OLM mirroring process.

The `openstack-operator` contains a list of related images that will ensure all required images for the deployment are mirrored following the above OpenShift process. Once images are mirrored, the `ImageContentSourcePolicy` custom resource (CR) is created. This process results in a `MachineConfig` called `99-master-genereted-registries` being updated in the cluster. The `99-master-generated-registries` `MachineConfig` contains a `registries.conf` file that is applied to all of the OpenShift nodes in the cluster.

In order for dataplane nodes to integrate cleanly with this process, openstack-operator checks for the existence of an `ImageContentSourcePolicy`. If one is found, it will read the `registries.conf` file from the `99-master-generated-registries` `MachineConfig`. The openstack-operator will then set two variables in the Ansible inventory for the nodes.

[,yaml]
----
edpm_podman_disconnected_ocp
Copy link
Contributor

Choose a reason for hiding this comment

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

Would not mentioning these ansible variables that are for internal use confuse the users? Though the section heading is Technical Overview i.e how it internally works, we should probably clearly mention that user does not have to do anything from OSP pov once OCP operataor catalog mirroring is done, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, true, don't wan to cause any confusion. I can make that more clear.

edpm_podman_registries_conf
----

`edpm_podman_disconnected_ocp` is a boolean variable that is used to conditionally render `registries.conf` on the dataplane nodes during the deployment. While `edpm_podman_registries_conf` contains the contents of the `registries.conf` that were acquired from the `MachineConfig` in the cluster. The contents of this file will be written to `/etc/containers/registries.conf` on each of the dataplane nodes. This ensures that our dataplane nodes are configured in a consistent manner with the OpenShift nodes.

Since this configuration file is lifted directly from OpenShift, the dataplane nodes also have the same requirements as OpenShift for images - such as using image digests rather than image tags.
This can be seen in the Ansible inventory secret for each of the `OpenStackDataPlaneNodeSet` objects in the cluster. Using `multipathd` as an example:

[,yaml]
----
edpm_podman_registries_conf: |
[...]
[[registry]]
prefix = ""
location = "registry.redhat.io/rhoso/openstack-multipathd-rhel9"

[[registry.mirror]]
location = "quay-mirror-registry.example.net:8443/olm/rhoso-openstack-multipathd-rhel9"
pull-from-mirror = "digest-only"
[...]
----

Note that the `pull-from-mirror` parameter is set to `digest-only`. This means that any attempt by podman to pull an image by a digest will result in the image being pulled from the specified mirror.

Accordingly, image references in the `OpenStackVersion` CR are provided in the digest format, for example the multipathd image:

[,bash]
----
$ oc get openstackversion -o jsonpath='{.items[].status.containerImages.edpmMultipathdImage}'
"registry.redhat.io/rhoso/openstack-multipathd-rhel9@sha256:7df2e1ebe4ec6815173e49157848a63d28a64ffb0db8de6562c4633c0fbcdf3f"
----

Since all images are in the digest format for the `OpenStackVersion` resource, there is no additional action required by users to work in a disconnected environment.
2 changes: 2 additions & 0 deletions docs/dataplane.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -29,4 +29,6 @@ include::assemblies/design.adoc[leveloffset=+1]

include::assemblies/creating-the-data-plane.adoc[leveloffset=+1]

include::assemblies/proc_deploying-in-disconnected-environments.adoc[leveloffset=+1]

include::assemblies/dataplane_resources.adoc[leveloffset=-1]
Loading