-
-
Notifications
You must be signed in to change notification settings - Fork 261
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
feat: add hydra-distributed
chart that creates separate admin and public deploys
#706
base: master
Are you sure you want to change the base?
Conversation
bc3b57c
to
71041f6
Compare
Hi there! |
@Demonsthere Are there any concerns with the additional complexity required to update two charts for Hydra if we fork this one into a new chart? My concern is if there's multiple different charts it gets complicated to keep them all maintained. Maybe we could modularize this chart such that portions can be reused in the distributed version? |
@Demonsthere If it wasn't clear, I'm totally open to doing this. Just looking for guidance to do it in a maintainable way. |
Yeah, sorry it was just a busy week 😅 |
@Demonsthere No worries, thanks for the response, no rush. Configuring the two deployments differently is actually supported in my current implementation by using the new But totally fair, definitely don't want to overcomplicate the chart. I can try making a separate chart. |
71041f6
to
3b54ded
Compare
@Demonsthere I essentially copied the hydra chart (including my changes) to a new Is this in line with what you were thinking? |
hydra-distributed
chart that creates separate admin and public deploys
Adds
hydra-distributed
chart that creates separate deployment objects for the admin and public components. In addition, if auto-scaling is enabled separate HPA objects will be created.Related Issue or Design Document
I was unable to find any related issues, and don't have a design document.
Checklist
If this pull request addresses a security vulnerability,
I confirm that I got approval (please contact [email protected]) from the maintainers to push the changes.
Further comments
The motivation for this change was to enable creating an Istio
RequestAuthentication
policy which applies to only the admin component (since it doesnt have its own auth). In addition, this change makes it possible to scale, configure, and route the admin and public components separately.