Adds post install procedure to deploying red hat quay (quay#1452)

Co-authored-by: Steven Smith <[email protected]>

Author: stevsmit

deploy_red_hat_quay_operator/master.adoc

@@ -33,20 +33,24 @@ include::modules/deploying-quay-registry.adoc[leveloffset=+1]
 //registry deployment
 include::modules/registry-deploy-console.adoc[leveloffset=+2]
 //cli
-include::modules/operator-deploy-cli.adoc[leveloffset=+2]
+include::modules/registry-deploy-cli.adoc[leveloffset=+2]
 
-//post installation configuration
+//creating the first user
+include::modules/creating-first-user.adoc[leveloffset=+1]
+include::modules/first-user-ui.adoc[leveloffset=+2]
+include::modules/first-user-api.adoc[leveloffset=+2]
 
+//post installation configuration
+include::modules/enabling-features-after-deployment.adoc[leveloffset=+1]
+include::modules/operator-config-cli.adoc[leveloffset=+2]
+include::modules/operator-config-cli-download.adoc[leveloffset=+2]
 
-include::modules/first-user-api.adoc[leveloffset=+3]
-include::modules/operator-deploy-view-pods-cli.adoc[leveloffset=+3]
-include::modules/operator-deploy-hpa.adoc[leveloffset=+3]
+//Advanced configuration
 
 
-//preconfiguration
-include::modules/operator-preconfigure.adoc[leveloffset=+1]
-include::modules/config-preconfigure-automation.adoc[leveloffset=+2]
+include::modules/operator-deploy-hpa.adoc[leveloffset=+1]
 
+//Advanced configuration options
 
 //traffic ingress
 [id="configuring-traffic-ingress"]
@@ -84,22 +88,15 @@ include::modules/creating-project-node-selector-toleration.adoc[leveloffset=+2]
 include::modules/installing-quay-operator-namespace.adoc[leveloffset=+2]
 include::modules/creating-registry-infra-node.adoc[leveloffset=+2]
 
-[role="_additional-resources"]
-.Additional resources
-For more information on pre-configuring your {productname} deployment, see the section xref:config-preconfigure-automation[Pre-configuring {productname} for automation]
 
 include::modules/operator-monitor-deploy-cli.adoc[leveloffset=+1]
 //ui
 include::modules/operator-deploy-ui.adoc[leveloffset=+2]
-include::modules/operator-first-user-ui.adoc[leveloffset=+3]
 
 //quayregistry status
 include::modules/operator-quayregistry-status.adoc[leveloffset=+1]
 
-//configuring
-include::modules/operator-config-cli.adoc[leveloffset=+1]
-include::modules/operator-config-cli-access.adoc[leveloffset=+2]
-include::modules/operator-config-cli-download.adoc[leveloffset=+2]
+
 
 //SSL/TLS
 include::modules/operator-custom-ssl-certs-config-bundle.adoc[leveloffset=+1]

modules/config-updates-36.adoc

@@ -13,9 +13,9 @@ The following configuration fields have been introduced with {productname} 3.6:
 |Parameter |Description
 |**FEATURE_EXTENDED_REPOSITORY_NAMES** |Support for nested repositories and extended repository names has been added. This change allows the use of `/` in repository names needed for certain {ocp} use cases. For more information, see xref:config-fields-nested-repositories[Configuring nested repositories].
 
-|**FEATURE_USER_INITIALIZE** |If set to true, the first `User` account can be created by the API `/api/v1/user/initialize`. For more information, see xref:config-preconfigure-automation[Pre-configuring {productname} for automation].
+|**FEATURE_USER_INITIALIZE** |If set to true, the first `User` account can be created by the API `/api/v1/user/initialize`.
 
-| **ALLOWED_OCI_ARTIFACT_TYPES** |Helm, cosign, and ztsd compression scheme artifacts are built into {productname} 3.6 by default. For any other Open Container Initiative (OCI) artifact types that are not supported by default, you can add them to the `ALLOWED_OCI_ARTIFACT_TYPES` configuration in Quay's `config.yaml` For more information, see xref:other-oci-artifacts-with-quay[Adding other OCI media types to Quay].
+| **ALLOWED_OCI_ARTIFACT_TYPES** |Helm, cosign, and ztsd compression scheme artifacts are built into {productname} 3.6 by default. For any other Open Container Initiative (OCI) artifact types that are not supported by default, you can add them to the `ALLOWED_OCI_ARTIFACT_TYPES` configuration in Quay's `config.yaml`.
 
 | **CREATE_PRIVATE_REPO_ON_PUSH** |Registry users now have the option to set `CREATE_PRIVATE_REPO_ON_PUSH` in their `config.yaml` to `True` or `False` depending on their security needs.
 

modules/creating-first-user.adoc

@@ -0,0 +1,5 @@
+:_mod-docs-content-type: CONCEPT
+[id="creating-first-user"]
+= Creating the first user
+
+This section guides you through creating the initial administrative user for your {productname} registry. Completing this step confirms that your deployment is fully operational and grants you the necessary credentials to begin using and managing your registry. This can be completed by using the {productname} UI or by leveraging the API.

modules/enabling-features-after-deployment.adoc

@@ -0,0 +1,5 @@
+:_mod-docs-content-type: REFERENCE
+[id="enabling-features-after-deployment"]
+= Enabling features after deployment
+
+After deployment, you can customize to the {productname} registry to enable new features and better suit the needs of your organization. This entails editing the {productname} configuration bundle secret (`spec.configBundleSecret`) resource. You can use the {ocp} web console or the command-line interface to enable features after deployment. Using the {ocp} web console is generally considered a simpler method.

modules/first-user-api.adoc

@@ -2,76 +2,62 @@
 [id="using-the-api-to-create-first-user"]
 = Using the API to create the first user
 
-Use the following procedure to create the first user in your {productname} organization.
+You can use the API to create the first user with administrative privileges for your registry. 
 
 .Prerequisites
 
-* The config option `FEATURE_USER_INITIALIZE` must be set to `True`.
-* No users can already exist in the database.
-
-.Procedure
-
-[NOTE]
-====
-This procedure requests an OAuth token by specifying `"access_token": true`.
-====
-
-. Open your {productname} configuration file and update the following configuration fields:
+* You have set `FEATURE_USER_INITIALIZE: true` and established a superuser in your `config.yaml` file. For example:
 +
 [source,yaml]
 ----
+# ...
 FEATURE_USER_INITIALIZE: true
 SUPER_USERS:
-     -  quayadmin
+     -  <username>
+# ..
 ----
-
-. Stop the {productname} service by entering the following command:
 +
-[source,terminal]
-----
-$ sudo podman stop quay
-----
+If you did not configure these settings upon registry creation, and need to re-configure your registry to enable these settings, see. . .
 
-. Start the {productname} service by entering the following command:
-+
-[source,terminal]
-----
-$ sudo podman run -d -p 80:8080 -p 443:8443 --name=quay -v $QUAY/config:/conf/stack:Z  -v $QUAY/storage:/datastorage:Z {productrepo}/{quayimage}:{productminv}
-----
+* You have not created a user by using the {productname} UI.
 
-. Run the following `CURL` command to generate a new user with a username, password, email, and access token:
+.Procedure
+
+. On the command-line interface, generate a new user with a username, password, email, and access token by entering the following `CURL` command:
 +
 [source,terminal]
 ----
-$ curl -X POST -k  http://quay-server.example.com/api/v1/user/initialize --header 'Content-Type: application/json' --data '{ "username": "quayadmin", "password":"quaypass12345", "email": "quayadmin@example.com", "access_token": true}'
+$ curl -X POST -k  http:/</quay-server.example.com>/api/v1/user/initialize --header 'Content-Type: application/json' --data '{ "username": "<username>", "password":"<password>", "email": "<email>@example.com", "access_token": true}'
 ----
 +
 If successful, the command returns an object with the username, email, and encrypted password. For example:
 +
 [source,yaml]
 ----
-{"access_token":"6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED", "email":"[email protected]","encrypted_password":"1nZMLH57RIE5UGdL/yYpDOHLqiNCgimb6W9kfF8MjZ1xrfDpRyRs9NUnUuNuAitW","username":"quayadmin"} # gitleaks:allow
+{"access_token":"6B4QTRSTSD1HMIG915VPX7BMEZBVB9GPNY2FC2ED", "email":"[email protected]","encrypted_password":"<password>","username":"quayadmin"} # gitleaks:allow
 ----
 +
-If a user already exists in the database, an error is returned:
+If a user already exists in the database, an error is returned. For example::
 +
 [source,terminal]
 ----
 {"message":"Cannot initialize user in a non-empty database"}
 ----
 +
-If your password is not at least eight characters or contains whitespace, an error is returned:
+If your password is not at least eight characters or contains whitespace, an error is returned. For example:
 +
 [source,terminal]
 ----
 {"message":"Failed to initialize user: Invalid password, password must be at least 8 characters and contain no whitespace."}
 ----
 
-. Log in to your {productname} deployment by entering the following command:
+. You can log in to your registry by navigating to the UI or by leveraging Podman on the CLI.
+
+.. Log in to the registry by running the following `podman` command:
 +
 [source,terminal]
 ----
-$ sudo podman login -u quayadmin -p quaypass12345 http://quay-server.example.com --tls-verify=false
+$ podman login -u <username> -p <password> http://<quay-server.example.com>
 ----
 +
 .Example output

modules/first-user-ui.adoc

@@ -0,0 +1,21 @@
+:_mod-docs-content-type: PROCEDURE
+[id="first-user-ui"]
+= Creating the first user by using the UI
+
+Creating the first user by using the UI offers a visual workflow and is often preferred after initial setup to ensure that the user interface is functional. For most users, the UI offers a simpler path to creating the first user, as it does not require additional configuration in the `config.yaml` file.
+
+.Prerequisites
+
+* You have deployed the {productname} registry.
+
+.Procedure
+
+. On the {ocp} web console, click *Operators* -> *Installed Operators* -> *{productname}*.
+
+. On the *{productname}* Operators page, click *Quay Registry*, and then the name of your registry.
+
+. On the *QuayRegistry details* page, click the *Registry Endpoint* link, for example, *example-registry-quay.username-cluster-new.gcp.quaydev.org*. You are navigated to the registry's main page. 
+
+. Click *Create Account*.
+
+. Enter the details for *Username*, *Password*, *Email*, and then click *Create Account*. After creating the first user, you are automatically logged in to the {productname} registry.

modules/operator-config-cli-access.adoc

@@ -26,7 +26,7 @@ $ oc describe quayregistry -n <quay_namespace>
 [source,terminal]
 ----
 # ...
-  Config Bundle Secret:  example-registry-config-bundle-v123x
+  Config Bundle Secret: example-registry-config-bundle-v123x
 # ...
 ----
 
@@ -100,7 +100,6 @@ $ oc patch quayregistry <registry_name> -n <namespace> --type=merge -p '{"spec":
 quayregistry.quay.redhat.com/example-registry patched
 ----
 
-
 .Verification
 
 . Verify that the `QuayRegistry` CR has been updated with the new `configBundleSecret`:

modules/operator-config-cli-download.adoc

@@ -1,26 +1,23 @@
 :_mod-docs-content-type: PROCEDURE
 [id="operator-config-cli"]
-= Customizing {productname} on {ocp}
+= Enabling features by using the {ocp} web console
 
-After deployment, you can customize the {productname} application by editing the {productname} configuration bundle secret `spec.configBundleSecret`. You can also change the managed status of components and configure resource requests for some components in the `spec.components` object of the `QuayRegistry` resource.
+To enable features in the {ocp} web console, you can edit the `configBundleSecret` resource.
 
-[id="editing-config-bundle-secret-in-ocp-console"]
-== Editing the config bundle secret in the {ocp} console
+.Prerequisites
 
-Use the following procedure to edit the config bundle secret in the {ocp} console.
+* You have have administrative privileges to the cluster.
 
 .Procedure
 
-. On the {productname} Registry overview screen, click the link for the *Config Bundle Secret*.
-+
-image:operator-quay-registry-overview.png[{productname} Registry overview]
+. On the {ocp} web console, click *Operators* -> *Installed Operators* -> *Red Hat Quay*.
 
-. To edit the secret, click **Actions** -> **Edit Secret**.
-+
-image:operator-config-bundle-edit-secret.png[Edit secret]
+. Click *Quay Registry* and then the name of your registry.
 
-. Modify the configuration and save the changes.
-+
-image:operator-save-config-changes.png[Save changes]
+. Under *Config Bundle Secret*, click the name of your secret, for example, `quay-config-bundle`.
 
-. Monitor the deployment to ensure successful completion and that the configuration changes have taken effect.
+. On the *Secret details* page, click *Actions* -> *Edit secret*.
+
+. In the *Value* text box, add the new configuration fields for the features that you want to enable. For a list of all configuration fields, see link:https://docs.redhat.com/en/documentation/red_hat_quay/3/html/configure_red_hat_quay/index[Configure {productname}].
+
+. Click *Save*. The {productname} Operator automatically reconciles the changes by restarting all Quay-related pods. After all pods are restart, the features are enabled.