RFC: Proposed "isAnnotation" as a MeshModel Component Attribute

Kanvas
, ,
1

Not all MeshModel components will not be directly deployable to Kubernetes or another platform under management. Examples:

  1. Design Annotations: A “Note” component that Design authors can use to visually place notes on the canvas.
  2. Component Subsets: A “WASM Filter” component that represents a portion of an overall configuration for another component, like an “Envoy Filter”.

To satisfy these used cases, a new attribute is proposed isAnnotation for the Components Schema. However, other component subset examples don’t necessary neatly fit within and are completely satisfied by an isAnnotation attribute only. Example:

  1. A “Pod” component isAnnotation as a stand-alone resource. A “Pod” component can also be considered a subset of a Deployment or of a Cronjob or many other Kubernetes resources given the high reuse of the Pod spec.

Consider the scenario in which a user first defines a Pod (isAnnotation: true), second defines a Deployment, after which they want to join the Pod as a child of Deployment, leaving both the parent and child as components in the design. A Relationship will need to accompany the Pod component in order to nullify it as independently deployable component and adjoining policy to affix (copy) the Pod component’s configuration into the Deployment component’s configuration.

isAnnotation is proposed to be a mutable attribute of the Component located under metadata, such that while a given Component may carry an initial value for this attribute, design authors may optionally choose to overwrite. Mutability of this attribute facilitates use cases like:

A separate, but related concern is that of deploy-time concerns that are preferences that can be updated at time of deployment of the design:

  1. Depends-on- This includes the use case for deploying CRDs and Operators.

  2. Ignore - Design author has a design full of components and wants to deploy a sub-section of the design (only specific components). Perhaps, they are performing a test or perhaps they want to avoid conflict with existing resources within the environment, like a Kubernetes Namespace without having to be bothered to remove the Namespace from the design.

What thoughts do you have about these use cases for incorporating isAnnotation as an attribute in the ComponentSchema? Does such a combination of isAnnotation and a Relationship satisfy these scenarios? Is there a more robust solution? In what other scenarios will additional Relationships (and their policies) will need to accompany certain components?

2

I am a bit skeptical about this. In my mind, the MeshModel implementation, that is, the engine that processes the Design should implicitly know how each Component of the Design should be handled.

If we have a Design that has this Notes Component, the engine should automatically do what needs to be done. In this case, the engine doesn’t have to do anything. So, the Notes Component can be ignored by the backend engine.

The Design processing engine will have multiple layers. One way to differentiate these layers would be based on what Components they are concerned about. For instance, if we have a Design that has an Envoy Filter Component, it will be handled by a particular layer of the Design processing pipeline and the rest of the layers might just ignore it.

So, there can be a bunch of Components in a Design and the consumers of the Design (MeshMap, the Design processing engine and its different layers) can ignore it if they have no knowledge of them.

So, this idea of adding another field to the Component schema for explicitly mentioning that it cannot be deployed doesn’t appeal very well to me. This is okay if we can guarantee that all our Components will fall into the two categories: Deployable and Non-Deployable. But there can be another class of Components that need to be handled in a completely different way, and we can’t keep adding another field in the Component schema.

3

Elegant. I like it. A concern with the approach using an implicit method of ignoring components (i.e. ignoring components that are mangled or not supported by an active registrant) is the presumption that this is normal and nothing is wrong, but that the engine to continue to proceed with the workflow.

4

The isAnnotation attribute seems valuable to handling not directly deployable components. The combination of the attribute and Relationships effectively satisfies the outlined use cases. Hence, adding the isAnnotation attribute seems reasonable, considering its mutability.