Config Validator requires a policy-library present in the local file system in order to start. The config-validator chart, by default, pulls in the example policy-library from the base repo. This repo is synced once by git-sync in an initContainer so that the policy-library is available to the config-validator container when the pod starts. git-sync is deployed as a container in the pod to periodically sync from the repository, and, if a change is detected, automatically restart the pod.
GCS is another option for policy-library storage. This option is available for Forseti on-GCE.
Helm advocates a run-as-is paradigm. The chart ought deploy pods to a READY state with just the defaults. This means the pods must deploy to a READY state if a GCS bucket is not specified.
Proposed Solution
By default (from Helm's perspective), an empty policy-library will be mounted to the pod so that the config-validator will start
If the user specifies policyLibrary.bucket
The gsutil initContainer will pull down the library once and stage it for the config-validator container
There will be no periodic sync. Without additional logic, the gsutil will not be able to determine a diff between files and restart the pod.
If the user specifies a policyLibrary.repositoryURL
git-sync will be deployed in an initContainer to pull the library from a Git repo once.
If the gitSync.enabled variable is set to true the git-sync will be deployed as a container in the pod to pull the repo periodically.
If the gitSync.enabled variable is set to false, then the git-sync pod will not be deployed as a container in the pod.
If a policyLibrary.gitSync.privateSSHKey is provided, then git-sync will pull the Git repository over SSH.
Acceptance Criteria
Config Validator deploys with pods to a READY state with default chart values.
If a bucket is provided then the repo will be pulled down with gsutil
If a repository string is provided, git-sync will be used
If the gitSync variable is true, then git-sync will be deployed as container in the pod. Changing a file in the Git repo causes the pod to restart. If false, then it won't.
kevensen
commented
4 years ago
Story
Config Validator requires a policy-library present in the local file system in order to start. The config-validator chart, by default, pulls in the example policy-library from the base repo. This repo is synced once by git-sync in an initContainer so that the policy-library is available to the config-validator container when the pod starts. git-sync is deployed as a container in the pod to periodically sync from the repository, and, if a change is detected, automatically restart the pod.
GCS is another option for policy-library storage. This option is available for Forseti on-GCE.
Helm advocates a run-as-is paradigm. The chart ought deploy pods to a READY state with just the defaults. This means the pods must deploy to a READY state if a GCS bucket is not specified.
Proposed Solution
By default (from Helm's perspective), an empty policy-library will be mounted to the pod so that the config-validator will start
If the user specifies policyLibrary.bucket
If the user specifies a policyLibrary.repositoryURL
git-sync will be deployed in an initContainer to pull the library from a Git repo once.
If the gitSync.enabled variable is set to true the git-sync will be deployed as a container in the pod to pull the repo periodically.
If the gitSync.enabled variable is set to false, then the git-sync pod will not be deployed as a container in the pod.
If a policyLibrary.gitSync.privateSSHKey is provided, then git-sync will pull the Git repository over SSH.
Acceptance Criteria