-
Notifications
You must be signed in to change notification settings - Fork 13
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
kubernetes and gitops docs updates #2888
Conversation
Please update: https://docs.calitp.org/data-infra/kubernetes/deployment.html (turn into Mermaid diagram) |
|
||
pr -- Yes --> candidates_branch -- "Open PR from candidates/branch-name to releases/test" --> branch_diff -- "Merge candidate PR to releases/test" --> branch_invoke -- Merge to main after review and testing --> candidates_main -- "Open PR from candidates/main to releases/prod" --> prod_diff -- "Merge candidate PR to releases/prod" --> prod_invoke | ||
pr -- "No; merge to main after review" --> candidates_main | ||
``` |
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 guess this may be obvious but is it helpful to make some kind of distinction (maybe bullets below or perhaps could change shapes in the mermaid diagram) between code changes and deployments? I.e., merging PRs to main changes code but the GH actions deploy. So if you don't merge candidates/main
at the end, you will have changed the main codebase but won't have deployed those changes and they won't run anywhere, right?
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.
So like, regardless of the test branch situation, you only ever merge your core code changes once right? From your normal git branch to main? But the candidate branch stuff is to deploy changes, either for testing or for real?
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.
Correct, yes. I think I addressed this with a clarification
### Secrets | ||
Because we use [Github OAuth](https://zero-to-jupyterhub.readthedocs.io/en/latest/administrator/authentication.html?highlight=oauth#github) for user authentication in JupyterHub, we have to provide a client-id and client-secret to the JupyterHub Helm chart. Here is what the full configuration for the GitHub OAuth in our JupyterHub Helm chart's `values.yaml` might look like: | ||
|
||
```yaml |
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.
did you want to replace this with a link to the real file?
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 no, because technically this is the entire values.yaml structure that we split into 2 places
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.
Oops I thought I did this a few days ago
Actually this isn't easily fixable, but I've addressed other things that have come up. |
Description
Removes some outdated/unnecessary docs around k8s/infra, cleans up what remains, and combines into READMEs in the appropriate folders. Also fixes the wrong readme showing for the repo.
Ran through some stuff with @evansiroky today; we're going to walk through a Metabase restore at some point to test the backups documentation.
Type of change
How has this been tested?
TODO: run through backup restoration process with @evansiroky
Post-merge follow-ups