Skip to content
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

Merged
merged 45 commits into from
Sep 27, 2024

Conversation

wajihyassine
Copy link
Member

@wajihyassine wajihyassine commented Sep 17, 2024

Description of the change

  • Allow for multiple instantiations of Turbinia on the same cluster by fixing parts of Helm code to name more resources with the Release name
  • Remove deprecated Turbinia controller
  • Clean up Ingress specification to allow it to be generalized to other environments (dont make host or IP required)
  • Remove 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 it
  • Lock tag by release version
  • README updates adding instructions on how to update the image tag, upgrading helm chart, moving sections around

Applicable issues

Checklist

  • Chart version bumped in Chart.yaml according to semver. This is not necessary when the changes only affect README.md files.
  • Newly added variables are documented in the values.yaml
  • Title of the pull request is descriptive

wajihyassine and others added 30 commits September 17, 2024 09:26
…e double indentation caused readme-generator to remove content after the table
…e double indentation caused readme-generator to remove content after the table
@wajihyassine wajihyassine self-assigned this Sep 23, 2024
@wajihyassine wajihyassine changed the title Remove values-production.yaml, update servicemonitor, documentation f… charts/turbinia Remove values-production.yaml, update servicemonitor, documentation updates, allow multiple instances of Turbinia Sep 23, 2024
@wajihyassine wajihyassine changed the title charts/turbinia Remove values-production.yaml, update servicemonitor, documentation updates, allow multiple instances of Turbinia charts/turbinia Make ingress more generalized, remove values-production.yaml, update servicemonitor, documentation updates, allow multiple instances of Turbinia Sep 24, 2024
@wajihyassine wajihyassine changed the title charts/turbinia Make ingress more generalized, remove values-production.yaml, update servicemonitor, documentation updates, allow multiple instances of Turbinia charts/turbinia Lock tag by release version, Make ingress more generalized, remove values-production.yaml, update servicemonitor, documentation updates, allow multiple instances of Turbinia Sep 24, 2024
@wajihyassine wajihyassine changed the title charts/turbinia Lock tag by release version, Make ingress more generalized, remove values-production.yaml, update servicemonitor, documentation updates, allow multiple instances of Turbinia charts/turbinia Lock tag by release version, Make ingress more generalized, remove values-production.yaml, README updates, allow multiple instances of Turbinia Sep 24, 2024
@wajihyassine wajihyassine marked this pull request as ready for review September 24, 2024 23:08
@wajihyassine wajihyassine requested review from aarontp and removed request for hacktobeer September 27, 2024 18:02
Copy link
Member

@aarontp aarontp left a 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
Copy link
Member

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?

Copy link
Member

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.

Copy link
Member Author

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)

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.
Copy link
Member

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"?

Copy link
Member Author

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 -
Copy link
Member

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?

Copy link
Member Author

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

@@ -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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/existing/existing release/ ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice catch, updated

@@ -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.
Copy link
Member

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"?

Copy link
Member Author

@wajihyassine wajihyassine Sep 27, 2024

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

@wajihyassine wajihyassine merged commit 4965d07 into main Sep 27, 2024
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Quality of life updates to OSDFIR Infrastructure charts
2 participants