Merge pull request #12 from RedHatGov/develop

Release 0.0.3

.travis.yml

@@ -24,7 +24,7 @@ script:
 - KUSTOMIZE_PATH=${KUSTOMIZE} TEST_OPERATOR_NAMESPACE=default molecule test -s kind-namespace
 deploy:
 - provider: script
-  script: hack/operate.sh --push-images --bundle --extra-tag=develop --verbose --formatter
+  script: hack/operate.sh --push-images --bundle --develop --verbose --formatter
   on:
     branch: develop
 - provider: script

README.adoc

@@ -18,7 +18,7 @@ Before running the script make sure to update the location of the container imag
 
 === Operator Installation Steps
 
-The installation of the Custom Resource Definition and Cluster Role requires *cluster-admin* privileges. After that regular users with `admin` privileges on their projects (which is automatically granted to the user who creates a project) can provision the Gitea Operator in their projects and deploy instances of Gitea using the gitea.redhatgov.io Custom Resource.
+The installation of the Custom Resource Definition and Cluster Role requires *cluster-admin* privileges. After that regular users with `admin` privileges on their projects (which is automatically granted to the user who creates a project) can provision the Gitea Operator in their projects and deploy instances of Gitea using the gitea.redhatgov.io Custom Resource. If you've installed the operator from the https://github.com/RedHatGov/operator-catalog[RedHatGov Operator Catalog Index] on an OLM-enabled cluster, the Gitea operator can be installed from the OperatorHub interface of the console.
 
 Perform the following tasks as *cluster-admin*:
 
@@ -46,42 +46,7 @@ hack/operate.sh --overlay=namespaced --namespace=mynamespace
 
 == Deploying a custom Gitea instance using the Operator
 
-A Gitea instance is deployed by creating a Custom Resource based on the gitea Custom Resource Definition.
-
-.Example
-
-[source,texinfo]
-----
-apiVersion: redhatgov.io/v1alpha1
-kind: Gitea
-metadata:
-  name: gitea-example
-spec:
-  postgresql:
-    volumeSize: 1Gi
-    image:
-      src: registry.redhat.io/rhel8/postgresql-10
-      tag: latest
-  gitea:
-    expose:
-      ssl: true                                             # There is currently no way to specify an alternate certificate
-      uri: special-gitea-route.apps.cluster.example.com     # You can leave this field out on OpenShift to get the default
-      kind: Ingress                                         # This should be of kind Route on OpenShift
-    image:
-      src: quay.io/redhatgov/gitea
-      tag: latest
-      pullPolicy: IfNotPresent
-    volumeSize: 1Gi                                         # Only matters if `persistent: true`
-    resources:
-      memory:
-        request: 2Gi
-        limit: 3Gi
-      cpu:
-        request: 1000m
-        limit: 2000m
-  persistent: true
-
-----
+A Gitea instance is deployed by creating a `kind: Gitea` Custom Resource based on the Gitea Custom Resource Definition. You can see some samples in the link:config/samples/[samples directory]. If you've installed the operator from the https://github.com/RedHatGov/operator-catalog[RedHatGov Operator Catalog Index] on an OLM-enabled cluster, Custom Resource creation can be done through the console UI with embedded documentation or a form view.
 
 . Write the definition to a file (e.g. gitea.yaml) and then create the Gitea instance:
 +
@@ -110,14 +75,14 @@ oc get route
 
 == Deleting a Gitea instance
 
-Deleting a Gitea instance and its associated resources is as simple as deleting the gitea object. If you created a Gitea server called `gitea-example` as in the example above it suffices to run the delete command on that resource:
+Deleting a Gitea instance and its associated resources is as simple as deleting the gitea object. If you created a Gitea Custom Resource with `metadata.name` of `gitea-example` it suffices to run the delete command on that resource:
 
 [source,sh]
 ----
 oc delete gitea gitea-example
 ----
 
-The Operator adds ownerReference fields to all created objects - which means that deleting the gitea object also deletes all objects that have been created by the Operator.
+The Operator adds ownerReference fields to all created objects - which means that deleting the Gitea object also deletes all objects that have been created by the Operator.
 
 == Uninstalling the Gitea Operator
 
@@ -128,22 +93,25 @@ In case you wish to uninstall the Gitea Operator make sure that there are no mor
 hack/operate.sh -r
 ----
 
+OLM uninstallation for OLM-based operators can be handled through the UI, or by deleting the `Subscription`.
+
 == Notes on disconnected installations
 
-The Operator SDK makes heavy use of Kustomize for development and installation, but intends bundles to be generated for use in an operator catalog. This enables the Operator Lifecycle Manager, deployed onto your cluster, to install and configure operators with a simple `kind: Subscription` object, instead of a large collection of manifests. If you intend on using `hack/operate.sh` it expects you to be in a development environment. Operator installation from this script therefore expects access to the internet. This comes with one extra concern: If `kustomize` isn't in your path, it tries to download it from the internet and save it locally into a `.gitignore`d folder. If you intend on using `hack/operate.sh` to install the operator, you should also bring `kustomize` and place it in the `$PATH` of the user who will be running the script.
+The Operator SDK makes heavy use of Kustomize for development and installation, but intends bundles to be generated for use in an operator catalog. This enables the Operator Lifecycle Manager, deployed onto your cluster, to install and configure operators with a simple `kind: Subscription` object, instead of a large collection of manifests.
+
+If you are using a `registries.conf` change and/or ImageContentSourcePolicy mirror that covers quay.io/redhatgov images, you should not have to change anything.
 
-To change the image sources for all necessary images for `hack/operate.sh` to deploy the operator, you need to have the following images hosted in a container repository on your disconnected network:
+To change the image sources for all necessary images to deploy the operator without such a policy, you need to have the following images hosted in a container repository on your disconnected network:
 
 . quay.io/redhatgov/gitea-operator:latest
 . quay.io/redhatgov/gitea:latest
 . Some PostgreSQL 10 image that either behaves like the Red Hat PostgreSQL 10 RHEL 8 image or the docker.io/library/postgres:10 image.
 
 The places where you must update those sources are then, respectively:
 
-. `hack/operate.conf`: IMG should point to the gitea-operator image in your environment _before_ running `hack/operate.sh`
 . The `kind: Gitea` custom resource manifest: `spec.gitea.image.src` and `spec.gitea.image.tag` should be updated
 . The `kind: Gitea` custom resource manifest: `spec.postgresql.image.src` and `spec.postgresql.image.tag` should be updated
 
-== OLM installation using a custom catalog source
+If you intend on using `hack/operate.sh` it expects you to be in a development environment. Operator installation from this script therefore expects access to the internet. This comes with one extra concern: If `kustomize` isn't in your path, it tries to download it from the internet and save it locally into a `.gitignore`d folder. If you intend on using `hack/operate.sh` to install the operator, you should also bring `kustomize` and place it in the `$PATH` of the user who will be running the script. Additionally, in order to install the operator with `hack/operate.sh` you'll need to make the following change:
 
-WIP
+. `hack/operate.conf`: IMG should point to the gitea-operator image in your environment