Merge branch 'master' into feat/gpe-1316

README.md

@@ -14,20 +14,9 @@ helm repo update
 helm upgrade --install gen3 gen3/gen3 -f ./values.yaml 
 ```
 
-Assuming you already have the [prerequisites](./docs/PREREQUISITES.md) installed and configured, you can deploy Gen3 with the helm command.
+For more information on how to deploy Gen3 with helm, please see the [Gen3 Example Deployment Guide](https://docs.gen3.org/docs/Deployment/Example%20Deployment)
 
-
-> **Warning**
-> The default Helm chart configuration is not intended for production. The default chart creates a proof of concept (PoC) implementation where all Gen3 services are deployed in the cluster, including postgres and elasticsearch. For production deployments, you must follow the [Production/Cloud Native/Hybrid architecture](./docs/PRODUCTION.md)
-
-
-For a production deployment, you should have strong working knowledge of Kubernetes. This method of deployment has different management, observability, and concepts than traditional deployments.
-
-In a production deployment:
-
-- The stateful components, like PostgreSQL or Elasticsearch, must run outside the cluster on PaaS or compute instances. This configuration is required to scale and reliably service the variety of workloads found in production Gen3 environments.
-
-- You should use Cloud PaaS for PostgreSQL, Elasticsearch, and object storage.
+https://docs.gen3.org
 
 
 ## Configuration
@@ -39,7 +28,7 @@ There's also an auto-generated table of basic configuration options here:
 [README.md for gen3 chart](./helm/gen3/README.md) (auto-generated documentation) or 
 
 
-To see documentation around setting up gen3 developer environments see [gen3_developer_environments.md](./docs/gen3_developer_environments.md)
+To see documentation around setting up gen3 developer environments see [our Example Deployment](https://docs.gen3.org/docs/Deployment/Example%20Deployment/).
 
 
 Use the following as a template for your `values.yaml` file for a minimum deployment of gen3 using these helm charts.
@@ -56,23 +45,6 @@ fence:
 ```
 
 
-
-## Selective deployments 
-All gen3 services are sub-charts of the gen3 chart (which acts as an umbrella chart). 
-
-For your specific installation of gen3, you may not require all our services.
-
-
-To enable or disable a service you can use this pattern in your `values.yaml`
-
-```yaml
-fence:
-  enabled: true
-
-wts:
-  enabled: false
-```
-
 ## Gen3 Login Options
 Gen3 does not have any IDP, but can integrate with many. We will cover Google login here, but refer to the fence documentation for additional options. 
 
@@ -108,39 +80,6 @@ For `"Authorized redirect URIs"` add  `https://<hostname>/user/login/google/logi
 
 After configuration is complete, take note of the client ID that was created. You will need the client ID and client secret to complete the next steps. 
 
-# Production deployments
-Please read [this](./docs/PRODUCTION.md) for more details on production deployments. 
-
-NOTE: Gen3 helm charts are currently not used in production by CTDS, but we are aiming to do that soon and will have additional documentation on that.
-
-# Local Development
-
-For local development you must be connected to a kubernetes cluster. As referenced above in the section `Kubernetes cluster` we recommend using [Rancher Desktop](https://rancherdesktop.io/) as Kubernetes on your local machine, especially on M1 Mac's. You also get ingress and other benefits out of the box.
-
-For MacOS users, [Minikube](https://minikube.sigs.k8s.io/docs/start/) equipped with the ingress addon serves as a viable alternative to Rancher Desktop. On Linux, we've observed that using [Kind](https://kind.sigs.k8s.io/) with an NGINX ingress installed often provides a more seamless experience compared to both Rancher Desktop and Minikube. Essentially, Helm requires access to a Kubernetes cluster with ingress capabilities, facilitating the loading of the portal in your browser for an optimal development workflow.
-
-To install the NGINX ingress: 
-```
-  helm repo add nginx-stable https://helm.nginx.com/stable
-  helm repo update
-  kubectl create ns nginx-ingress
-  helm install nginx-ingress nginx-stable/nginx-ingress --namespace nginx-ingress 
-```
-
-> **Warning**
-> If you are using Rancher Desktop you need to increase the vm.max_map_count as outlined [here](https://docs.rancherdesktop.io/how-to-guides/increasing-open-file-limit/)
-> If you are using Minikube you will need to enabled the ingress addon as outlined [here](https://kubernetes.io/docs/tasks/access-application-cluster/ingress-minikube/)
-
-1. Clone the repository
-2. Navigate to the `gen3-helm/helm/gen3` directory and run `helm dependency update`
-3. Navigate to the back to the `gen3-helm` directory and create your values.yaml file. See the `TL;DR` section for a minimal example.
-4. Run `helm upgrade --install gen3 ./helm/gen3 -f ./values.yaml`
-
-## Using Skaffold
-
-Skaffold is a tool for local development that can be used to automatically rebuild and redeploy your application when changes are detected. A minimal skaffold.yaml configuration file has been provided in the gen3-helm directory. Update the values of this file to match your needs.
-
-Follow the steps above, but instead of doing the helm upgrade --install step, use `skaffold dev` to start the development process. Skaffold will automatically build and deploy your application to your kubernetes cluster. 
 
 # Troubleshooting
 

docs/INGRESS.md

@@ -1,7 +1,7 @@
 # Ingress in Gen3
 
 # Dev
-if `global.dev` is set to true, a very basic ingress is created, that works out of the box with `traefik` service that is included in `Rancher-Desktop` 
+if `global.dev` is set to true, a very basic ingress is created.
 
 # AWS
 

docs/PREREQUISITES.md

@@ -24,9 +24,7 @@ Before deploying the Gen3 application using Helm, ensure that the following prer
 ## Prerequisites
 
 ### Kubernetes cluster
-Any kubernetes cluster _should_ work. We are testing with EKS, AKS, GKE and Rancher Desktop. 
-
-It is suggested to use [Rancher Desktop](https://rancherdesktop.io/) as Kubernetes on your laptop, especially on M1 Mac's. You also get ingress and other benefits out of the box. 
+Any kubernetes cluster _should_ work. We are testing with EKS, AKS, GKE.
 
 
 ### Postgres 

docs/fence_usersync_job.md

@@ -1,6 +1,6 @@
 # Fence Usersync CronJob
 
-If `.Values.usersync.usersync` is set to true, the Fence usersync-cron.yaml will be deployed to the cluster.
+If `.Values.usersync.usersync` is set to true, the Fence usersync-cron.yaml will be deployed to the cluster, otherwise useryaml job will be deployed instead of usersync.
 
 User lists can be synced from three sources:
 

helm/ambassador/Chart.yaml

@@ -15,7 +15,7 @@ type: application
 # This is the chart version. This version number should be incremented each time you make changes
 # to the chart and its templates, including the app version.
 # Versions are expected to follow Semantic Versioning (https://semver.org/)
-version: 0.1.11
+version: 0.1.12
 
 # This is the version number of the application being deployed. This version number should be
 # incremented each time you make changes to the application. Versions are not expected to
@@ -25,5 +25,5 @@ appVersion: "1.4.2"
 
 dependencies:
 - name: common
-  version: 0.1.10
+  version: 0.1.14
   repository: file://../common