Platform support for CloudFoundry

[rshriram]

Need to support running the manager/mixer in a cloud foundry environment, where the sidecar runs alongside the app in the same CF container. This would imply that we can no longer use iptable rules to capture all traffic (sidecar might not be transparent).

The config generation for this platform would be similar to what is being done by the Ingress codebase.

[mandarjog]

For outbound traffic there are at least 3 modes of operation in CF

1. Injected variables thru VCAP_SERVICES
2. direct access of cf apps by name. -> normal routing thru gorouter
3. External traffic, when dependency is not externalized.

Which of these we want to support, what is the relative importance.

[rshriram]

I think we have to cleanly separate the mode of access from the logic for config generation. There are only two choices for config generation: transparent mode (current manager internal config generator) and non transparent mode (ingress config generator). It would be nice to further refactor the existing config generation in manager to generate transparent vs non transparent listeners. There are further corner cases, that need to be considered.

On Wed, Mar 15, 2017 at 7:00 PM mandarjog ***@***.***> wrote: For outbound traffic there are at least 3 modes of operation in CF 1. Injected variables thru VCAP_SERVICES 2. direct access of cf apps by name. -> normal routing thru gorouter 3. External traffic, when dependency is not externalized. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#333 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0qd2-vqXUYLM_W6JV1yE5uK-fxVIlpks5rmG1wgaJpZM4MemD2> .

-- ~shriram

[rshriram]

we have added support for typical CF registries (e.g., Eureka). The rest is packaging.
#994

[kyessenov]

Issue moved to istio/istio #1431 via ZenHub