search

solo-io / service-mesh-extensions

A public registry of all service mesh extensions and other content for the Service Mesh Hub.
Apache License 2.0
14 stars 6 forks source link

Spec for new API that helps address a few use cases #60

Closed rickducott closed 5 years ago

rickducott commented 5 years ago

Here is a spec for an API that addresses a few more advanced use cases around rendering and installing complex applications:

  1. Allow for multiple layers. This was supported with the original API, but wasn't implemented -- now implemented.

  2. Allow for helm values in layers. Currently, we only support kustomize, which are overlaid on the initial installation manifest. For applications with a helm installation spec, it may be preferable for layers to affect how the helm chart is rendered, i.e. containing helm value overrides. In this PR, the layer can now contain a Kustomize layer, a yaml string for helm values, or both.

  3. Allow for optional layers. Currently, every layer is applied as defined. However, for complex applications with many possible layers, it is preferable to enable or disable layers, rather than require defining new flavors with every combination.

  4. Allow for layer options. Currently, a layer has exactly one way it is rendered. However, there may be many different ways a certain layer should be configured. For instance, it may be desired to configure mtls as strict, permissive, or disabled entirely.

  5. Allow for custom flavors. A complex application like a mesh may have a vanilla flavor that makes sense as a starting point. It may even have some various standard flavors that we want to support for all users. However, a single user may want a bespoke flavor that customizes layers in different ways, adds new ones, etc. This PR adds CustomFlavor as a top-level API component that defines a full flavor, and contains a reference to a specific registry name, application, and version that it is extending. The intent is for custom flavors to be defined in different repositories than the application spec itself, so the system that ends up rendering an application with a custom flavor would need the registry name to know how to look up the application spec.

rickducott commented 5 years ago

@kris-nova @EItanya @joekelley

Draft because this is currently implemented as an API break and would require coordination before merging.

joekelley commented 5 years ago

see https://github.com/solo-io/service-mesh-hub/pull/69 for a continuation of the work put forth here.