Skip to content

Conversation

@rios0rios0
Copy link
Contributor

No description provided.

… allow list for desired IPs be allowed and rest blocked

Signed-off-by: Felipe Rios <[email protected]>
@rios0rios0 rios0rios0 requested a review from a team as a code owner November 28, 2024 20:56
@rios0rios0
Copy link
Contributor Author

Is anyone available to review? @nscuro?

@nscuro
Copy link
Member

nscuro commented Dec 10, 2024

Is there a way to support such customization without eventually copying the entire Service spec into our Helm chart? i.e. can we accept a generic object instead and embed it into the Service manifests somehow?

@rios0rios0
Copy link
Contributor Author

Is there a way to support such customization without eventually copying the entire Service spec into our Helm chart? i.e. can we accept a generic object instead and embed it into the Service manifests somehow?

Sorry, I was just following the standard the community is following for helm charts and those kind of customization (SonarQube for example: https://github.com/SonarSource/helm-chart-sonarqube/blob/master/charts/sonarqube/values.yaml#L104). But I do agree with you that it seems to be duplicating. The only way I can think of improving that, would be passing the responsibility of creating the service code to the user who is using the chart. Like:

 {{- if .Values.apiServer.enabled }}
   {{- with .Values.apiServer.service }}
   {{- toYaml . | nindent 0 }}
   {{- end }}
 {{- end }}

Although, it's not that beautiful, and it does complicate the things in Terraform for example, which is the way I'm using this chart.

What are your thoughts on that?

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.

2 participants