Documentation/formatting

See merge request platform-one/big-bang/charter!39

Signed-off-by: Jason Krause <8408603+jasonpatrickellykrause@users.noreply.github.com>

Signed-off-by: Jason Krause <8408603+jasonpatrickellykrause@users.noreply.github.com>

Dns url updates

See merge request platform-one/big-bang/charter!35

BB-1082 - Update Umbrella Charter with finalized CI / workflow content and diagrams

See merge request platform-one/big-bang/charter!34

Adds vendor distro docs

See merge request platform-one/big-bang/charter!32

Update charter with package pipeline info

See merge request platform-one/big-bang/charter!30

Packagestandard

See merge request platform-one/big-bang/charter!22

# Conflicts:
#   PackageRequirements.md

Update with helm standards

See merge request platform-one/big-bang/charter!28

Addons

See merge request platform-one/big-bang/charter!25

# argo shortcomings:

See merge request platform-one/big-bang/charter!24

Quality of Service for Pods

See merge request platform-one/big-bang/charter!23

Outline Understudies

See merge request platform-one/big-bang/charter!16

- the big bang product's charter and sole purpose is deploy and configure a suite of applications that work in tandem to quickly and stamp out dsop compliant infrastructure running on k8s clusters
    - this is most easily done by consuming tried, tested, production ready deployments of community maintained helm charts, with *light* modifications needed for P1 specific integrations

## Big Bang use of Helm:
- Helm is the preferred templating solution for packages that need to be delivered and customizable for customers in a supported way in the community
- Vendors provide and **support** Helm charts for their applications for the same reason:
  - Confluent
- Even vendors that create operators for managing lifecycles of an individual instance of their applications provide Helm charts for the deployment and configuration of the operator and CRs **in an easy to configure, hard to mess up way**
- Kustomize as the primary interface for consumption of BigBang provides too many nobs for end users to turn and expect end users understand too much about how the manifests are created to ensure they are easily able to provide configuration (e.g. domain names, certs, ImagePullSecrets). 
- for an "on rails" orchestrated deployment of multiple packages (the heart of BigBang) meant to play in tandem with each other, a pure kustomize approach has too many options and requires end users to understand how to re-configure packages when other packages are/are not present
Conclusion:
- Our delivery solution needs to support Helm

## Argo does not support Helm
- Argo does not support Helm as a first class citizen, leading to issues in how Helm charts are managed:
    - Argo Shims features to Argo capabilities, often leading to errors in deployment:
        - Deletion of WebHooks (GitLab Issue)
        - Lack of hooks in Argo cause issues in conversion of both Install and Upgrade Helm WebHook to one Argo Hook, causing issues in:
            - gitlab: initial secret creation is performed via a [subchart]([https://gitlab.com/gitlab-org/charts/gitlab/-/tree/master/charts/shared-secrets](https://gitlab.com/gitlab-org/charts/gitlab/-/tree/master/charts/shared-secrets))
            - kube-prometheus-stack: [prometheusrule admission webhook]([https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack#prometheusrules-admission-webhooks](https://github.com/prometheus-community/helm-charts/tree/main/charts/kube-prometheus-stack#prometheusrules-admission-webhooks)) is created via a helm `install` hook
            - Confluent Chart
    - As Helm features continue to improve, Argo will always have to implement a shim to an argo feature (and maybe develop the feature) and we will rely on the Argo developers to correctly port the features.
    - 

## Secret Management

- secret management within argocd requires custom solutions:
    - harbor: helm install with external database requires plaintext database password to be provided [here]([https://github.com/goharbor/harbor-helm/blob/master/values.yaml#L686](https://github.com/goharbor/harbor-helm/blob/master/values.yaml#L686)).  Workaround of a custom helm secrets plugin and/or kustomize —> secrets 
- umbrella: chart values are passed as `values` in the `Application` CR, which is rendered as a single yaml string (not a yaml map), which means any secrets provided to charts is exposed as plaintext in the `Application` CR, and environment specific overlays are not possible without custom solutions (such as object deep merging within the helm template lifecycle)


## Notes

- not really helm but a helm shim, reliant on argocd maintainers to keep the necessary logic in sync with how helm evolves
- 
    - this includes operator based deployments, while the operator is responsible for managing the lifecycle of the application, helm is responsible for templating the custom resources the operator deploys 
        - other choices such as kustomize are a great way of overriding CR based operator deployments, but it provides too many options and entrypoints for users consuming the manifests to mess up, and completely eliminates any sort of guard rails the distributor puts on the deployment methods

- while it has it's flaws, helm is the defacto community accepted standard for being the "kubernetes package 
- most community maintained helm charts have adopted `helm hooks` as standard for ensuring lifecycle specific logic is properly handled in the helm chart rollout
manager".  it is important that the gitops engine of choice supports helm as a *first class citizen*