Easily understood VIP for Kudo frameworks deployed on my cluster

[tbaums]

AA k8s developer, I want an easily understood, consistent VIP for Kudo frameworks deployed on my cluster so that I can easily consume Kudo framework services.

Something like Marathon VIPs would be great.

[runyontr]

@tbaums , I think this would go nicely with a KEP about exporting values from instance for consumption by others:

1. https://github.com/kudobuilder/kudo/blob/master/pkg/apis/kudo/v1alpha1/frameworkversion_types.go#L41 Is not currently implemented, just there as a place holder. It would be great to be able to define how one might export a connection string to that instance. What if there are multiple things to connect to? e.g. Read/write have two different connection strings? UI vs API? etc
2. Secrets: How does one store and export credentials for an Instance? How is RBAC managed on who can access that secret?
3. Storing metadata that could be used by other plans/users: In the Flink Demo I created and patched a config map that i used to store that data: https://github.com/kudobuilder/frameworks/blob/master/repository/flink/docs/demo/submitter/submit.sh#L37

[gkleiman]

What do you think about this?

1. Framework developers are responsible for adding services (the Kubernetes equivalent of a "Marathon VIP") to their framework definitions, so that operators/applications can easily discover/reach whatever the framework install.
2. We can introduce a templated field (e.g., postInstallMessage) that will be rendered and printed by the KUDO CLI after creating an instance. This message can include the url and credentials needed to reach the server and any extra useful information.