-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
charts/turbinia Lock tag by release version, Make ingress more generalized, remove values-production.yaml, README updates, allow multiple instances of Turbinia #167
Conversation
Signed-off-by: wajihyassine <[email protected]>
…astructure into turb-updates5
Signed-off-by: wajihyassine <[email protected]>
Signed-off-by: wajihyassine <[email protected]>
Signed-off-by: wajihyassine <[email protected]>
Signed-off-by: wajihyassine <[email protected]>
Signed-off-by: wajihyassine <[email protected]>
Signed-off-by: wajihyassine <[email protected]>
…e double indentation caused readme-generator to remove content after the table
…astructure into turb-updates5
…e double indentation caused readme-generator to remove content after the table
Signed-off-by: wajihyassine <[email protected]>
Signed-off-by: wajihyassine <[email protected]>
Signed-off-by: wajihyassine <[email protected]>
Signed-off-by: wajihyassine <[email protected]>
Signed-off-by: wajihyassine <[email protected]>
…have in doc, remove deprecated controller, remove config.override
Signed-off-by: wajihyassine <[email protected]>
Signed-off-by: wajihyassine <[email protected]>
Signed-off-by: wajihyassine <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, just a few minor comments.
@@ -1,495 +0,0 @@ | |||
## Turbinia Helm Production Values |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this getting removed to make maintenance easier so we don't have to maintain two versions of this? I don't remember all what is different in this production version, but I do seem to recall there being some parameters that we'd want to use from this in a production install but could be wrong. I'm just wondering if that info will be kept somewhere, or if we should consider keeping a minimal or sparse version of this file with only the differences?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking at this file a bit closer, I think most of the values that would be commonly changed for a production instance are probably pretty obvious, and you already have some comments in the README, so I don't think we would need to keep a minimal or sparse version unless there are some other less obvious differences that are recommended (ie. things outside of VM/resource size or autoscaling), and if there is anything else we could just mention it in the README where you have the other related comments.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes exactly. And it is to make maintenance easier as it's hard to keep track of the changes done in values.yaml
that might also apply to values-production.yaml
and we don't test if the deployment works with the values-production.yaml
file. Yeah really the biggest difference was the resources defined and autoscaling turned on and filestore (which made it GCP specific).
For the second part expanding the README SGTM. Still thinking about this, but in a second pass, was opting to update the README with the recommended production resource values. Then leave any GKE specific steps in the install GKE instructions (like using GCP filestore for shared storage)
charts/turbinia/README.md
Outdated
the Turbinia deployment will automatically retrieve the latest default configs | ||
from the Turbinia Github repository. This method requires no further action from you. | ||
|
||
> **NOTE:** When using the default method, you cannot update the Turbinia config file directly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From what I can tell from the instructions below, you can upgrade the helm chart in an existing installation to be able to use a custom config with the config map, is that right? If so, can we add something to the end of this sentence like "... unless you create a config map and upgrade your Helm chart using the instructions below"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep you can. I added "See the next section for instructions on using a custom Turbinia config instead." to make it more clear that there is another option
1. Update the ConfigMap: | ||
|
||
```console | ||
kubectl create configmap turbinia-configs --from-file=turbinia.conf --dry-run -o yaml | kubectl replace -f - |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think --dry-run
might need to be removed here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noo it's because without --dry-run
it will complain that the configmap exists and there isn't any direct update
you can use so you re-create the yaml file with the --dry-run and replace the ConfigMap file containing the turbina config. A little convoluted.. yes
charts/turbinia/README.md
Outdated
@@ -126,14 +279,14 @@ OAuth client. | |||
kubectl create secret generic authenticated-emails --from-file=authenticated-emails-list=authenticated-emails.txt | |||
``` | |||
|
|||
8. Then to upgrade an existing release with production values, externally expose | |||
Turbinia through a load balancer with GCP managed certificates, and deploy the | |||
8. Then to upgrade an existing, externally expose Turbinia through a load balancer with GCP managed certificates, and deploy the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
s/existing/existing release/ ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nice catch, updated
charts/turbinia/README.md
Outdated
@@ -146,52 +299,14 @@ Oauth2 Proxy for authentication, run: | |||
plan to expose Turbinia with a public facing IP, it is highly recommended that | |||
the Oauth2 Proxy is deployed alongside with the command provided above. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this is unchanged from the previous version and should be obvious, but maybe we want to make this statement even stronger by adding something like "... otherwise Turbinia will be accessible from anyone on the internet without authentication"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah good call out that should be made as clear as possible. I've updated to match that language
Description of the change
kube-prometheus
from sub dependency as this should remain a seperate steps/so we don't have to download the charts even when not using itApplicable issues
Checklist
Chart.yaml
according to semver. This is not necessary when the changes only affect README.md files.