Contributing to Models

Models serve as a foundational element in the Meshery ecosystem, representing the interconnectedness of various components inside the infrastructure of an architecture.

Difference Between Model Schemas, Definition, and Instance

Models are infrastructure and application deployment technologies. Model Definitions are read-only templates that contain instructions for creating a any given infrasture. A Model Definition is a snapshot or blueprint of the configuration, credentials(s) and dependencies required for an application to run.

Depending upon where they are in their lifecycle, Meshery Models can be referred to differently based on their are comprised of a handful of core constructs.

1. Schema (static): The schema represents the skeletal structure of a construct and provides a logical view of its size, shape, and characteristics. It defines the expected properties and attributes of the construct. The schema serves as a blueprint or template for creating instances of the construct. It is a static representation that defines the structure and properties but does not contain specific configuration values.

2. Definition (static): The definition is an implementation of the schema. It contains specific configurations and values for the construct at hand. The definition provides the actual configuration details for a specific instance of the construct. It is static because it is created based on the schema but does not change once created. The definition is used to instantiate instances of the construct.

    Things to Keep in Mind while creating RelationshipDefinitions:
   
    a. Relationships are defined only between Components.
    b. The values for Kind, Version  and Model are case-sensitive
    c. The convention is to use camel-casing for Kind and SubType values.
    d. Absence of a field means in the selector means “*” (or wildcard).
        - If we have a selector with {Kind: Pod, Model: Kubernetes}, the absence of the Version field here
          means that all the versions of the Kubernetes Pod resource (e.g. k8s.io/v1/betav2) will match.
    e. In the event of conflicting Relationship Definitions, union between them is taken.
        - If we have two Relationships, one from (Component A) to (Component B and Component F), and another
          from (Component A) to (Component B and Component C), then it is similar to having a Relationship
          from Component A to Component B, C and F
    f. In the event of an overlapping set of complementary Relationship Definitions, Union.
    g. In the event of an overlapping set of conflicting  Relationship Definitions:
        - No relationship type (Kind) is inherently more important than the next one, so will not be any case
          of conflict
   

3. Instance (dynamic): The instance represents a realized construct. It is a dynamic representation that corresponds to a deployed or discovered instance of the construct. The instance is created based on the definition and represents an actual running or deployed version of the construct within the service mesh environment.

If a specific attribute is not provided with a value in the definition, it means that the value for that attribute has to be written or configured per construct. In other words, the absence of a value indicates that the configuration for that attribute is required and specific to each individual construct instance.

Figure: MeshModel Contruct Classification

Contribute to MeshModel Relationships

Relationships within MeshModel play a crucial role in establishing concrete visualisations of efficient data flow between different components of Meshery. These are used to classify the nature of interaction between one or more interconnected Components.

1. Identify the relationship and any specific constraints to be enforced between the two specific components, their models or potentially other components, models, or environmental considerations.
2. Propose a specific visual representation for the relationship.
3. Visual representation examples:
   • Hierarchical
   • Sibling
   • Binding
   • Edge
4. Prospose the appropriate relationship type, using one of the predefined set of relationship types or suggest a new relationship where an existing type does not fit.
5. Create a Relationship Definition (yaml).
6. Create a policy for evaluation of the relationship (rego). See examples.
7. Add in Documentation.

Existing Relationships, their Definitions and their Subtypes

1. Hierarchical relationships involve either an ancestral connection of the components i.e. the creation/ deletion of a Component higher up affects the existence of the Components below in the lineage or a connection which involves the inheritence of features from one Component to the other.
   • Parent - A parent-child relationship implies the requirement of the parent component before the child component can be created. For example, a “Namespace” can be a parent of “Pods” within that namespace. The namespace must exist before creating pods within it.
   • Inventory - Wasm filters can inherit features and functionalities from Envoy filters. This can be used to build on existing functionalities provided by Envoy filters and further extend them using Wasm filters. It enables a modular and scalable approach to customize the behavior of the proxy while maintaining a clear hierarchy of features.
2. Edge relationships indicate the possibility of traffic flow between two components. They enable communication and interaction between different Components within the system.
   • Mount - This subtype addresses the storage and access possibility between involved components. For example, a “PersistentVolume” can be mounted to a “Pod” to provide persistent storage for the pod’s data.
   • Network - This deals with IP addresses and DNS names and provides stable endpoints for communication. For example, a “Service” provides a stable endpoint for accessing multiple replicas of a “Deployment.”
   • Firewall - This acts as intermediary for communications which include standard networking protocols like TCP and UDP. It can enforce network policies to control traffic between components. For example, a “NetworkPolicy” can be used to manage the traffic flow between different “Pods” in the cluster.
   • Permission - This defines the permissions for components if they can have a possible relationship with other Components. It ensures that only authorized Components can interact with each other. For example, a “Role” can define permissions for Components to access specific resources.
3. Sibling relationships represent connections between components that are at the same hierarchical level or share a common parent. Siblings can have the same or similar functionalities or may interact with each other in specific ways. These relationships facilitate communication and cooperation between components that are in the same group or category.
   • Sibling

See all Visual Representations

Hierarchical

Sibling

Binding

Edge

For more information refer - MeshModel - Construct Models in Meshery