optionally create a router when deploying the controller

[qrkourier]

It's highly likely that a controller deployment is immediately followed by a router deployment. We can simplify and facilitate this by automatically provisioning a router in the Ziti mgmt API and storing the token as a K8s secret.

The implementation will involve Helm hooks and simple shell scripts to be executed by the resulting Job resources that are scheduled during life cycle events.

[qrkourier]

The first change is for the controller chart to create the router in Ziti, but the router chart can also be improved as part of this. It can accept a new value that is the name of the existing K8s secret where the token is saved. That way it's unnecessary to fetch the token and feed it to the router chart.

[qrkourier]

The point of this issue is to simplify the process of getting a Ziti network running in K8s by eliminating these orchestration steps:

1. fetch Ziti admin password
2. login to Ziti
3. create router and save token
4. fetch token
5. supply token to router chart

[dariuszSki]

yes, if the router will be deployed on the same cluster, then I would make sense to add an option to create a router if needed

[qrkourier]

I'm still planning to work on this soon.

[qrkourier]

This is still needed to support a more compact deployment scenario where a default router makes sense.

[qrkourier]

I'm clawing my way back to this and still think it's an obvious way to simplify k8s bootstrapping.

[qrkourier]

This avoids Terraforming/Ansible the mgmt API to create the router and is relevant to the "ziti-stack" chart idea (umbrella chart for controller+cert-manager+trust-manager+router w/ optional node proxy daemonset, sidecar injector, etc.)