Merge branch 'cmbc_19july' into 'master'

Update docs/guides/using-bigbang/style.md,...

See merge request !4781

docs/guides/using-bigbang/style.md

 # General Conventions Style Guide
-This style guide outlines the general conventions to follow for package names, structure standardization, version numbers, and YAML formatting focusing on the Big Bang Helm chart. Individual packages (core, addons, community) may not follow these exact standards.
+This style guide outlines the general conventions to follow for package names, structure standardization, version numbers, and YAML formatting focusing on the Big Bang Helm chart. Individual packages (e.g., core, addons, community) may not follow these exact standards.
 
 ## Package Names
-When creating package names, consider that different usages of the name will require different formats. For Helm values keys use camelCase to delineate multi-word package names. Avoid using . or - within values keys to simplify Helm templating. Kubernetes resources require translation to kebab-case as they do not support uppercase. Package naming for Kubernetes resources should be consistent across all resources (GitRepository, Namespace, HelmRelease, labels, etc).
+When creating package names, consider that different usages of the name will require different formats. For Helm values keys use camelCase to delineate multi-word package names. Avoid using . or - within values keys to simplify Helm templating. Kubernetes resources require translation to kebab-case as they do not support uppercase. Package naming for Kubernetes resources should be consistent across all resources (e.g., GitRepository, Namespace, HelmRelease, and/or labels).
 
 ##### Notable Exceptions
 > If a package name is two words and the additional words are less than four characters, consider it as part of the single name. Examples include "fluentbit" (technically "Fluent Bit") and "argocd" (technically "Argo CD").
@@ -12,17 +12,17 @@ When creating package names, consider that different usages of the name will req
 ## Formatting YAML
 When formatting YAML files, follow these guidelines:
 
-- Indent using two spaces, not tabs.
-- Use camelCase and alphanumeric keys, without any special characters.
-- Ensure that all Kubernetes resource names, repository names, and namespaces are lowercase, alphanumeric, or hyphenated, using kebab-case.
+* Indent using two spaces, not tabs.
+* Use camelCase and alphanumeric keys, without any special characters.
+* Ensure that all Kubernetes resource names, repository names, and namespaces are lowercase, alphanumeric, or hyphenated, using kebab-case.
 
 ## Structure Standardization
 For each package, ensure that the following items have the same name:
 
-- Folder: chart/templates/<package\>
-- Top-level key: chart/templates/values.yaml
-- Namespace: chart/templates/<package\>/namespace.yaml, unless targeting another package's namespace.
-- Repo name: https://repo1.dso.mil/bigbang/packages/<package\>
+* Folder: chart/templates/<package\>
+* Top-level key: chart/templates/values.yaml
+* Namespace: chart/templates/<package\>/namespace.yaml, unless targeting another package's namespace.
+* Repo name: https://repo1.dso.mil/bigbang/packages/<package\>
 
 
 ##

docs/guides/using-bigbang/testing-deployments.md

@@ -6,13 +6,13 @@
 3. [Resources](#resources)
  
 ## Introduction
-Big Bang leverages a sub-chart called Gluon to perform both scripted and UI tests of deployed applications.  This guide is designed to describe the basics of the UI testing portion of Gluon and how it can be extended to suit your needs.
+Big Bang leverages a sub-chart called Gluon to perform both scripted and User Interface (UI) tests of deployed applications.  This guide is designed to describe the basics of the UI testing portion of Gluon and how it can be extended to suit your needs.
 
 The UI testing is performed via a container running Cypress and can be enabled on a per-package level by setting the value of bbtests.enabled to true.  Be sure to review the values for each package as there may be additional settings related to the Cypress test under the bbtests.cypress section.  With the correct values in place, you can run a test by specifying the following command:
 
 `helm test kiali-kiali -n bigbang`
     
-    > Note: You can run the following command to grab the proper names for each helm chart deployed in Big Bang: "helm list -n bigbang"
+    > **NOTE:** You can run the following command to grab the proper names for each helm chart deployed in Big Bang: "helm list -n bigbang."
 
 Upon running the command, a new pod will be created in the same namespace as the package.  This pod will install Cypress, download a Cypress configuration file, download a file that contains custom Cypress commands, and run any available tests.  In order for the Cypress pod to run successfully, it needs to have external access to the internet and any resources it is attempting to reach out to for testing.  This communication should be allowed by default. You may also need to add exceptions if using Kyverno or Gatekeeper within Big Bang.  Links to these exceptions required can be found below in the Resources section.  
  
@@ -26,6 +26,7 @@ Additionally, test isolation has been disabled by default within Big Bang's impl
 The above command can be executed either at the beginning to ensure a clean session or at the end of any given test to ensure everything is clean before the next test.
  
 ## Extending Cypress Tests
+
 If the default provided Cypress tests are not enough for your installation of Big Bang, there are two options available to extend the behaviour to suit your needs:
  
 ### Option 1: Augment Default Tests with Custom Cypress Tests
@@ -132,4 +133,4 @@ kubectl kustomize ../bigbang
 [In Depth BB Test Documentation](https://repo1.dso.mil/big-bang/product/packages/gluon/-/blob/master/docs/bb-tests.md?ref_type=heads)
 [Kyverno Exceptions for Cypress](https://repo1.dso.mil/big-bang/bigbang/-/blob/master/chart/templates/kyverno-policies/values.yaml)
 [Gatekeeper Exceptions for Cypress](https://repo1.dso.mil/big-bang/bigbang/-/blob/master/chart/templates/gatekeeper/values.yaml)
-[Cypress Environment Variables](https://docs.cypress.io/guides/guides/environment-variables#Option-4---env)
\ No newline at end of file
+[Cypress Environment Variables](https://docs.cypress.io/guides/guides/environment-variables#Option-4---env)

docs/guides/using-bigbang/upgrading-bigbang.md

 # Upgrading Big Bang
 
 ## Before Upgrading
-Before upgrading Big Bang please first check the Release Notes and the Changelog to look for any notes that apply to Big Bang Updates and Package Updates.
+Before upgrading Big Bang, please first check the Release Notes and the Changelog to look for any notes that apply to Big Bang Updates and Package Updates.
 
-Two important things to review when upgrading:
-- "Upgrade Notices" in the Big Bang release notes: 
+There are two important things to review when upgrading:
+1. "Upgrade Notices" in the Big Bang release notes: 
   - These capture any critical notes that the Big Bang development team identified during the release process. 
     - This may be an update to Flux which requires a "manual" application, or a change to a specific package that we deem important to include.
-- Changelog entries for individual packages that you are deploying: 
+2. Changelog entries for individual packages that you are deploying: 
   - Oftentimes individual packages could have breaking changes depending on your configuration. 
   - It is important to review the changes included with those packages and determine if your configuration needs to be adjusted as a result.
 
 ## Supported Upgrades
-Generally we expect upgrades to be done one minor release at a time.  If necessary, it is possible to jump past several versions provided there is careful review of the release notes in between the versions and there are no problems.
+Generally, we expect upgrades to be done one minor release at a time.  If necessary, it is possible to jump past several versions provided there is careful review of the release notes in between the versions and there are no problems.
 
 NOTE: It is recommended that upgrades first be tested in a staging environment that mirrors the production environment so that errors are caught early.
 
@@ -65,10 +65,10 @@ resources:
 ```
 
 ## Verifying the Upgrade
-After upgrading the cluster there are some places to look to verify that the upgrade was completed successfully.
+After upgrading the cluster, there are some places to look to verify that the upgrade was completed successfully.
 
 ### Verify Helm releases 
- - Verify all the helm releases have succeeded
+Verify all the helm releases have succeeded
    
    If everything has updated successfully you should see `Release reconciliation succeeded` as the status for each HelmRelease.
 ```bash
@@ -81,9 +81,9 @@ bigbang     istio             5h1m   True    Release reconciliation succeeded
 ```
 
 ### Verify Pods
- - Verify that there are all pods are either `Running` or `Completed`
- - Look for any pods that recently restarted (crashing recently)
-   - Below see an example of a pod that has restarted multiple times in a short time
+ - Verify that there are all pods are either `Running` or `Completed.`
+ - Look for any pods that recently restarted (crashing recently).
+   - Below see an example of a pod that has restarted multiple times in a short time.
 ```bash
 ❯ k get pod -A
 NAMESPACE           NAME                                                        READY   STATUS    RESTARTS   AGE
@@ -93,7 +93,7 @@ monitoring          alertmanager-monitoring-monitoring-kube-alertmanager-0
 ```
 
 ### Verify Image Versions for Specific Packages
- - Check for specific package versions (image version on pods)
+ - Check for specific package versions (image version on pods).
    - There may be cases where you are hoping to use new features in a new package version, as such it can be beneficial to validate that package did update to the new version as expected.
    - It can also be important to validate Istio sidecar versions, especially for packages outside of Big Bang core/addons. See an example of checking the image version of the running pod below:
 ```bash
@@ -118,6 +118,6 @@ status:
    - It is important to validate those specific applications/features are functioning as expected post-upgrade.
 
 ## Upgrade Troubleshooting
-Oftentimes a good place to start with troubleshooting is to identify which package had issues upgrading. After identifying the package that had problems it can be helpful to re-review the release notes and changelog for that specific package to see if any changes were missed that may have caused the upgrade issue you ran into.
+Usually, a good place to start with troubleshooting is to identify which package had issues upgrading. After identifying the package that had problems it can be helpful to re-review the release notes and changelog for that specific package to see if any changes were missed that may have caused the upgrade issue you ran into.
 
 Specific troubleshooting steps for common issues will be added here in the future.

docs/guides/using-bigbang/values-guide.md

@@ -12,7 +12,7 @@ Big Bang is a slight variation from the typical "umbrella" helm chart pattern. I
 
 The variables in Big Bang's `values.yaml` file are either passed to Flux or Helm depending on the deployment methodology. Values specific to individual packages will be passed to Flux and used to deploy the package itself. Technically speaking, when you deploy Big Bang you are deploying a number of Flux objects and Flux does the heavy lifting to deploy the actual applications. For more information on Flux, see its official [documentation](https://fluxcd.io/docs/components/).
 
-A high level conceptual graph of how values flow through Big Bang is provided below:
+A high level conceptual graph of how values flow through Big Bang is provided in the following:
 
 ```mermaid
 graph TD
@@ -42,7 +42,7 @@ Variables defined in Big Bang's [values.yaml](../../../chart/values.yaml) are va
 
 ### Big Bang Configuration Values
 
-There are a number of values in the Big Bang chart that are solely used for configuration of the Big Bang chart itself. Typically these values are used for the Flux templates (HelmRelease, GitRepository) or for secrets (registry credentials, git credentials).
+There are a number of values in the Big Bang chart that are solely used for configuration of the Big Bang chart itself. Typically these values are used for the Flux templates (e.g., HelmRelease and/or GitRepository) or for secrets (e.g., registry credentials and/or git credentials).
 
 Some examples of these values include:
 - `registryCredentials`: Used to configure the image pull secrets for every namespace
@@ -55,14 +55,14 @@ Some examples of these values include:
 
 Global values within Big Bang are used in cases where packages inherit a common configuration. These mainly include configuration for networking, common SSO provider config, and other common usability values.
 
-Some examples of these values include:
+Some examples of these values are included in the following:
 - `domain`: This value informs the VirtualService configurations for all packages
 - `openshift`: This toggle provides for configuration of any OpenShift specific values across all packages
 - `networkPolicies`: These values inform configuration of network policies (enabling, disabling, setting IP ranges)
 - `imagePullPolicy`: When set this value is used to configure all packages (and their pods) with a common pull policy
 - `sso` (top level value): The configuration set here is used to assist with packages' individual OIDC or SAML configuration, such as endpoints
 
-**Important Note**: While we use the term "global" here these values are NOT the exact same as a Helm global value. Helm globals are directly passed to all subcharts. Big Bang globals are in some cases passed directly to the package charts, but in other cases they are manipulated/customized to inform package values.
+**NOTE**: While we use the term "global" here these values are NOT the exact same as a Helm global value. Helm globals are directly passed to all subcharts. Big Bang globals are in some cases passed directly to the package charts, but in other cases they are manipulated/customized to inform package values.
 
 ### Abstracted Package Values
 
@@ -71,8 +71,8 @@ Each package generally has some configuration that is commonly used for a produc
 When these values are set they are passed through to the package itself. In some cases the Big Bang chart provides additional utility by creating any necessary secrets or toggling other values that are needed.
 
 Some examples of these values include:
-- `<package>.database`: Simplified configuration for an external database connection (user, pass, host, port, etc)
-- `<package>.objectStorage`: Similar configuration for external storage (i.e. S3)
+- `<package>.database`: Simplified configuration for an external database connection (e.g., user, pass, host, and/or port)
+- `<package>.objectStorage`: Similar configuration for external storage (i.e., S3)
 - `<package>.sso.client_id`: Specific SSO client ID for the package
 - `<package>.enterprise.license`: Enterprise license for the specific package