Closed criskurtin closed 9 months ago
Unfortunatly, changing the existing ingress
value to accept list of Ingress objects will not be possible as this would brake the backwards compatibility promisse between major chart versions.
I've added the extraIngress
configuration option in related PR #24 that will be included in 1.2.0 version.
Full feature documentation is available in values.yaml and on website https://kubedeploy.app/start/values/extraingress.html
If you wish to do some early testing, the release candidate version that will include all the 1.2.0 milestone features is available in pre-release repository:
helm repo add sysbee-release https://charts.sysbee.io/release/sysbee
helm repo update
Feel free to re-open this issue if you encounter any errors with extraIngress
config
Currently only single
ingress
object can be defined without using theextraObjects
field and defining raw manifests.ingress
field should be an array instead, in order to natively support defining multiple ingresses.Expected Behavior
Result of this configuration should be two ingress manifests.
Current Behavior
Currently, the
ingress
field does not support specifying an array of objects. Only single ingress object can be specified instead:Possible Solution
ingress.yaml
template should iterate through specified array elements and use the already implemented templating logic to generate individual ingress manifests. Sort of a combination betweenextra-objects.yaml
withrange
function and the existingingress.yaml
template.Context
This would be useful if multiple ingresses should be defined. For example, most of the service endpoints might only be available to the internal network (using the
haproxy
default ingress controller), while the endpoints prefixed with/public
might need to be exposed through thehaproxy-public
ingress controller. At the moment, the solution is a bit clumsy and requires specifying one of the above as a raw manifest.Your Environment