You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be beneficial having a stack Helm chart which configures the complete OpenZiti stack at once instead of defining every Helm release separately.
This is the best approach which would simplify the deployment massively. One could define a chart Meta-Version which define a version bundle for ziti-console, ziti-controller, ziti-router which can be tested to be working well together, similar to what kube-prometheus-stack does for a prometheus environment.
The text was updated successfully, but these errors were encountered:
It's a good idea. When the controller is deployed, it's related to optionally creating a router entity in the Ziti API in the controller chart. That way, a router deployment can use the enrollment token stored in a secret.
A ziti-stack chart could start as an umbrella chart for the controller and first router, possibly N routers.
The next major iteration would be to let the ziti-stack chart deploy a future Ziti operator which could subsequently deploy HA controllers and N routers.
Hi @qrkourier,
It would be beneficial having a stack Helm chart which configures the complete OpenZiti stack at once instead of defining every Helm release separately.
This is the best approach which would simplify the deployment massively. One could define a chart Meta-Version which define a version bundle for ziti-console, ziti-controller, ziti-router which can be tested to be working well together, similar to what
kube-prometheus-stack
does for a prometheus environment.The text was updated successfully, but these errors were encountered: