Conversation
|
Isn't a better approach to not deploy anything related to admin when Similarly, the backup, cluster-conf job and related resources are not necessary, since there is no connection between the runtime nodes and also there is no interface for confiugration changes to trigger a backup. finally, the ingress resource should also if enabled, not configure a route for the admin, if onlyRuntimes is true |
|
True. That make sense. |
|
I put this into draft. I question if it is a good idea to have this in the charts? It will add some complexity and maybe it is not needed at all. If you want to deploy only runtime nodes you might as well use the manifest files anyway since it will be only deployment, service and ingress. Thus, If it will not be used there is no need for it. |
# Conflicts: # idsvr/README.md # idsvr/templates/cluster-conf.yaml # idsvr/templates/config-backup.yaml # idsvr/templates/deployment-admin.yaml # idsvr/templates/deployment-runtime.yaml # idsvr/templates/ingress.yaml # idsvr/templates/network.yaml # idsvr/templates/rbac.yaml # idsvr/templates/service-admin.yaml
|
I opened this again. Since we are able to now convert keystores during startup it really make sense to also be able to use the Helm charts for production using only runtime nodes. I also implemented your suggestion above and now Helm will only create manifest files that are needed. |
|
Sorry. I deleted the branch unintentionally. |
|
This PR needs a little bit more love @bokristoffersson . Also can you document the curity.onlyRuntimeNodes setting in the readme ? |
|
Will be solved when #114 is merged |
When running in production we are investigating in running without an admin server since no configuration changes are to be made outside of gitops configuration.