Handle extension APIs from aggregated API servers and ThirdPartyResource

[pradeepto]

This needs some real thought. If this is done correctly, OpenCompose can become extensible by users of it.

[tnozicka]

Actually, after looking at aggregated API servers and ThirdPartyResources I would imagine it a bit differently. OpenCompose could be an aggregated API server having it's own 3rdparty resource and a controller. This would be an addition/replacement to opencompose tool which would allow you to do kubectl create -f opencompose.yaml or any other operation directly on OpenCompose file. The controller would be the one doing the generation inside the cluster.

It has benefits and downsides. Any parametrization done from the CLI should be possible to specify in the file as well. Also things like local build would not make sense there. Probably some more. And it's significantly harder to write that the converting tool we have, but it could be our next evolution step.

As far as I understand it by having and aggregated server we could have our own API object syntax and not be limited by json/yaml with forced structure e.g.

apiVersion: ...
kind: ...
metadata:
  name: ...

To me all this sound like: let's keep it in mind and see where we stand in few months.

[tnozicka]

Also merging multiple files (using -f option) wouldn't work for this.