Numbering

By Anna V. January 15, 2025. Revised. Version: 0.1.02

This section defines the key terms and concepts used throughout this document to ensure a shared understanding of the naming and numbering conventions.

Numbering Convention Example

  • Leg: A "Leg" represents a distinct stage or interaction within a larger functionality, often involving communication between the Frontend User, Frontend/Backend Microservices, and Backend Resources. Each Leg focuses on a specific aspect of the overall functionality (e.g., static data retrieval, image validation, metadata storage). The image upload functionality, for example, is broken down into multiple Legs to represent the different phases of the upload.

  • Part: A "Part" is a subdivision of a Leg, detailing a specific operation or step within that stage. Each Part has a defined Start Resource and End Resource, along with a sequence of actions. Parts allow for a granular breakdown of complex Legs into manageable and trackable units.

  • Flow: A "Flow" represents a complete sequence of actions or operations, spanning multiple Legs. A Flow describes the end-to-end execution of a specific functionality, from initiation to completion. For example, the "Image Upload Flow" might encompass several Legs, each handling a different part of the overall upload.

  • Component: A "Component" is a logical grouping of related resources and microservices. Components serve to organize the k8or Orbit application into functional units.

  • Microservice: A "Microservice" is a small, independent service within a Component, designed to perform a specific function. Microservices communicate with each other and with backend resources to achieve the overall functionality of the Component. Microservices can be categorized as either Frontend Microservices (FMS), handling user interface interactions, or Backend Microservices (BMS), implementing the core logic and interacting with backend resources.

  • Resource: A "Resource" refers to a backend element that the microservices interact with. Resources are persistent elements like databases (e.g., DynamoDB, MySQL), storage buckets (e.g., S3), or message queues.

  • Process ID (PID): A "Process ID" is a unique identifier assigned to each step or operation (Part) within a flow. The PID follows a structured format (<start-resource>-<end-resource>-e<execution_order>) and is used for tracking and analyzing individual functionality steps.

  • Microservice Identification (MID): A "Microservice Identification" string is a unique identifier assigned to each microservice (e.g., c8fms03). The MID includes a component prefix and a functional identifier, making it easy to identify the microservice's role and location within the k8or Orbit application.

  • Resource Identification (RID): A "Resource Identification" string is a unique identifier assigned to each resource (e.g., c20bre03). The RID includes a component prefix and a resource type and identifier, providing a clear way to identify and reference each resource.

Flow Numbering Convention

This section describes the convention used for numbering process flows within the k8or Orbit application. Consistent flow numbering is important for organizing and referencing the various functionalities within the k8or Orbit application.

  • Base and Increment: Flow numbering begins with flow-4 and increments by 4 for each subsequent flow. This means that the initial flow is designated as flow-4, the next flow is flow-8, then flow-12, flow-16, and so on.

  • Reserved Numbers: Numbers between assigned flow numbers are reserved for future expansion and the addition of new flows. This reservation strategy ensures that new flows can be easily integrated without disrupting the existing numbering sequence. For example, the numbers flow-5, flow-6, and flow-7 are reserved for potential future flows between flow-4 and flow-8. This pattern of reserving numbers between assigned flows is consistently applied across all flow ranges.

  • Example:

Flow numbering within the k8or Orbit application begins with flow-4 and increments by 4 for each subsequent flow. Numbers between assigned flows are reserved for future use, maintaining a structured and expandable numbering system. Each flow is associated with specific repositories (Infrastructure, Application, Data, Population, Testing, and State) on GitHub, enabling version control and collaboration.

Here are examples of assigned flows and their associated components and repositories:

Numbers such as flow-5, flow-6, flow-7 (between flow-4 and flow-8), flow-9, flow-10, flow-11 (between flow-8 and flow-12), and so on, are reserved for future flows within the k8or Orbit application. This structured approach to flow numbering ensures maintainability and scalability as the application evolves.

Block Numbering Convention

This section details the convention used for numbering blocks within a flow. Blocks are used to manage and allocate resources or processing units within a component. The block numbering convention ensures that resources are assigned systematically and avoids conflicts.

  • Component-Specific Reservation: Each component within a flow reserves four consecutive block numbers. These reserved blocks are specifically allocated to that component and are not available for other components within the same flow. This ensures that each component has dedicated resources and prevents resource contention.

  • Reserved Block Pattern: The block numbers are reserved in a specific pattern. This pattern is consistent across all components and flows, making it easy to predict which block numbers are associated with a given component. The pattern for the first eight components is as follows:

    • First Component: 3, 6, 9, 12

    • Second Component: 15, 18, 21, 24

    • Third Component: 27, 30, 33, 36

    • Fourth Component: 39, 42, 45, 48

    • Fifth Component: 51, 54, 57, 60

    • Sixth Component: 63, 66, 69, 72

    • Seventh Component: 75, 78, 81, 84

    • Eighth Component: 87, 90, 93, 96

    This pattern shows that the first component reserves blocks 3, 6, 9, and 12. The second component then reserves blocks 15, 18, 21, and 24, and so on.

  • Example:

    Let's consider a flow-8 that involves three components: Component C4, Component C8, and Component C12.

    • Component C4 (within flow-8) would reserve blocks 3, 6, 9, and 12. These blocks are exclusively assigned to C4 within flow-8.

    • Component C8 (within flow-8) would reserve blocks 15, 18, 21, and 24. These blocks are exclusively assigned to C8 within flow-8.

    • Component C12 (within flow-8) would reserve blocks 27, 30, 33, and 36. These blocks are exclusively assigned to C12 within flow-8.

    If flow-8 needed to add a fourth component, it would reserve blocks 39, 42, 45, and 48. This pattern continues for subsequent components.

    It's important to note that these block reservations are specific to a given flow. If the same component (e.g., C4) appears in a different flow (e.g., flow-12), it would reserve a new set of blocks according to the same pattern. For instance, Component C4 in flow-12 might reserve blocks 3, 6, 9, and 12 again, because the block allocation is per flow instance of the component.

Component Numbering Convention

This section describes the convention used for numbering components within the k8or Orbit application. Consistent component numbering is essential for organizing the k8or Orbit application's architecture and managing resources effectively.

  • Base and Increment: Component numbering begins with C4 and increments by 4 for each subsequent component within the k8or Orbit application. This means the first component is designated as C4, the second as C8, the third as C12, the fourth as C16, and so on.

  • Flow Component Limit: A single flow can accommodate a maximum of eight components. This limitation is imposed by the available block numbering range and helps to maintain manageable and well-defined flows.

  • Flow Division: If a process requires more than eight components, the process must be divided into multiple smaller flows. Each flow will then have its own set of components, numbered according to the C4 incrementing pattern. This ensures that no single flow becomes overly complex and that the eight-component limit is adhered to.

  • Component Numbering Scheme (Regional): While the C4 incrementing pattern applies within the k8or Orbit application, the initial component number assigned to a component can also be influenced by the region where the associated infrastructure resources are located. This regional scheme helps to further organize components across different deployment environments:

    • N. Virginia Region: Infrastructure resources launched in the N. Virginia region are assigned component numbers from 1 to 100. So, a component in this region might be C4, C8, C12, etc., up to C100.

    • Ohio Region - K3s Cluster Master Nodes: K3s cluster master nodes and its components deployed in the Ohio region are assigned component numbers from 101 to 200. A component representing a K3s master node might be C104, C108, C112, etc.

    • Ohio Region - K3s Agent Nodes: K3s agent nodes and its components deployed in the Ohio region are assigned component numbers from 201 to 300. A component representing a K3s agent node might be C204, C208, C212, etc.

Specific Component and Resource Mapping

This section provides a detailed mapping of components, microservices, and resources within the k8or Orbit application, focusing on the k8or Portal node and its interactions. This information is critical for understanding the k8or Orbit application's architecture and the relationships between its various elements.

k8or Portal node Microservices

The following microservices are currently hosted on the k8or Portal node:

  • c8fms03 - Portal Upload Board Frontend Microservice: Handles user interface interactions for image uploads, presenting the upload form and managing user input.

  • c8bms06 - Portal Upload Logic Backend Microservice: Implements the backend logic for image uploads, receiving user data, interacting with other microservices and resources, and managing the upload workflow.

  • c8fms09 - Portal Search Board Frontend Microservice: Manages the user interface for searching uploaded images and related metadata.

  • c8bms18 - Portal Search Logic Backend Microservice: Implements the backend search logic, querying databases and resources to retrieve search results. Also handles the Portal Transfer Logic.

  • c8bms15 - Portal Deploy Logic Backend Microservice: Manages the deployment of applications to Kubernetes clusters, using generated manifests and user configurations.

  • c8bms18 - Portal Transfer Logic Backend Microservice: Handles the transfer of images between different storage locations or registries. (Note: This microservice handles two distinct functions.)

  • c8bms21 - Portal Scan Logic Backend Microservice: Implements image scanning functionalities, potentially for vulnerabilities or compliance checks.

  • c8bms24 - Portal Chart Logic Backend Microservice: Manages the creation and manipulation of Helm charts, facilitating application deployments.

  • c8bms27 - Portal Delete Logic Backend Microservice: Handles the deletion of images, manifests, or other resources within the portal.

Backend Resource List

The following persistent resources are used by the k8or Orbit application:

  • c20bre03 - base-kustomize-1603-tbl-k8d-aws DynamoDB Table: Stores base kustomize manifest templates.

  • c20bre06 - user-input-manifest-data-1606-tbl-k8d-aws DynamoDB Table: Stores user-provided configuration data for manifest generation.

  • c20bre09 - k8or-kustomize-1609-tbl-k8d-aws DynamoDB Table: Stores generated kustomize manifest files.

  • c20bre12 - user-metadata-1612-tbl-k8d-aws DynamoDB Table: Stores user-related metadata.

  • c20bre15 - app-image-metadata-1615-tbl-k8d-aws DynamoDB Table: Stores metadata about uploaded application images.

  • c20bre21 - user-event-log-1621-tbl-k8d-aws DynamoDB Table: Stores user activity logs.

  • c20bre24 - user-error-log-1624-tbl-k8d-aws DynamoDB Table: Stores error logs related to user actions.

  • c20bre27 - portal-upload-static-data-1627-tbl-k8d-aws DynamoDB Table: Stores static data used in the image upload process.

  • c16bre03 - temporary-app-image-1203-bkt-k8d-aws S3 Bucket: Serves as a temporary storage location for uploaded images before validation.

  • c16bre06 - app-image-1206-bkt-k8d-aws S3 Bucket: Stores validated application images.

  • c32bre03 - app_image_mql_2003_dtb_k8d_aws MySQL Database: Stores application and user data, including WordPress data if integrated. Contains multiple tables as detailed in the original document.

PreviousNamingNextMicroservice ID

Last updated