adding more updates 4

Author: kquinn1204

content/patterns/ansible-edge-gitops/ansible-automation-platform.adoc

@@ -27,16 +27,19 @@ Follow these steps to log in to the Ansible Automation Platform using the OpenSh
 .AAP secret
 image::/images/ansible-edge-gitops/ocp-console-secrets-aap-admin-password-v1.png[ansible-edge-observability-operators,title="AAP secret"]
 
-.. Select the `controller-admin-password`. 
+.. Select the `aap-admin-password`. 
 
 .. In the *Data* field click *Reveal values* to display the password. 
 +
 .AAP secret detail
 image::/images/ansible-edge-gitops/ocp-console-aap-admin-password-detail-v1.png[ansible-edge-observability-operators,title="AAP secret details"]
 
-. Under *Networking* > *Routes*, click the URL for the `controller` route to open the Ansible Automation Platform interface. 
+. Under *Networking* > *Routes*, click the URL for the `aap` route to open the Ansible Automation Platform interface. 
 
-.. Log in using the `admin` user and the password you retrieved from the `controller-admin-password` secret. 
+.. Log in using the `admin` user and the password you retrieved from the `aap-admin-password` secret. A screen similar to the following appears:
++
+.AAP login
+image::/images/ansible-edge-gitops/aap-login-v1.png[ansible-edge-observability-operators,title="AAP login"]
 
 [id="logging-in-using-secret-retrieved-using-script-ansible_get_credentials"]
 === Logging in using a secret retrieved with ansible_get_credentials.sh
@@ -91,155 +94,16 @@ localhost                  : ok=7    changed=0    unreachable=0    failed=0    s
 
 == Pattern AAP Configuration Details
 
-In this section, we describe the details of the AAP configuration we apply as part of installing the pattern. All of the configuration
-discussed in this section is applied by the
+In this section, we describe the details of the AAP configuration we apply as part of installing the pattern. All of the configuration discussed in this section is applied by the
 https://github.com/validatedpatterns/ansible-edge-gitops/blob/main/scripts/ansible_load_controller.sh[ansible_load_controller.sh]
 script.
 
-=== Loading a Manifest
-
-After validating that AAP is ready to be configured, the first thing the script does is to install the manifest you specify in the
-`values-secret.yaml` file in the `files.manifest+` setting. The value of this setting is expected to be a fully-pathed file that represents a
-Red Hat Satellite manifest file with a valid entitlement for AAP. The
-_only_ thing this manifest is used for is entitling AAP.
-
-Instructions for creating a suitable manifest file can be found https://www.redhat.com/en/blog/how-create-and-use-red-hat-satellite-manifest[here].
-
-While it is absolutely possible to entitle AAP via a username/password on first login, the automated mechanisms for entitling only support
-manifests, that is the technique the pattern uses.
-
-=== Organizations
-
-The pattern installs an Organization called `HMI Demo` is installed. This makes it a bit easier to separate what the pattern is doing versus
-the default configuration of AAP. The other resources created in AAP as part of the load process are associated with this Organization.
-
-=== Credential Types (and their Credentials)
-
-==== Kubeconfig (Kubeconfig)
-
-The Kubeconfig credential is for holding the OpenShift cluster admin kubeconfig file. This is used to query the `edge-gitops-vms+` namespace
-for running VM instances. Since the kubeconfig is necessary for installing the pattern and must be available when the load script is
-running, the load script pulls it into an AAP secret and stores it for later use (and calls it `Kubeconfig`).
-
-The template for creating the Credential Type was taken from https://blog.networktocode.com/post/kubernetes-collection-ansible/[here].
-
-==== RHSMcredential (rhsm_credential)
-
-This credential is required to register the RHEL VMs and configure them for Kiosk mode. The registration process allows them to install packages
-from the Red Hat Content Delivery Network.
-
-==== Machine (kiosk-private-key)
-
-This is a standard AAP Machine type credential. `kiosk-private-key` is created with the username and private key from your
-`values-secret.yaml+` file in the `kiosk-ssh.username` and `kiosk-ssh.privatekey` fields.
-
-==== KioskExtraParams (kiosk_container_extra_params)
-
-This CredentialType is considered "`secret`" because it includes the admin login password for the Ignition application. This passed to the
-provisioning playbook(s) as extra_vars.
-
-=== Inventory
-
-The pattern installs an Inventory (HMI Demo), but no inventory sources. This is due to the way that OpenShift Virtualization provides access to
-virtual machines. The IP address associated with the SSH service that a given VM is running is associated with the Service object on the VM.
-This is not the way the Kubernetes inventory plugin expects to work. So to make inventory dynamic, we are instead using a play to discover VMs
-and add them to inventory "`on the fly`". What is unusual about DNS inside a Kubernetes cluster is that resources outside the namespace must
-use the cluster FQDN - which is `resource-name.resource-namespace.svc`.
-
-It is also possible to define a static inventory - an example of how this would like is preserved in the pattern repository as
-https://github.com/validatedpatterns/ansible-edge-gitops/blob/main/ansible/inventory/hosts[hosts].
-
-A standard dynamic inventory script is available https://github.com/validatedpatterns/ansible-edge-gitops/blob/main/ansible/inventory/openshift_cluster.yml[here].
-This will retrieve the object names, but it will not (currently) map the FQDN properly. Because of this limitation, we moved to using the
-inventory pre-play method.
-
-=== Templates (key playbooks in the pattern)
-
-==== https://github.com/validatedpatterns/ansible-edge-gitops/blob/main/ansible/dynamic_kiosk_provision.yml[Dynamic Provision Kiosk Playbook]
-
-This combines all three key workflows in this pattern:
-
-* Dynamic inventory (inventory preplay)
-* Kiosk Mode
-* Podman Playbook
-
-It is safe to run multiple times on the same system. It is run on a schedule, every 10 minutes, to demonstrate this.
-
-==== https://github.com/validatedpatterns/ansible-edge-gitops/blob/main/ansible/kiosk_playbook.yml[Kiosk Mode Playbook]
-
-This playbook runs the link:/patterns/ansible-edge-gitops/ansible-automation-platform/#roles-included-in-the-pattern[kiosk_mode
-role].
-
-==== https://github.com/validatedpatterns/ansible-edge-gitops/blob/main/ansible/podman_playbook.yml[Podman Playbook]
-
-This playbook runs the link:/patterns/ansible-edge-gitops/ansible-automation-platform/#roles-included-in-the-pattern[container_lifecycle
-role] with overrides suitable for the Ignition application container.
-
-==== https://github.com/validatedpatterns/ansible-edge-gitops/blob/main/ansible/ping.yml[Ping Playbook]
-
-This playbook is for testing basic connectivity - making sure that you can reach the nodes you wish to manage, and that the credentials you
-have given will work on them. It will not change anything on the VMs - just gather facts from them (which requires elevating to root).
-
-=== Schedules
-
-==== Update Project AEG GitOps
-
-This job runs every 5 minutes to update the GitOps repository associated with the project. This is necessary when any of the Ansible code (for
-example, the playbooks or roles associated with the pattern) changes, so that the new code is available to the AAP instance.
-
-==== Dynamic Provision Kiosk Playbook
-
-This job runs every 10 minutes to provision and configure any kiosks it finds to run the Ignition application in a podman container, and
-configure firefox in kiosk mode to display that application. The playbook is designed to be idempotent, so it is safe to run multiple
-times on the same targets; it will not make user-visible changes to those targets unless it must.
-
-This playbook combines the link:/patterns/ansible-edge-gitops/ansible-automation-platform/#extra-playbooks-in-the-pattern[inventory_preplay]
-and the link:/patterns/ansible-edge-gitops/ansible-automation-platform/#extra-playbooks-in-the-pattern[Provision
-Kiosk Playbook].
-
-=== Execution Environment
-
-The pattern includes an execution environment definition that can be found https://github.com/validatedpatterns/ansible-edge-gitops/tree/main/ansible/execution_environment[here].
-
-The execution environment includes some additional collections beyond what is provided in the Default execution environment, including:
-
-* https://linux-system-roles.github.io/[fedora.linux_system_roles]
-* https://galaxy.ansible.com/containers/podman[containers.podman]
-* https://docs.ansible.com/ansible/latest/collections/community/okd/index.html[community.okd]
-
-The execution environment definition is provided if you want to customize or change it; if so, you should also change the Execution
-Environment attributes of the Templates (in the https://github.com/validatedpatterns/ansible-edge-gitops/blob/main/scripts/ansible_load_controller.sh[load
-script], those attributes are set by the variables `aap_execution_environment` and `aap_execution_environment_image`).
-
-=== Roles included in the pattern
-
-==== https://github.com/validatedpatterns/ansible-edge-gitops/tree/main/ansible/roles/kiosk_mode[kiosk_mode]
-
-This role is responsible does the following:
-
-* RHEL node registration
-* Installation of GUI packages
-* Installation of Firefox
-* Configuration of Firefox kiosk mode
-
-==== https://github.com/validatedpatterns/ansible-edge-gitops/tree/main/ansible/roles/container_lifecycle[container_lifecycle]
-
-This role is responsible for:
-
-* Downloading and running a podman image on the system (and configure it to auto-update)
-* Setting the container up to run at boot time
-* Passing any other runtime arguments to the container. In this container’s case, that includes specifying an admin password override.
-
-=== Extra Playbooks in the Pattern
+The `ansible_load_controller.sh` script automates the configuration of the Ansible Automation Platform (AAP) by executing a series of Ansible playbooks. These playbooks perform tasks such as retrieving credentials, parsing secrets, and configuring the AAP instance.
 
-==== https://github.com/validatedpatterns/ansible-edge-gitops/blob/main/ansible/inventory_preplay.yml[inventory_preplay.yml]
+Key components of the configuration process:
 
-This playbook is designed to be included in other plays; its purpose is to discover the desired inventory and add those hosts to inventory at
-runtime. It uses a kubernetes query via the cluster-admin kube config file.
+* Retrieving AAP Credentials: The script runs the `ansible_get_credentials.yml` playbook to obtain necessary credentials for accessing and managing the AAP instance.
 
-==== https://github.com/validatedpatterns/ansible-edge-gitops/blob/main/ansible/provision_kiosk.yml[Provision Kiosk Playbook]
+* Parsing Secrets: It then executes the `parse_secrets_from_values_secret.yml` playbook to extract and process sensitive information stored in the `values_secret.yaml` file, which includes passwords, tokens, or other confidential data required for configuration.
 
-This does the work of provisioning the kiosk, which configures kiosk mode, and also installs Ignition and configures it to start at boot. It
-runs the link:/patterns/ansible-edge-gitops/ansible-automation-platform/#roles-included-in-the-pattern[kiosk_mode]
-and link:/patterns/ansible-edge-gitops/ansible-automation-platform/#roles-included-in-the-pattern[container_lifecycle]
-roles.
+* Configuring the AAP Instance: Finally, the script runs the `ansible_configure_controller.yml` playbook to set up and configure the AAP controller based on the retrieved credentials and parsed secrets.

content/patterns/ansible-edge-gitops/getting-started.adoc

@@ -154,6 +154,27 @@ This is the username and password that you use to log in to link:https://catalog
       base64: true
 ----
 
+.. Edit the `automation-hub-token` section to include the token generated at the *Load token* link at link:https://console.redhat.com/ansible/automation-hub/token[Automation Hub Token] to generate a token. For example:
++
+[source,yaml]
+----
+  - name: automation-hub-token
+    fields:
+    - name: token
+      path: '/path/to/automation-hub-token'
+----
+
+.. Optionally: Edit the `agof-vault-file` section to use the following (you do not need additional secrets for this pattern):
++
+[source,yaml]
+----
+  - name: agof-vault-file
+    fields:
+    - name: agof-vault-file
+      value: '---'
+      base64: true
+----
+
 . Create and switch to a new branch named `my-branch`, by running the following command:
 +
 [source,terminal]

content/patterns/ansible-edge-gitops/installation-details.adoc

@@ -101,41 +101,20 @@ The script has defaults that are overridden when run as part of make install. Th
 OpenShift GitOps is central to this pattern as it is responsible for insalling all of the other components. The installation process is driven through the installation of the
 https://github.com/validatedpatterns/common/tree/v1/clustergroup[clustergroup] cart. This in turn reads the repo’s https://github.com/validatedpatterns/ansible-edge-gitops/blob/main/values-global.yaml[global values file], which instructs it to read the https://github.com/validatedpatterns/ansible-edge-gitops/blob/main/values-hub.yaml[hub values file]. This is how the pattern knows to apply the Subscriptions and Applications listed further in the pattern.
 
-== ODF (OpenShift Data Foundations)
-
-ODF is the storage framework that is needed to provide resilient storage for OpenShift Virtualization. It is managed via the helm chart https://github.com/validatedpatterns/ansible-edge-gitops/tree/main/charts/hub/openshift-data-foundations[here].
-
-This is basically the same chart that our Medical Diagnosis pattern uses (see link:/patterns/medical-diagnosis/getting-started/[here] for details on the Medical Edge pattern’s use of storage).
-
-[NOTE]
-====
-This chart will create a Noobaa S3 bucket named nb.epoch_timestamp.cluster-domain which will not be destroyed when the cluster is destroyed.
-====
-
 == OpenShift Virtualization (KubeVirt)
 
 OpenShift Virtualization is a framework for running virtual machines as native Kubernetes resources. While it can run without hardware acceleration, the performance of virtual machines will suffer terribly; some testing on a similar workload indicated a 4-6x delay running without hardware acceleration, so at present this pattern requires hardware acceleration. The pattern provides a script https://github.com/validatedpatterns/ansible-edge-gitops/blob/main/scripts/deploy_kubevirt_worker.sh[deploy-kubevirt-worker.sh] which will provision a metal worker to run virtual machines for the pattern.
 
 OpenShift Virtualization currently supports only AWS and on-prem clusters; this is because of the way that baremetal resources are provisioned in GCP and Azure. We hope that OpenShift Virtualization can support GCP and Azure soon.
 
-The installation of the OpenShift Virtualization HyperConverged deployment is controlled by the chart https://github.com/validatedpatterns/ansible-edge-gitops/tree/main/charts/hub/cnv[here].
-
-OpenShift Virtualization was chosen in this pattern to avoid dealing with the differences in galleries and templates of images between the different public cloud providers. The important thing from this pattern’s standpoint is the availability of machine instances to manage (since we are simulating an Edge deployment scenario, which could either be bare metal instances or virtual machines); OpenShift Virtualization was the easiest and most portable way to spin up machine instances. It also provides mechanisms for defining the desired machine set
-declaratively.
-
-The creation of virtual machines is controlled by the chart https://github.com/validatedpatterns/ansible-edge-gitops/tree/main/charts/hub/edge-gitops-vms[here].
-
 More details about the way we use OpenShift Virtualization are available link:/ansible-edge-gitops/openshift-virtualization[here].
 
 == Ansible Automation Platform (AAP, formerly known as Ansible Tower)
 
-The use of Ansible Automation Platform is really the centerpiece of this pattern. We have recognized for some time that the notion and design principles of GitOps should apply to things outside of Kubernetes, andwe believe this pattern gives us a way to do that.
+The use of Ansible Automation Platform is really the centerpiece of this pattern. We have recognized for some time that the concept and design principles of GitOps should apply to things outside of Kubernetes, and we believe this pattern gives us a way to do that.
 
 All of the Ansible interactions are defined in a Git Repository; the Ansible jobs that configure the VMs are designed to be idempotent (and are scheduled to run every 10 minutes on those VMs).
 
-The installation of AAP itself is governed by the chart https://github.com/validatedpatterns/ansible-edge-gitops/tree/main/charts/hub/ansible-automation-platform[here].
-The post-installation configuration of AAP is done via the https://github.com/validatedpatterns/ansible-edge-gitops/blob/main/scripts/ansible_load_controller.sh[ansible-load-controller.sh] script.
-
 It is very much the intention of this pattern to make it easy to replace the specific Edge management use case with another one. Some ideas on how to do that can be found link:/ansible-edge-gitops/ideas-for-customization/[here].
 
 Specifics of the Ansible content for this pattern can be seen https://github.com/validatedpatterns/ansible-edge-gitops/tree/main/ansible[here].