Charles Moulliard

> I do suppose the title of this issue is potentially misleading due to a mix of problem and solution space. Could we instead say: "cf-for-k8s should support a great...

> Disclaimer 2: I am sceptical about the usage of a tool that is open source, but lacks widespread usage in the broader Kubernetes community. We had (well, have for...

> Thank you for bringing your concerns to us. It seems like the discussion should be moved to the #cf-for-k8s slack channel in the cloudfoundry slack Why. A github ticket,...

> We agree that this should be open for now and filed under the feature request category. We updated the title to reflect the problem and not a solution because...

> Disclaimer 2: I am sceptical about the usage of a tool that is open source, but lacks widespread usage in the broader Kubernetes community. We had (well, have for...

> IMO the ytt strikes a good balance between something that is structure aware, very portable without custom binary extensions and approachable in terms of using a variant of a...

> From my point of view -- I think that providing a fully rendered set of yaml with good defaults is a great thing for a project to have and...

> Recently, I was wondering if the two options are mutually exclusive: I believe that indeed bigger providers will need very sophisticated means to operate their (potentially big number of)...

> At the same time, I completely agree to the observation that the Carvel toolchain can have a similar role than BOSH had in the cf-on-vms world when it comes...

> To cater for both cases, my thought was: Can the individual components of cf-for-k8s define an API which is based on the configuration they support (ultimately, the filled out...