Bug 1798354 - [Doc RFE] Document deployment in a disconnected environment
Summary: [Doc RFE] Document deployment in a disconnected environment
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenShift Container Storage
Classification: Red Hat Storage
Component: documentation
Version: 4.3
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: OCS 4.5.0
Assignee: Kusuma
QA Contact: Daniel Horák
URL:
Whiteboard:
Depends On:
Blocks: 1826399
TreeView+ depends on / blocked
 
Reported: 2020-02-05 06:47 UTC by Anjana Suparna Sriram
Modified: 2020-09-20 15:21 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-09-20 15:21:37 UTC
Embargoed:


Attachments (Terms of Use)

Description Anjana Suparna Sriram 2020-02-05 06:47:46 UTC
User Story: As an OpenShift administrator using OCP 4.3 in a disconnected environment, I want my attached storage solution (OCS 4.3) to be available in this environment as well.

Content Plan: https://docs.google.com/document/d/1BOPHnBmZf7ApzSF6VoXsImaFVIwEuLgHvFEGEzfeSGg/edit?usp=sharing

Comment 5 Elad 2020-04-24 17:29:54 UTC
This is not planned for 4.4. We should re-target

Comment 6 Anjana Suparna Sriram 2020-04-27 12:26:31 UTC
(In reply to Elad from comment #5)
> This is not planned for 4.4. We should re-target

Updated the bug and updated the flags

Comment 12 Daniel Horák 2020-08-07 09:15:01 UTC
What is the state of this bug? It is in ON_QA state, but there are some
suggestions in the previous comment and also I see following issues in the
existing preview doc:

* General issue, what I see is - that the chapter 3. Deploying OpenShift
  Container Storage in disconnected environments in document Deploying
  OpenShift Container Storage[1] is basically duplicating OCP documentation[2],
  is this expected?

* The chapter is mentioning "air gap disconnected" environment (which what I
  understand is the case, where there is no access to the internet neither from
  the mirror registry - so the content have to be carried for example on
  removable media), but all the commands in the doc for mirroring the images
  requires direct access to the internet from the mirror registry.

* Some commands have wrong alignment and line breaks on wrong places. If one
  (long) shell command have to be split to multiple lines, each line (except
  the last one) have to be ended by backslash ('\'), but this have to be at the
  end of the line.

  So for example following command is wrong, because it is in fact on one line,
  visually on two lines, but the separating backslash is in the middle of line:

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    # oc adm catalog mirror ${MIRROR_REGISTRY_DNS}/olm/redhat-operators:v1
    ${MIRROR_REGISTRY_DNS}  \ --registry-config=${AUTH_FILE} --insecure
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    Correctly this command should be written for example like this:

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    # oc adm catalog mirror ${MIRROR_REGISTRY_DNS}/olm/redhat-operators:v1 \
      ${MIRROR_REGISTRY_DNS} --registry-config=${AUTH_FILE} --insecure
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  Similarly the `oc adm catalog build...` command is in fact written correctly,
  but as it is very long command, it is visually split to more lines than it
  actually is separated to, so I would suggest to write it like this:

    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    # oc adm catalog build --appregistry-org redhat-operators \
      --from=registry.redhat.io/openshift4/ose-operator-registry:v4.4 \
      --to=${MIRROR_REGISTRY_DNS}/olm/redhat-operators:v1 \
      --registry-config=${AUTH_FILE} \
      --filter-by-os="linux/amd64" --insecure
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Basically the same apply also to the chapter 10.3. Updating OpenShift Container
Storage in disconnected environments.

[1] https://access.redhat.com/documentation/en-us/red_hat_openshift_container_storage/4.5/html-single/deploying_openshift_container_storage/index?lb_target=preview#deploying-openshift-container-storage-in-disconnected-environments_aws-vmware
[2] https://docs.openshift.com/container-platform/4.5/operators/olm-restricted-networks.html

Because of all the issues and uncertainty mentioned above, moving back to ASSIGNED.

Comment 13 Neha Berry 2020-08-10 08:00:57 UTC
I had a question @Kusuma,

In the current preview link, the last step n Chapter 3 is:

>> 4. Install OpenShift Container Storage Operator from the Operator Hub.

>> You can see all the operators in the Operator Hub of the OpenShift Container Platform console UI. See Installing OpenShift Container Storage using the Operator Hub for instructions.

But this is installation of OCS operator from Operator Hub . Don't we then need to link "Installing Storagecluster" and "verifying the installation" sections as well ?

I tried searching for these information in the preview link Chapter 3 but sorry could not find anything. let me know if I missed anything

Comment 23 Daniel Horák 2020-08-13 14:26:35 UTC
The first doc *Preparing to deploy in a disconnected environment* looks good.

Tor the second doc: *Managing OpenShift Container Storage* - *10.3. Preparing
to update in a disconnected environment* I have few notes and suggestions.
I'm comparing it with the official OCP doc[1] and most of the notes will refer
to that.


# In the second paragraph of the preface, it might be worth to point the link
  *Using Operator Lifecycle Manager on restricted networks* directly to the
  *14.4. Updating an Operator catalog image* section of the doc[1] (not only
  generally to the whole doc).

# 10.3.2. Building and mirroring the Red Hat operator catalog:
  The note for the fist step is (I think) not correct.
> Make sure to change the ose-operator-registry tag to latest version (for
> example, v4.4 → v4.5). 
  Based on what I understand and what is written in the OCP doc, the tag should
  always:
> match the target OpenShift Container Platform cluster major and minor version.
  So it depends, if the version of OCP changed or not (it might be desired to
  update OCS to next minor version while OCP didn't changed in the meantime).
  Update of OCP itself is not part of our guide, it is covered somewhere else.
  Did I understand it correctly?

# 10.3.2. Building and mirroring the Red Hat operator catalog, 1st step Build
# the catalog for redhat-operators:
  The tag in the `--to=${MIRROR_REGISTRY_DNS}/olm/redhat-operators:v1`
  parameter of the `oc adm catalog build ...` command should be changed to
  higher version (e.g. `v2` - as it is stated in the OCP doc:
> Name your catalog image and include a tag, for example, v2 because it is the
> updated catalog.
  And the same tag have to be used also in the following commands, where is the
  `${MIRROR_REGISTRY_DNS}/olm/redhat-operators:XY` image referred.

# 10.3.2. Building and mirroring the Red Hat operator catalog:
  The 3rd step is not necessary during upgrade, the default operator sources
  are already disabled from installation. So it can be removed completely.
> Disable the default OperatorSources by adding disableAllDefaultSources: true
> to the spec file for the Operator Hub.
> $ oc patch OperatorHub cluster --type json -p '[{"op": "add", "path":
> "/spec/disableAllDefaultSources", "value": true}]' 

# 10.3.3. Creating Operator imageContentSourcePolicy
  This section might not be required, based on following note from the OCP doc,
  but as it shouldn't break anything if the steps are done, I'll preserve it
  here for now, instead of explaining how to check, if the application of the
  imageContentSourcePolicy.yaml is required or not.
> Important
> It is possible that you do not need to apply the
> imageContentSourcePolicy.yaml manifest. Complete a diff of the files to
> determine if changes are necessary. 

# 10.3.4. Updating redhat-operator CatalogSource
  We are suggesting to use the same tag for the updated redhat-operators image
  (v1) and delete the related pod, to spin it up with the updated version, but
  the official OCP doc[1] suggest different approach: use different version tag
  for the updated redhat-operators image (as mentioned above) and then edit
  (update) the CatalogSource object with the new image tag.
  The second approach suggested by OCP doc seems slightly better and more clear
  to me.

[1] https://access.redhat.com/documentation/en-us/openshift_container_platform/4.5/html/operators/olm-restricted-networks#olm-updating-operator-catalog-image_olm-restricted-networks

Comment 36 Daniel Horák 2020-08-26 13:21:57 UTC
Just for the record, I find only following typo:

Document: Managing OpenShift Container Storage
Section:  10.2.2. Building and mirroring the Red Hat operator catalog
Step: 2. Mirror the catalog for redhat-operators.

The command oc adm catalog mirror ...  have to refer the same version tag (v2)
for redhat-operators as used in the previous command `oc adm catalog build ...`,
so it should looks like this:
  $ oc adm catalog mirror ${MIRROR_REGISTRY_DNS}/olm/redhat-operators:v2 \
    ${MIRROR_REGISTRY_DNS} --registry-config=${AUTH_FILE} --insecure

Comment 40 Daniel Horák 2020-08-27 07:41:14 UTC
I didn't find any significant issue in the two documents[1,2] covered by this
bug. I still see big space for improvement for the future releases, mainly
related to the question raised in comment 12 about duplicating OCP doc and all
the related issues.

[1] https://access.redhat.com/documentation/en-us/red_hat_openshift_container_storage/4.5/html-single/preparing_to_deploy_in_a_disconnected_environment/index?lb_target=preview
[2] https://access.redhat.com/documentation/en-us/red_hat_openshift_container_storage/4.5/html-single/managing_openshift_container_storage/index?lb_target=preview#preparing_to_update_in_a_disconnected_environment

Also based on comments #38 and #39 I'm verifying this bug.


Note You need to log in before you can comment on or make changes to this bug.