reorganising

Author: kquinn1204

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

@@ -1,6 +1,6 @@
 ---
 title: Ansible Automation Platform
-weight: 20
+weight: 30
 aliases: /federated-edge-observability/aap/
 ---
 

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

@@ -1,4 +1,4 @@
-5-Day Gen AI Intensive Course with Google---
+---
 title: Getting Started
 weight: 10
 aliases: /ansible-edge-gitops/getting-started/

content/patterns/ansible-edge-gitops/ideas-for-customization.adoc

@@ -1,13 +1,20 @@
+---
+title: Ideas for Customization
+weight: 40
+aliases: /ansible-edge-gitops/ideas-for-customization/
+---
+
+:toc:
+:imagesdir: /images
+:_content-type: ASSEMBLY
+include::modules/comm-attributes.adoc[]
+
 == Ideas for Customization
 
 == Why change it?
 
-One of the major goals of the Red Hat patterns development process is to
-create modular, customizable demos. Maybe you are not interested in
-Ignition as an application, or you do not have kiosks…but you do have
-other use cases that involve running containers on edge devices. Maybe
-you want to experiment with different releases of RHEL, or you want to
-do something different with Ansible Automation Platform.
+One of the major goals of the Red Hat patterns development process is to create modular, customizable demos. Maybe you are not interested in
+Ignition as an application, or you do not have kiosks…but you do have other use cases that involve running containers on edge devices. Maybe you want to experiment with different releases of RHEL, or you want to do something different with Ansible Automation Platform.
 
 This demo in particular can be customized in a number of ways that might
 be very interesting - and here are some starter ideas with some

content/patterns/ansible-edge-gitops/ideas-for-customization.md

@@ -12,11 +12,11 @@ One of the major goals of the Red Hat patterns development process is to create
 
 This demo in particular can be customized in a number of ways that might be very interesting - and here are some starter ideas with some instructions on exactly what and where changes would need to be made in the pattern to accommodate those changes.
 
-# HOWTO define your own VM sets using the chart
+# Defining your own VM sets using the chart
 
-1. Either fork the repo or copy the edge-gitops-vms chart out of it.
+. Either fork the repo or copy the edge-gitops-vms chart out of it.
 
-1. Customize the [values.yaml](https://github.com/validatedpatterns/ansible-edge-gitops/blob/main/charts/hub/edge-gitops-vms/values.yaml) file
+. Customize the [values.yaml](https://github.com/validatedpatterns/ansible-edge-gitops/blob/main/charts/hub/edge-gitops-vms/values.yaml) file
 
 The `vms` data structure is designed to support multiple groups and types of VMs. The `kiosk` example defines all of the variables currently supported by the chart, including references to the Vault instance and port definitions.  If, for example, you wanted to replace kiosk with new iotsensor and iotgateway types, the whole file might look like this:
 

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

@@ -1,3 +1,14 @@
+---
+title: Installation Details
+weight: 20
+aliases: /ansible-edge-gitops/installation-details/
+---
+
+:toc:
+:imagesdir: /images
+:_content-type: ASSEMBLY
+include::modules/comm-attributes.adoc[]
+
 == Installation Details
 
 == Installation Steps
@@ -93,7 +104,7 @@ The script waits until AAP is ready, and then proceeds to:
 . Configure Schedules for the jobs that need to repeat
 
 _Note:_ This script has defaults that it overrides when run as part of make install` that it derives from the environment (the repo that it
-is attached to and the branch that it is on). So if you need to re-run i, the most straightforward way to do this is to run `+make upgrade+`
+is attached to and the branch that it is on). So if you need to re-run i, the most straightforward way to do this is to run `make upgrade+`
 when using the make-based installation process.
 
 == OpenShift GitOps (ArgoCD)
@@ -109,15 +120,12 @@ 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
+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
+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).
 
-Please note that this chart will create a Noobaa S3 bucket named
-nb.epoch_timestamp.cluster-domain which will not be destroyed when the
+Please note that 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)