update workshop content to remove common and be more modern

Author: dminnear-rh

content/workshop/_index.adoc

@@ -6,6 +6,10 @@ menu:
     name: Workshop
 ---
 
+= Welcome to the Validated Patterns Workshop!
+
+== Overview
+
 **Reference Architectures with Added Value**
 
 Validated Patterns are an evolution of how you deploy and manage applications in a hybrid cloud. With a pattern, you can automatically deploy a full application stack through a GitOps-based framework. With this framework, you can create business-centric solutions while maintaining a level of Continuous Integration (CI) over your application.

content/workshop/cluster-domains.adoc

@@ -9,25 +9,15 @@ weight: 102
 :toc:
 include::modules/comm-attributes.adoc[]
 
-= Cluster Domains
-
-== Topic Objectives
-
-[#objectives]
-In this topic we will discuss:
-
-* ArgoCD Limitations
-* How the framework collects and uses cluster information
-
 [#limitations]
-=== Limitations
+== Limitations
 
 By default ArgoCD does not expose any means to know the cluster's name/FQDN (Fully Qualified Domain Name)
 
 To make up for this the framework collects some cluster information in order to provide reusable parameters for cluster specific values.
 
 [#variables]
-=== Domain variables set by the pattern
+== Domain variables set by the pattern
 
 |===
 |**Variable**|**Purpose**|**Example (if applicable)**

content/workshop/consuming-patterns.adoc

@@ -8,22 +8,7 @@ weight: 50
 include::modules/comm-attributes.adoc[]
 :imagesdir: /images/workshop
 
-= Consuming Validated Patterns
-
-== Topic Objectives
-
-[#objectives]
-In this topic we will discuss:
-
-* Validated Pattern Deployment workflow
-* Describing a pattern
-* Using the patterns operator
-** And the patterns.sh script
-* Preparing your environment
-* Understand our base pattern
-* To fork or not to fork
-
-== Validated Pattern workflow
+== Consuming Validated Patterns
 [#workflow]
 
 Let's dive into what happens when we deploy a pattern! Take a look at the following graphic to see what is deployed on the `hub` clusterGroup cluster.
@@ -45,16 +30,14 @@ image::consuming-vpWorkflow-managedCluster.png[Managed Cluster]
 
 IMPORTANT: Deploying the pattern through the OpenShift Console or via `pattern.sh` will deploy the patterns operator.
 
-=== Element Layering
+== Element Layering
 [#layering]
 
-The base component of every Validated Pattern is `common` - which is a link:https://github.com/validatedpatterns/common[Github Repo]
+Architecturally, Patterns share a very similar base structure, as seen below.
 
 image::consuming-common.png[common]
 
-Without further configuration, common is actually quite boring. So let's add another layer!
-
-Your specific industry or use-case is layered into the framework and utilizes the underlying common. In this example the solution includes a bespoke application, cloud-native cluster storage, {rhacs}, and an enterprise container registry. The framework will deploy and configure these components through Helm charts, kustomize manifests or Ansible if necessary.
+Your specific industry or use-case is layered into the framework and utilizes the underlying base structure. In this example, the solution includes a bespoke application, cloud-native cluster storage, {rhacs}, and an enterprise container registry. The framework will deploy and configure these components through Helm charts, Kustomize manifests or Ansible if necessary.
 
 image::consuming-common-solution-layering.png[]
 
@@ -68,9 +51,70 @@ The following graphic illustrates swapping components in the framework:
 
 image::consuming-common-solution-layering-modular.png[]
 
-[#multiArgos]
-== Multiple ArgoCDs
+== The Base Architecture
+[#skeleton]
+
+So where exactly are these different architectural components defined?
+
+=== GitOps
+
+link:https://github.com/validatedpatterns/patterns-operator[The {validated-patterns-op}] automatically deploys an instance of {rh-gitops-short} when a Pattern CR is installed on the cluster.
+
+Check out an example Pattern CR for an {mcg-pattern} installation:
+
+[source,yaml]
+----
+apiVersion: gitops.hybrid-cloud-patterns.io/v1alpha1
+kind: Pattern
+metadata:
+  name: multicloud-gitops
+  namespace: openshift-operators
+spec:
+  clusterGroupName: hub
+  gitSpec:
+    targetRepo: https://github.com/validatedpatterns/multicloud-gitops.git
+    targetRevision: main
+----
+
+When the {validated-patterns-op} reconciles this CR, it creates an Argo Application using link:https://github.com/validatedpatterns/clustergroup-chart[the Validated Patterns Clustergroup Chart] and link:https://github.com/validatedpatterns/multicloud-gitops/blob/main/values-hub.yaml[the values-`<.spec.clusterGroupName>`.yaml values] from the CR above.
+
+=== Secrets Management
+
+The default secrets backend uses link:https://charts.validatedpatterns.io/charts/hashicorp-vault[Vault] and link:https://charts.validatedpatterns.io/charts/openshift-external-secrets[ESO].
+
+As you can see in our link:https://github.com/validatedpatterns/multicloud-gitops/blob/main/values-hub.yaml[values-hub.yaml], we provide a namespace, subscription and an application for both of these components.
+
+When we run `./pattern.sh make install` it ultimately calls link:https://github.com/validatedpatterns/rhvp.cluster_utils/blob/main/playbooks/load_secrets.yml[the rhvp.cluster_utils.load_secrets playbook] and loads a secrets file from our home directory into Vault as part of the pattern installation process.
+
+=== ACM
+
+Similar to the secrets management, link:https://charts.validatedpatterns.io/charts/acm[ACM] is provided in `values-hub.yaml` as a namespace, subscription and an application. By providing a `managedClusterGroups` block in our `values-hub.yaml` we are able to provision spoke clusters with the Validated Patterns framework as well.
+
+[source,yaml]
+----
+clusterGroup:
+  managedClusterGroups:
+    exampleRegion:
+      name: group-one
+      acmlabels:
+        - name: clusterGroup
+          value: group-one
+----
+
+Any cluster that ACM sees labeled with `clusterGroup=group-one` will be provisioned with our link:https://github.com/validatedpatterns/clustergroup-chart[Clustergroup chart] and linkhttps://github.com/validatedpatterns/multicloud-gitops/blob/main/values-group-one.yaml[values-group-one.yaml].
+
+=== Imperative Jobs
+
+The example imperative job in the {mcg-pattern} is
 
-You may be asking yourself ...
+[source,yaml]
+----
+clusterGroup:
+  imperative:
+    jobs:
+      - name: hello-world
+        playbook: rhvp.cluster_utils.hello_world
+        timeout: 234
+----
 
-image::consuming-multipleArgos.png[]
+This gets transformed by link:https://github.com/validatedpatterns/clustergroup-chart/tree/main/templates/imperative[the Clustergroup chart] into several resources. This process is a bit complex and we will cover it in more detail later.

content/workshop/creating-patterns.adoc

@@ -10,87 +10,14 @@ weight: 52
 include::modules/comm-attributes.adoc[]
 :imagesdir: /images/workshop
 
-= Creating Validated Patterns
-
-== Topic Objectives
-
-[#objectives]
-In this topic we will discuss:
-
-* Understanding `common`
-* Pattern Requirements
-* Creation Process
-
 [IMPORTANT]
 .Core Concepts
 ====
-* **Creating is Extending** We never really create a new pattern from zero. Instead we extend our basic pattern using artifacts that we have developed along the way
 * **Artifacts** Artifacts can include Helm Charts, Kustomize manifests, or plain Kubernetes manifests
 * **Moving Artifacts into the Validated Patterns framework** Many artifacts require conversion to Helm chart templates and parameterizing certain values
 * **Helm** Helm is a kubernetes package manager that allows you to define, install and manage kubernetes applications as reusable packages called charts
 ====
 
-[#common]
-== Understanding common
-
-What's the role of the **common** repository?
-
-* The core components that make up the Validated Patterns framework are contained in the common repository
-* Including:
-** OpenShift GitOps configurations
-** RHACM configuration and Global Policies
-*** Support for **clusterGroup** and **GitOps** policies
-** Validated Pattern build scripts and Makefiles
-** Secrets Management (Hashicorp Vault)
-** Operator CRDs and other assets
-** Various utility scripts
-
-What's in common?
-
-NOTE: The common repository is where all the common manifests for the Validated Patterns framework live
-
-* **acm** - contains the helm charts, which contains policies and is used to configure the deployment of the {rhacm}
-* **clusterGroup** - contains the helm charts used to create namespaces, subscriptions, Argo Project and Applications described in values files. This is the seed for all the patterns.
-* **operator-install** - contains the helm chart used by the Validated Patterns operator to create the openshift-gitops component, creating the initial ArgoCD applications for Validated Patterns.
-
-[source,bash]
-----
-common
-├── acm
-├── ansible
-├── Changes.md
-├── clustergroup
-├── common -> .
-├── examples
-├── golang-external-secrets
-├── hashicorp-vault
-├── LICENSE
-├── Makefile
-├── letsencrypt
-├── operator-install
-├── README.md
-├── reference-output.yaml
-├── scripts
-├── super-linter.log
-├── tests
-└── values-global.yaml
-----
-
-* **ansible** - this directory contains the ansible roles and modules that support the secrets management for a pattern
-* **hashicorp-vault** - contains the helm chart for {vault}
-* **scripts** - contains utility scripts used by the Validated Patterns Framework
-* **golang-external-secrets** - Helm chart for the {eso}
-
-=== What's next for common?
-
-* We are in the very early stages of moving the helm charts in common into a public Helm repository
-* Deploying our patterns with multi-source enabled which allows us to use multiple sources for values, which will help reduce the need to have all the charts in the repo
-* Continue to maintain Makefiles, Ansible scripts and other tools in this repo in support of deploying patterns
-
-You may be wondering - **why**?
-
-We want to maximize modularity in the framework. This will reduce our reliance on the common repository as it is today and will decrease the footprint and complexity of the patterns.
-
 [#creation]
 == Creation Process
 
@@ -272,3 +199,99 @@ They should be viewed as absolutely hard coded into the pattern.
       - name: ocp_auth.bind_password
         value: "supersecret"
 ----
+
+== Using Patternizer to create new patterns
+
+When creating new patterns you have two options: you can either fork an existing pattern and modify it to suit your purpose or start a new pattern from scratch.
+
+link:https://github.com/validatedpatterns/patternizer[The patternizer tool] exists to expedite starting a pattern from scratch.
+
+To create a new pattern you merely need to run `podman run --pull=newer -v "$PWD:$PWD:z" -w "$PWD" quay.io/validatedpatterns/patternizer init --with-secrets` (you can omit the `--with-secrets` if you don't need to use the secrets framework.)
+
+On an empty directory, named `workshop-pattern`, this currently produces the following files:
+
+[source,bash]
+----
+workshop-pattern
+├── ansible.cfg                 # the default ansible configuration
+├── Makefile                    # a stub Makefile which includes Makefile-common
+├── Makefile-common             # where all the common commands (install, load-secrets, etc) live
+├── pattern.sh                  # the convenvience utility container (has oc, helm, makefile, etc)
+├── values-global.yaml          # names the pattern based on the directory and sets common defaults
+├── values-prod.yaml            # contains the components for using the secrets framework
+└── values-secret.yaml.template # a stub for the secrets file
+----
+
+The `values-global.yaml` contains
+
+[source,yaml]
+----
+global:
+  pattern: workshop-pattern
+  singleArgoCD: true
+  secretLoader:
+    disabled: false
+main:
+  clusterGroupName: prod
+  multiSourceConfig:
+    enabled: true
+    clusterGroupChartVersion: 0.9.*
+----
+
+and the `values-prod.yaml` contains
+
+[source,yaml]
+----
+clusterGroup:
+  name: prod
+  namespaces:
+    - workshop-pattern
+    - vault
+    - external-secrets-operator:
+        operatorGroup: true
+        targetNamespaces: []
+    - external-secrets
+  subscriptions:
+    eso:
+      name: openshift-external-secrets-operator
+      namespace: external-secrets-operator
+      channel: stable-v1
+  applications:
+    openshift-external-secrets:
+      name: openshift-external-secrets
+      namespace: external-secrets
+      chart: openshift-external-secrets
+      chartVersion: 0.0.*
+    vault:
+      name: vault
+      namespace: vault
+      chart: hashicorp-vault
+      chartVersion: 0.1.*
+----
+
+[TIP]
+.Shell Function
+====
+You can add a simple shell function to your shell config file (ex `~/.zshrc`) to enable easier use of the tool.
+
+[source,bash]
+----
+pattern() {
+  podman run --pull=newer \
+    -v "$PWD:$PWD:z" \
+    -w "$PWD" \
+    quay.io/validatedpatterns/patternizer "$@"
+}
+----
+
+Now you can more simply run `pattern init`.
+====
+
+[NOTE]
+.Idempotency
+====
+The `pattern init` command is idempotent and can be used several times during pattern creation to update the patterns values files.
+You can go from just using `pattern init` to `pattern init --with-secrets` to add the secret framework to your pattern.
+If you use `helm create` (or `./pattern.sh helm create`) to create helm charts and then run `pattern init` again, the helm charts
+will be automatically added to your `values-prod.yaml`.
+====

content/workshop/demo.adoc

@@ -0,0 +1,13 @@
+---
+menu:
+  workshop:
+    parent: Introduction
+title: Demo
+weight: 21
+---
+
+# Validated Patterns Workshop Demo
+
+This interactive demo walks through installing the Validated Patterns operator and deploying the [Multicloud Gitops](/patterns/multicloud-gitops/) pattern on a fresh OpenShift cluster using the Validated Patterns Catalog.
+
+{{< arcade url="https://demo.arcade.software/share/m8RRb4Wanooo2Vq6iV5O" title="Validated Patterns Workshop Demo" >}}

content/workshop/demo.md

@@ -10,8 +10,6 @@ weight: 61
 include::modules/comm-attributes.adoc[]
 :imagesdir: /images/workshop
 
-= Secrets Management in Validated Patterns
-
 [#esoVault]
 == ESO and Vault