diff --git a/deploy_quay_on_openshift_op_tng/master.adoc b/deploy_quay_on_openshift_op_tng/master.adoc index c2273bc12..60b110534 100644 --- a/deploy_quay_on_openshift_op_tng/master.adoc +++ b/deploy_quay_on_openshift_op_tng/master.adoc @@ -5,11 +5,11 @@ include::modules/attributes.adoc[] {productname} is an enterprise-quality container registry. Use {productname} to build and store container images, then make them available to deploy across your enterprise. -The Quay Operator provides a simple method to deploy and manage a {productname} cluster. This is the preferred procedure for deploying {productname} on OpenShift and is covered in this guide. +The {productname} Operator provides a simple method to deploy and manage a {productname} cluster. This is the preferred procedure for deploying {productname} on OpenShift and is covered in this guide. -Note that this version of the Quay Operator has been completely rewritten and differs substantially from earlier versions. Please review this documentation carefully. +Note that this version of the {productname} Operator has been completely rewritten and differs substantially from earlier versions. Please review this documentation carefully. ifeval::["{productname}" == "Project Quay"] -If you are looking for documentation for prior versions of the Quay Operator, please xref:deploy_quay_on_openshift_op.adoc[check here.] +If you are looking for documentation for prior versions of the {productname} Operator, please xref:deploy_quay_on_openshift_op.adoc[check here.] endif::[] include::modules/con_quay_openshift_prereq.adoc[leveloffset=+1] diff --git a/modules/con_quay_openshift_prereq.adoc b/modules/con_quay_openshift_prereq.adoc index ad6cc26f3..a0d714974 100644 --- a/modules/con_quay_openshift_prereq.adoc +++ b/modules/con_quay_openshift_prereq.adoc @@ -6,6 +6,12 @@ Here are a few things you need to know before you begin the {productname} Operat * *OpenShift cluster*: You need a privileged account to an OpenShift 4.5 or later cluster on which to deploy the {productname} Operator. That account must have the ability to create namespaces at the cluster scope. +* *Resource Requirements*: Each {productname} application pod has the following resource requirements: +** 8Gi of memory +** 2 milicores of CPU. + +The {productname} Operator will create at least one application pod per {productname} deployment it manages. Ensure your OpenShift cluster has sufficient compute resources for these requirements. + * *Object Storage*: By default, the {productname} Operator uses the `ObjectBucketClaim` Kubernetes API to provision object storage. Consuming this API decouples the Operator from any vendor-specific implementation. OpenShift Container Storage provides this API via its NooBaa component, which will be used in this example. Otherwise, {productname} can be manually configured to use any of the following supported cloud storage options: ** Amazon S3 (see link:https://access.redhat.com/solutions/3680151[S3 IAM Bucket Policy] for details on configuring an S3 bucket policy for {productname}) diff --git a/modules/proc_deploy-quay-openshift-operator-tng.adoc b/modules/proc_deploy-quay-openshift-operator-tng.adoc index 16b7268ec..e6db40b4a 100644 --- a/modules/proc_deploy-quay-openshift-operator-tng.adoc +++ b/modules/proc_deploy-quay-openshift-operator-tng.adoc @@ -269,26 +269,6 @@ When the Quay Operator starts up, it immediately looks for any `QuayRegistries` Upgrades are supported from previous versions of the Operator which used the `QuayEcosystem` API for a limited set of configurations. To ensure that migrations do not happen unexpectedly, a special label needs to be applied to the `QuayEcosystem` for it to be migrated. A new `QuayRegistry` will be created for the Operator to manage, but the old `QuayEcosystem` will remain until manually deleted to ensure that you can roll back and still access Quay in case anything goes wrong. To migrate an existing `QuayEcosystem` to a new `QuayRegistry`, follow these steps: -==== Preparing Managed Database for Migration - -If using an external database not deployed by the Quay Operator, skip this step. Otherwise, ensure that the password is set for the `postgres` root admin user (not set by default). This allows remote access to the database for migration. The Operator looks for this password in the `Secret` referenced by `spec.quay.database.credentialsSecretKey` under the `database-root-password` key. - -To set/change the password, use either the OpenShift console or `kubectl` to [open an SSH terminal connection](https://kubernetes.io/docs/tasks/debug-application-cluster/get-shell-running-container/) to the Postgres pod: -```sh -$ kubectl exec -n --stdin --tty deployment/-quay-postgresql -- /bin/bash -``` - -Execute the following command and follow instructions to change the password: -```sh -$ psql -psql (10.12) -Type "help" for help. - -postgres=# \password -``` - -==== Performing QuayEcosystem Upgrade - . Add `"quay-operator/migrate": "true"` to the `metadata.labels` of the `QuayEcosystem`. . Wait for a `QuayRegistry` to be created with the same `metadata.name` as your `QuayEcosystem`. The `QuayEcosystem` will be marked with the label `"quay-operator/migration-complete": "true"`. @@ -319,7 +299,7 @@ The Quay Operator will report errors in its logs and in `status.conditions` if m *Database* -Ephemeral database not supported (`volumeSize` field must be set). The `postgres` user must have a password set and referenced in `credentialsSecretName` (instructions above). +Ephemeral database not supported (`volumeSize` field must be set). *Redis*