Setup make index for testing (#1183)

- Reconfigure index file generation
- checkout gh-pages branch in promote.yaml
- fix helm-index make target
- add gh-pages folder in .gitignore

Signed-off-by: Miles Wilson <wilson.mil@icloud.com>
Co-authored-by: Hao Liu <haoli@redhat.com>
Co-authored-by: Christian Adams <rooftopcellist@gmail.com>

.github/workflows/pr_body_check.yml

@@ -13,21 +13,13 @@ jobs:
       packages: write
       contents: read
     steps:
-      - name: Write PR body to a file
-        run: |
-          cat >> pr.body << __SOME_RANDOM_PR_EOF__
-          ${{ github.event.pull_request.body }}
-          __SOME_RANDOM_PR_EOF__
-
-      - name: Display the received body for troubleshooting
-        run: cat pr.body
-
-      # We want to write these out individually just incase the options were joined on a single line
       - name: Check for each of the lines
+        env:
+          PR_BODY: ${{ github.event.pull_request.body }}
         run: |
-          grep "Bug, Docs Fix or other nominal change" pr.body > Z
-          grep "New or Enhanced Feature" pr.body > Y
-          grep "Breaking Change" pr.body > X
+          echo $PR_BODY | grep "Bug, Docs Fix or other nominal change" > Z
+          echo $PR_BODY | grep "New or Enhanced Feature" > Y
+          echo $PR_BODY | grep "Breaking Change" > X
           exit 0
         # We exit 0 and set the shell to prevent the returns from the greps from failing this step
         # See https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#exit-codes-and-error-action-preference

.github/workflows/promote.yaml

@@ -8,7 +8,14 @@ jobs:
   promote:
     runs-on: ubuntu-latest
     steps:
-      - uses: actions/checkout@v2
+      - uses: actions/checkout@v3
+        with:
+          depth: 0
+
+      - uses: actions/checkout@v3
+        with:
+          ref: gh-pages
+          path: gh-pages
 
       - name: Log in to GHCR
         run: |

.gitignore

@@ -1,4 +1,5 @@
 *~
+gh-pages/
 .cache/
 /bin
 /bundle

.helm/starter/README.md

@@ -1,6 +1,6 @@
 # AWX Operator Helm Chart
 
-This chart installs the AWX Operator resources configured in [this](https://github.com/ansible/awx-operator) repository. 
+This chart installs the AWX Operator resources configured in [this](https://github.com/ansible/awx-operator) repository.
 
 ## Getting Started
 To configure your AWX resource using this chart, create your own `yaml` values file. The name is up to personal preference since it will explicitly be passed into the helm chart. Helm will merge whatever values you specify in your file with the default `values.yaml`, overriding any settings you've changed while allowing you to fall back on defaults. Because of this functionality, `values.yaml` should not be edited directly.
@@ -8,7 +8,7 @@ To configure your AWX resource using this chart, create your own `yaml` values f
 In your values config, enable `AWX.enabled` and add `AWX.spec` values based on the awx operator's [documentation](https://github.com/ansible/awx-operator/blob/devel/README.md). Consult the docs below for additional functionality.
 
 ### Installing
-The operator's [helm install](https://github.com/ansible/awx-operator/blob/devel/README.md#helm-install-on-existing-cluster) guide provides key installation instructions. 
+The operator's [helm install](https://github.com/ansible/awx-operator/blob/devel/README.md#helm-install-on-existing-cluster) guide provides key installation instructions.
 
 Example:
 ```
@@ -27,10 +27,10 @@ To update an existing installation, use `helm upgrade` instead of `install`. The
 ## Configuration
 The goal of adding helm configurations is to abstract out and simplify the creation of multi-resource configs. The `AWX.spec` field maps directly to the spec configs of the `AWX` resource that the operator provides, which are detailed in the [main README](https://github.com/ansible/awx-operator/blob/devel/README.md). Other sub-config can be added with the goal of simplifying more involved setups that require additional resources to be specified.
 
-These sub-headers aim to be a more intuitive entrypoint into customizing your deployment, and are easier to manage in the long-term. By design, the helm templates will defer to the manually defined specs to avoid configuration conflicts. For example, if `AWX.spec.postgres_configuration_secret` is being used, the `AWX.postgres` settings will not be applied, even if enabled. 
+These sub-headers aim to be a more intuitive entrypoint into customizing your deployment, and are easier to manage in the long-term. By design, the helm templates will defer to the manually defined specs to avoid configuration conflicts. For example, if `AWX.spec.postgres_configuration_secret` is being used, the `AWX.postgres` settings will not be applied, even if enabled.
 
 ### External Postgres
-The `AWX.postgres` section simplifies the creation of the external postgres secret. If enabled, the configs provided will automatically be placed in a `postgres-config` secret and linked to the `AWX` resource. For proper secret management, the `AWX.postgres.password` value, and any other sensitive values, can be passed in at the command line rather than specified in code. Use the `--set` argument with `helm install`. 
+The `AWX.postgres` section simplifies the creation of the external postgres secret. If enabled, the configs provided will automatically be placed in a `postgres-config` secret and linked to the `AWX` resource. For proper secret management, the `AWX.postgres.password` value, and any other sensitive values, can be passed in at the command line rather than specified in code. Use the `--set` argument with `helm install`. Supplying the password this way is not recommended for production use, but may be helpful for initial PoC.
 
 
 ## Values Summary
@@ -44,13 +44,24 @@ The `AWX.postgres` section simplifies the creation of the external postgres secr
 | `AWX.postgres` | configurations for the external postgres secret | - |
 
 
-# Contributing 
+# Contributing
 
 ## Adding abstracted sections
-Where possible, defer to `AWX.spec` configs before applying the abstracted configs to avoid collision. This can be facilitated by the `(hasKey .spec what_i_will_abstract)` check. 
+Where possible, defer to `AWX.spec` configs before applying the abstracted configs to avoid collision. This can be facilitated by the `(hasKey .spec what_i_will_abstract)` check.
 
 ## Building and Testing
 This chart is built using the Makefile in the [awx-operator repo](https://github.com/ansible/awx-operator). Clone the repo and run `make helm-chart`. This will create the awx-operator chart in the `charts/awx-operator` directory. In this process, the contents of the `.helm/starter` directory will be added to the chart.
 
 ## Future Goals
 All values under the `AWX` header are focused on configurations that use the operator. Configurations that relate to the Operator itself could be placed under an `Operator` heading, but that may add a layer of complication over current development.
+
+
+# Chart Publishing
+
+The chart is currently hosted on the gh-pages branch of the repo. During the release pipeline, the `index.yaml` stored in that branch is generated with helm chart entries from all valid tags. We are currently unable to use the `chart-releaser` pipeline due to the fact that the complete helm chart is not committed to the repo and is instead built during the release process. Therefore, the cr action is unable to compare against previous versions.
+
+Instead of CR, we use `helm repo index` to generate an index from all locally pulled chart versions. Since we build from scratch every time, the timestamps of all entries will be updated. This could be improved by using yq or something similar to detect which tags are already in the index.yaml file, and only merge in tags that are not present.
+
+Not using CR could be addressed in the future by keeping the chart built as a part of releases, as long as CR compares the chart to previous release packages rather than previous commits. If the latter is the case, then we would not have the necessary history for comparison.
+
+

Makefile

@@ -350,43 +350,52 @@ helm-chart-generate: kustomize helm kubectl-slice yq charts
 
 
 .PHONY: helm-package
-helm-package: cr helm-chart
-	@echo "== CHART RELEASER (package) =="
-	$(CR) package ./charts/awx-operator
+helm-package: helm-chart
+	@echo "== Package Current Chart Version =="
+	mkdir -p .cr-release-packages
+	# package the chart and put it in .cr-release-packages dir
+	$(HELM) package ./charts/awx-operator -d .cr-release-packages
 
 # List all tags oldest to newest.
 TAGS := $(shell git ls-remote --tags --sort=version:refname --refs -q | cut -d/ -f3)
 
-# The actual release happens in ansible/helm-release.yml
-# until https://github.com/helm/chart-releaser/issues/122 happens
+# The actual release happens in ansible/helm-release.yml, which calls this targer
+# until https://github.com/helm/chart-releaser/issues/122 happens, chart-releaser is not ideal for a chart
+# that is contained within a larger repo, where a tag may not require a new chart version
 .PHONY: helm-index
-helm-index: cr helm-chart
-	@echo "== CHART RELEASER (httpsorigin) =="
-	git remote add httpsorigin "https://github.com/$(CHART_OWNER)/$(CHART_REPO).git"
-	git fetch httpsorigin
+helm-index:
+	# when running in CI this gh-pages are already checked out with github action to 'gh-pages' directory
+	# TODO: test if gh-pages directory exists and if not exist
 
+	@echo "== GENERATE INDEX FILE =="
 	# This step to workaround issues with old releases being dropped.
 	# Until https://github.com/helm/chart-releaser/issues/133 happens
 	@echo "== CHART FETCH previous releases =="
 	# Download all old releases
-	cd .cr-release-packages;\
+	mkdir -p .cr-release-packages
+
 	for tag in $(TAGS); do\
-		dl_url="https://github.com/$${CHART_OWNER}/$${CHART_REPO}/releases/download/$${tag}/$${CHART_REPO}-$${tag}.tgz";\
-		curl -RLOs -z "$${CHART_REPO}-$${tag}.tgz" --fail $${dl_url};\
+		dl_url="https://github.com/$(CHART_OWNER)/$(CHART_REPO)/releases/download/$${tag}/$(CHART_REPO)-$${tag}.tgz";\
+		echo "Downloading $${tag} from $${dl_url}";\
+		curl -RLOs -z ".cr-release-packages/$(CHART_REPO)-$${tag}.tgz" --fail $${dl_url};\
 		result=$$?;\
 		if [ $${result} -eq 0 ]; then\
-			echo "Downloaded $$dl_url";\
+			echo "Downloaded $${dl_url}";\
+		else\
+			echo "Skipping release $${tag}; No helm chart present";\
+			rm -rf ".cr-release-packages/$(CHART_REPO)-$${tag}.tgz";\
 		fi;\
-	done
+	done;\
 
-	@echo "== CHART RELEASER (index) =="
-	$(CR) index \
-		--owner "$(CHART_OWNER)" \
-		--git-repo "$(CHART_REPO)" \
-		--token "$(CR_TOKEN)" \
-		--pages-branch "$(CHART_BRANCH)" \
-		--index-path "./charts/$(CHART_INDEX)" \
-		--charts-repo "https://$(CHART_OWNER).github.io/$(CHART_REPO)/$(CHART_INDEX)" \
-		--remote httpsorigin \
-		--release-name-template="{{ .Version }}" \
-		--push
+	# generate the index file in the root of the gh-pages branch
+	# --merge will leave any values in index.yaml that don't get generated by this command, but
+	# it is likely that all values are overridden
+	$(HELM) repo index .cr-release-packages --url https://$(CHART_OWNER).github.io/awx-operator/ --merge gh-pages/index.yaml
+
+	mv .cr-release-packages/index.yaml gh-pages/index.yaml
+
+	@echo "== PUSH INDEX FILE =="
+	cd gh-pages;\
+	git add index.yaml;\
+	git commit -m "Updated index.yaml latest release";\
+	git push;\

README.md

@@ -813,7 +813,22 @@ spec:
   bundle_cacert_secret: <resourcename>-custom-certs
 ```
 
-To create the secrets, you can use the commands below:
+Create the secret with `kustomization.yaml` file:
+
+```yaml
+....
+
+secretGenerator:
+  - name: <resourcename>-custom-certs
+    files:
+      - bundle-ca.crt=<path+filename>
+    options:
+      disableNameSuffixHash: true
+      
+...
+```
+
+Create the secret with CLI:
 
 * Certificate Authority secret
 
@@ -1222,7 +1237,14 @@ Apply the awx-operator.yml for that release to upgrade the operator, and in turn
 
 #### Backup
 
-The first part of any upgrade should be a backup. Note, there are secrets in the pod which work in conjunction with the database. Having just a database backup without the required secrets will not be sufficient for recovering from an issue when upgrading to a new version. See the [backup role documentation](https://github.com/ansible/awx-operator/tree/devel/roles/backup) for information on how to backup your database and secrets. In the event you need to recover the backup see the [restore role documentation](https://github.com/ansible/awx-operator/tree/devel/roles/restore).
+The first part of any upgrade should be a backup. Note, there are secrets in the pod which work in conjunction with the database. Having just a database backup without the required secrets will not be sufficient for recovering from an issue when upgrading to a new version. See the [backup role documentation](https://github.com/ansible/awx-operator/tree/devel/roles/backup) for information on how to backup your database and secrets.
+
+In the event you need to recover the backup see the [restore role documentation](https://github.com/ansible/awx-operator/tree/devel/roles/restore). *Before Restoring from a backup*, be sure to:
+* delete the old existing AWX CR
+* delete the persistent volume claim (PVC) for the database from the old deployment, which has a name like `postgres-13-<deployment-name>-postgres-13-0`
+
+**Note**: Do not delete the namespace/project, as that will delete the backup and the backup's PVC as well.
+
 
 #### PostgreSQL Upgrade Considerations
 

molecule/default/templates/awx_cr_molecule.yml.j2

@@ -26,6 +26,7 @@ spec:
     requests:
       cpu: 50m
       memory: 16M
+  no_log: false
   postgres_resource_requirements: {}
   postgres_init_container_resource_requirements: {}
   redis_resource_requirements: {}

roles/installer/tasks/initialize_django.yml

@@ -18,10 +18,21 @@
     namespace: "{{ ansible_operator_meta.namespace }}"
     pod: "{{ tower_pod_name }}"
     container: "{{ ansible_operator_meta.name }}-task"
-    command: >-
-      bash -c "echo \"from django.contrib.auth.models import User;
-      User.objects.create_superuser('{{ admin_user }}', '{{ admin_email }}', '{{ admin_password }}')\"
-      | awx-manage shell"
+    command: awx-manage createsuperuser --username={{ admin_user | quote }} --email={{ admin_email | quote }} --noinput
+  register: result
+  changed_when: "'That username is already taken' not in result.stderr"
+  failed_when: "'That username is already taken' not in result.stderr and 'Superuser created successfully' not in result.stdout"
+  no_log: "{{ no_log }}"
+  when: users_result.return_code > 0
+
+- name: Update Django super user password
+  k8s_exec:
+    namespace: "{{ ansible_operator_meta.namespace }}"
+    pod: "{{ tower_pod_name }}"
+    container: "{{ ansible_operator_meta.name }}-task"
+    command: awx-manage update_password --username='{{ admin_user }}' --password='{{ admin_password }}'
+  register: result
+  changed_when: "'Password updated' in result.stdout"
   no_log: "{{ no_log }}"
   when: users_result.return_code > 0
 

roles/installer/tasks/upgrade_postgres.yml

@@ -93,7 +93,7 @@
     command: |
       bash -c """
       set -e -o pipefail
-      PGPASSWORD={{ awx_postgres_pass }} {{ pgdump }} | PGPASSWORD={{ awx_postgres_pass }} {{ pg_restore }}
+      PGPASSWORD='{{ awx_postgres_pass }}' {{ pgdump }} | PGPASSWORD='{{ awx_postgres_pass }}' {{ pg_restore }}
       echo 'Successful'
       """
   no_log: "{{ no_log }}"

roles/restore/README.md

@@ -17,6 +17,12 @@ This role assumes you are authenticated with an Openshift or Kubernetes cluster:
   - AWX is deployed to via the operator
   - An AWX backup is available on a PVC in your cluster (see the backup [README.md](../backup/README.md))
 
+*Before Restoring from a backup*, be sure to:
+  - delete the old existing AWX CR
+  - delete the persistent volume claim (PVC) for the database from the old deployment, which has a name like `postgres-13-<deployment-name>-postgres-13-0`
+
+**Note**: Do not delete the namespace/project, as that will delete the backup and the backup's PVC as well.
+
 
 Usage
 ----------------