1. Use --spring.config.additional-location to specify Spring application config
   so the default application.yaml bundled in the jar can be used, and users
   only need to override required config. This is to prevent chart users being
   overwhelmed by the amount of config to set.

2. Use less templating, if else, and functions in configmap.yaml in Feast
   charts. Instead set a reasonable default and allow users to override
   in application-override.yaml. This makes it easier to manage when
   application.yaml structure changes and documentation for application.yaml
   can be delegated to:
   https://github.com/gojek/feast/blob/master/core/src/main/resources/application.yml
   https://github.com/gojek/feast/blob/master/serving/src/main/resources/application.yml

3. Remove double nesting of charts. Previously, Postgresql and Kafka subcharts
   are bundled in Feast Core suchart. Now all 3 subcharts are sibling charts.
   This reduces coupling between charts and it's easier to configure chart
   values one at a time than one big values yaml. Also, documentation for
   third party subcharts can be delegated to the original authors.

4. Use helm-docs to generate README for Feast charts so the documentation
   is reproducible and easier to keep up to date when values.yaml changes.
   It is also easier to follow best practices when writing values.yaml.
   https://github.com/norwoodj/helm-docs

5. Add prometheus and grafana charts to support out of the box metrics
   collector and visualization when users install Feast with this chart.

6. Add tests for users to verify installation:

7. Add examples to install Feast with 3 different profiles:
   - online serving only with direct runner
   - online and batch serving with DirectRunner
   - online and batch serving with DataflowRunner

helm-docs look for it in repo root folder

Incorrectly swapped resources requests and limit

…resql.existingSecret, use JAVA_TOOL_OPTIONS instead of JAVA_OPTS

- Also adjust CPU request and memory limit for test pods to fit the actual usage

… v0.4

…d Serving

- application.yaml: default application.yaml bundled in the jar
- application-generated.yaml: additional config generated by Helm that is valid when the dependencies like Postgres, Kafka and Redis are installed with default config
- application-secret.yaml: config to override default and Helm generated config
- application-override.yaml: same as application-secret.yaml but config is created as ConfigMap vs Secret and has a higher precendence than application-secret.yaml

…works with latest Kubernetes version

…cret

So that deployment will be updated when configmap and secret are updated

…cumentation for .Values.gcpProjectId