-
Notifications
You must be signed in to change notification settings - Fork 325
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
Add helm chart for the federator #1317
Conversation
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.
Some questions, but in general looks good and fine to merge if CI is green.
spec: | ||
type: ClusterIP | ||
ports: | ||
# TODO: Do we name it something else to get the _correct_ SRV record? |
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 don't quite understand this TODO comment. What does the kubernetes port name have to do with SRV records? Naming this port http seems fine to me. Do we use the port name somewhere else?
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.
When we call this port http
, kubernetes will create SRV record as _http._tcp.federator.<namespace>.cluster.local
.
I assume for discovering remote federators, we will rely on an SRV record like _wire-federator._tcp.<domain>
.
So, if we rename this port from http to wire-federator
and configure domain as federator.<namespace>.cluster.local
we will be able to test federation in same kubernetes cluster without having to mess with global DNS records. All of this is obviously not thought through, so I would much rather tackle it later. I will remove this TODO and write this information in some issue in JIRA.
internalPort: 8080 | ||
|
||
resources: | ||
# FUTUREWORK: come up with numbers which didn't appear out of thin air |
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 we can probably leave the resources block entirely empty: resources: {}
.
But I'm also okay to follow the other charts and to make a change for all charts at once regarding resource usage, instead of only for the federator.
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, let's do them all together.
@@ -9,3 +9,4 @@ tags: | |||
team-settings: false | |||
account-pages: false | |||
legalhold: false | |||
federator: false |
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.
Do we want to disable installing this compoent by default, and enable it once the implementation is more "ready"? Or do you want to keep this false also going forward?
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, I was thinking we shouldn't enable it by default at least until it is useful. Even when it is useful, maybe we shouldn't deploy it when federation is not enabled.
https://wearezeta.atlassian.net/browse/SQCORE-364