Finalize Delivery-related template interface

[sclevine]

In RFC0013, two templates were proposed for deploying services and validated them post-deployment:

• ClusterDeployTemplates are cluster-scoped resources that enable application operators to specify resource templates that deploy environments.
  ClusterDeployTemplates take a single source artifact and return a single deployment artifact.

  source -> deployment

• ClusterDeliveryTemplates are cluster-scoped resources that enable application operators to specify resource templates that perform validations on a particular deployed environment.
  ClusterDeliveryTemplates take a deployment artifact and any number of additional source artifacts. They return a single deployment artifact.

  deployment, source[] -> deployment

Based on feedback from the community, I want to suggest that we simplify this interface by making these templates identical in inputs/outputs, by moving the source->deployment "cast" to the input of ClusterDeployTemplate. This also gives us the ability to inject additional K8s config (e.g., values.yaml files for Kapp, out-of-band resources) into ClusterDeployTemplate. Additionally, I also want to suggest that we rename these resources for clarity. The new descriptions would look like:

• ClusterDeploymentTemplates are cluster-scoped resources that enable application operators to specify resource templates that deploy environments.
  ClusterDeliveryTemplates take a deployment artifact and any number of additional source artifacts. They return a single deployment artifact.

  deployment, source[] -> deployment

• ClusterDeploymentValidationTemplates are cluster-scoped resources that enable application operators to specify resource templates that perform validations on a particular deployed environment.
  ClusterDeliveryTemplates take a deployment artifact and any number of additional source artifacts. They return a single deployment artifact.

  deployment, source[] -> deployment

An interesting outcome of this approach would be that it becomes possible to feed the output of a deployment into another deployment. This may or may not be useful. One use case might be deploying several environments that should remain synchronized.

[github-actions]

Hello @sclevine! Welcome to the Cartographer community and thank you for opening your first issue, we appreciate your contributions

[squeedee]

@sclevine I like this on principle, but I'm a little worried that "(Cluster)Deployment(Template)" receives a "deployment" ?

I know it can happen with source into source, config into config etc, but typically that doesn't happen.

[jwntrs]

source into source is actually fairly common. At unit-test step is one example.

I also think that there is a separate distinction for deployment into deployment. It's actually a source into deployment where the source gets cast into a deployment (which gives nice symmetry when its later downcast back to a source).

[squeedee]

RFC 13 should be updated to match this spec if we accept this issue

[waciumawanjohi]

An interesting outcome of this approach would be that it becomes possible to feed the output of a deployment into another deployment. This may or may not be useful. One use case might be deploying several environments that should remain synchronized.

1. I see usefulness in ClusterDeploymentTemplate consuming deployments from other ClusterDeploymentTemplates. Namely, consider a Delivery author who does not have access to create ClusterDeploymentTemplates. There exist two templates that alter a cluster in a manner necessary for their tests of the app to be deployed. The Delivery author can simply call the first deployment template and then call the second deployment template.
2. I do not think that ClusterDeploymentTemplate consuming deployments from other ClusterDeploymentTemplates gives us enough primitives to keep two environments synchronized. This is because ClusterDeploymentTemplate only takes a single deployment. While that deployment would be locked, every other value (e.g. the sources) would not be locked. So synchronization cannot be assured.
   • Possible solution, the sources taken by a deployment are also locked and also passed along. This is not very satisfying because there is no distinction between sources and deployments. Better to allow ClusterDeploymentTemplate to take (and pass on) multiple deployments. Even this is a bit messy, as we would then have to dissambiguate between the different deployments that were being referenced within the template field of the ClusterDeploymentTemplate or ClusterDeploymentValidationTemplates .

[waciumawanjohi]

Closed by #322