-
Notifications
You must be signed in to change notification settings - Fork 134
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
Helm: have Ingress as configurable option #3570
Comments
Hi @aegershman, I'm current reviewing our open community issues to assess their liveness - I see you opened this one in May - I assume this feature is still relevant to you? Please let me know. Thanks! |
It is, but to be honest it's not a huge priority for me. No worries, will close this out. In general, thanks for helping making Stratos possible👍 |
@aegershman You're welcome. Should this feature become more of a priority in the future please let us know and we can re-open it. And feel free to contact us about anything else you'd like to see in Stratos or any issues you encounter. |
SUSE CAP has had ingress creation via the helm chart since the 1.4 release and it has proved extremely convenient and useful for deployments where Kubernetes-provided load balancers are not available. This will be a requirement for SUSE/stratos downstream (for consistency), so we might as well do this upstream so everyone deploying with Helm can use this. :) |
Ingress as configurable option within chart itself
Similar to how other charts handle Ingress as a configurable option via
ingress.enabled: true/false
, it would be operationally helpful if the helm deployment of Stratos had Ingress as a configuration option included in the chart rather than requiring it to be configured/added on as an external fileContext p1: my personal use-case
As a proof of concept I installed
SUSE/scf
(CF on k8s) as a helm chart & leveraged an Ingress rather than multipleService: LoadBalancer
's. I wanted to leverage Stratos for the UI using the cluster-wide Ingress Controller rather than setting up new DNS entries for the LoadBalancer services that would get generated. I thought about installing Stratos as an app on CF Docker app instead, but sadly I don't think it's possible to run docker images on the k8s CF deployment model yet.Context, p2: general use-case
When deploying helm charts, either manually with the helm-cli or with a declarative helm tool like
helmfile
, it's beneficial to have the deployments be as declarative as possible. Any steps required outside of what can be defined statically makes the deployment "snowflake-y" (hate that term, but whatever).In order to use an Ingress I need to go manually download the
ingress.yml
, which breaks the workflow of:helm repo add stratos https://cloudfoundry-incubator.github.io/stratos helm repo update # setup a stratos-values.yml with all the options you want enabled, including Stratos version + Ingress config and such... helm upgrade stratos/console --install --namespace=console --name my-console --values stratos-values.yml
and means people need to add in manual steps, like maybe having to
wget https://github.com/cloudfoundry-incubator/stratos/blob/v2-master/deploy/kubernetes/ingress/ingress.yml
or something. And even then, since it's not part of the versioned Chart.yml, there's no guarantee that it'll work with the version of Stratos you're using.Possible Implementation
Stealing fromdrawing inspiration from other helm charts on how they do Ingress? e.g. like Concourse or minio or artifactory, etc. I'm by no means a helm expert, so I apologize for opening an issue rather than a PR with the suggested improvement. I can take a crack at it, but someone smarter than I + w/ more context might be more appropriate.Thoughts?
Thanks for your time & consideration 👍
The text was updated successfully, but these errors were encountered: