Emf modular usecase #1194
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,197 @@ | ||
| # Design Proposal: Edge Manageability Framework Modular Use Case | ||
|
|
||
| Author(s): Edge Manageability Framework Architecture Team | ||
|
|
||
| Last updated: 2025-12-02 | ||
|
|
||
| ## Abstract | ||
|
|
||
| Starting 2025.02 release EMF will support capability for users to deploy full EMF or turnoff certain domains to deploy | ||
| a modular EMF instance. This design proposal outlines the customer usecases for modular EMF deployment. This document | ||
| will not address the full EMF usecase as it is already well established. | ||
|
|
||
| ## Supported Modular Use Cases | ||
|
|
||
| The following modular use cases will be supported in EMF starting 2025.02 release along with the full EMF deployment.: | ||
|
|
||
| - **EIM+CO+AO** Modular deployment with Edge infrastructure manager, Cluster Orchestration and Application | ||
| orchestration without Edge node and Orchestrator observability. | ||
| - **EIM** Modular deployment with Edge infrastructure manager only. | ||
| - **EIM+CO** Modular deployment with Edge infrastructure manager and Cluster Orchestration only. | ||
| - **EIM+OB** Modular deployment with Edge infrastructure manager with Edge node and Orchestrator observability. | ||
|
Contributor
There was a problem hiding this comment. For Observability, is there a need for use cases where we only deploy one of the node or orchestrator observability pipelines but not the other? For example, only edge node observability is required, would just the edge node observability pipeline be deployed or would it be both in that case? The two pipelines are separate already, separate Helm charts, separate configuration settings, different components and different ArgoCD applications, so we could support deploying only one or the other if needed for modular deployments with minimal changes. |
||
| - **EIM+CO+OB** Modular deployment with Edge infrastructure manager, Cluster Orchestration with Edge node | ||
| and Orchestrator observability. | ||
|
|
||
| In all the above modular usecases only CLI and API based interfaces will be supported. GUI based interfaces will not | ||
| be supported in modular usecases. | ||
|
|
||
| Following EMF domains will not be supported in any of the modular usecases: AO only, CO only, OB only and AO+CO+OB. | ||
|
|
||
| ## User Stories for the EMF Modular Use Cases | ||
|
|
||
| In this section we will outline the user stories for each of the modular use cases supported in EMF. These user stories | ||
| will help define the requirements and validation tests for each modular use case. | ||
|
|
||
| ### EIM+CO+AO User Stories | ||
|
|
||
| EIM+CO+AO modular deployment is targeted for full EMF customers who want to manage their own observability stack but | ||
|
Contributor
There was a problem hiding this comment. There's also the case of users who wish to have no observability stack, who find it sufficient to manually log in and retrieve log files or query statistics. This may not be useful for production, but may be useful in an evaluation context. We should provide instructions on where to locate these log files, for example when SSHing into an edge node. |
||
| use EIM, CO and AO from EMF. For customers to use their own observability stack, they will need setup the required data | ||
| store, dashboard and observability control plane services. The Edge node and orchestrator services will be emitting the | ||
| logs and metrics to the customer provided observability stack. The current implementation of the edge node observability | ||
| agents and collectors on the orchestrator should be flexible enough to support this use case. | ||
|
|
||
| ```mermaid | ||
| flowchart TD | ||
| %% Classes for styling | ||
| classDef emf fill:#e3f2fd,stroke:#1565c0,stroke-width:2px,color:#0d47a1; | ||
| classDef customer fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px,color:#1b5e20; | ||
| classDef edge fill:#fff3e0,stroke:#ef6c00,stroke-width:2px,color:#e65100; | ||
|
|
||
| subgraph EMF_Scope ["EMF Orchestrator Services"] | ||
| direction TB | ||
| EIM[Edge Infrastructure Manager]:::emf | ||
| CO[Cluster Orchestration]:::emf | ||
| AO[Application Orchestration]:::emf | ||
| end | ||
|
|
||
| subgraph Edge_Scope ["Edge Infrastructure"] | ||
| Edge_Node[Edge Node Agents]:::edge | ||
| Obs_Agent[Observability Agent & Collector]:::edge | ||
| end | ||
|
|
||
| subgraph Customer_Scope ["Customer Managed Scope"] | ||
| direction TB | ||
| Obs_Stack["Customer Observability Stack<br/>(Data Store, Dashboards, Alerts)"]:::customer | ||
| end | ||
|
|
||
| %% Management Relationships | ||
| EIM -->|Manages| Edge_Node | ||
| CO -->|Orchestrates| Edge_Node | ||
| AO -->|Deploys Apps| Edge_Node | ||
|
|
||
| %% Data Flow | ||
| EIM & CO & AO -.->|Logs & Metrics| Obs_Stack | ||
| Edge_Node -.->|Logs & Metrics| Obs_Agent | ||
| Obs_Agent -.->|Forward| Obs_Stack | ||
|
|
||
| %% Styling links for data flow | ||
| linkStyle 3,4,5,6,7 stroke:#d32f2f,stroke-width:2px,stroke-dasharray: 5 5; | ||
| ``` | ||
|
|
||
| **User story 1:** As a admin-user, I want to deploy EMF with EIM, CO and AO domains only so that I can manage my own | ||
| observability stack and configure the edge node agents, collectors, orchestrator services and collectors to use the | ||
| observability stack deployed by me. I need detailed instructions on how to configure the edge node agents, collectors | ||
| and orchestrator services to send logs and metrics to my own observability stack. | ||
|
|
||
| **User story 2:** As a developer-user, I want to deploy EMF with EIM, CO and AO domains only as i am only | ||
| interested in logs i would like detailed instructions on how to get the edge node agents logs and orchestrator | ||
| services logs directly logging into the system. | ||
|
|
||
| ### EIM and EIM+OB User Stories | ||
|
|
||
| EIM modular deployment is targeted for customers who want to use EMF for edge infrastructure management only. The | ||
| customer will be responsible for managing cluster and application life cycle management. It might be ideal for customer | ||
| deployed application and cluster management stack might need to leverage EIM APIs to link the managed edge node | ||
|
Contributor
There was a problem hiding this comment. What about users who wish no cluster management, who do not intend to use the edge node with kubernetes? Do we consider the lack of cluster management to be one such stack? There was a problem hiding this comment. I think one example we should suggest or demo would be connecting the "bare edge node" to Portainer or some other container management solution. We need to remove the impression that we require Kubernetes. |
||
| instances with their own stack. It is also possible to use EIM as a standalone edge node management solution. | ||
|
|
||
| ```mermaid | ||
| flowchart TD | ||
| %% Classes for styling | ||
| classDef emf fill:#e3f2fd,stroke:#1565c0,stroke-width:2px,color:#0d47a1; | ||
| classDef customer fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px,color:#1b5e20; | ||
| classDef edge fill:#fff3e0,stroke:#ef6c00,stroke-width:2px,color:#e65100; | ||
|
|
||
| subgraph EMF_Scope ["EMF Orchestrator Services"] | ||
| direction TB | ||
| EIM[Edge Infrastructure Manager]:::emf | ||
| end | ||
|
|
||
| subgraph Edge_Scope ["Edge Infrastructure"] | ||
| Edge_Node[Edge Node Agents]:::edge | ||
| end | ||
|
|
||
| subgraph Customer_Scope ["Customer Managed Scope"] | ||
| direction TB | ||
| Cust_Mgmt["Customer App & Cluster<br/>Management Stack"]:::customer | ||
| Obs_Stack["Customer Observability Stack"]:::customer | ||
| end | ||
|
|
||
| %% Management Relationships | ||
| EIM -->|Manages Infrastructure| Edge_Node | ||
| Cust_Mgmt -->|Integrates via API| EIM | ||
| Cust_Mgmt -->|Manages Apps & Clusters| Edge_Node | ||
|
|
||
| %% Data Flow | ||
| EIM -.->|Logs & Metrics| Obs_Stack | ||
| Edge_Node -.->|Logs & Metrics| Obs_Stack | ||
|
|
||
| %% Styling links for data flow | ||
| linkStyle 3,4 stroke:#d32f2f,stroke-width:2px,stroke-dasharray: 5 5; | ||
| ``` | ||
|
|
||
| **User story 1:** As a admin-user, I want to deploy EMF with standalone EIM domain only for device lifecycle | ||
| management at fleet level. I can manage my own Application, Cluster and observability management stack without | ||
| integrating with the EIM state using the EIM APIs. | ||
|
|
||
| **User story 2:** As a developer-user, I want to deploy EMF with EIM domain only for device lifecycle management | ||
| at fleet. I can manage my own Application, Cluster and observability management stack. I will integrate my application, | ||
| cluster and observability stack with the Infrastructure state maintained by EIM. For this I need detailed instructions | ||
| on how to use EIM APIs for integrating with my own stack. | ||
|
|
||
| **User story 3:** As a admin-user, I want to deploy EMF with standalone EIM and edge node and EIM observability domains | ||
| only for device lifecycle management at fleet level. I can manage my own Application, Cluster management stack without | ||
| integrating with the EIM state using the EIM APIs. I need detailed instructions on how to configure the edge node | ||
| agents, collectors and orchestrator services to send logs and metrics to my own observability stack. | ||
|
|
||
| ### EIM+CO and EIM+CO+OB User Stories | ||
|
|
||
| EIM+CO modular deployment is targeted for customers who want to use EMF for edge infrastructure and cluster management | ||
| only. The customer will be responsible for managing application life cycle management. It might be ideal for customer | ||
| deployed application management stack might need to leverage EIM and CO APIs to link the managed edge node | ||
|
Contributor
There was a problem hiding this comment. Providing the ability to download kubeconfig via CLI would be useful here. I know we support this via REST API, but do we support it via CLI also? @hyunsun ? |
||
| instances with their own stack. | ||
|
|
||
| #### Limitation and comparing with EIM OxM profile | ||
|
|
||
| EIM OXM provide mechanism for customer to deploy application on the edge node and install kubernetes cluster on the | ||
|
Contributor
There was a problem hiding this comment. Can we describe EIM OXM as subclass of the EIM-only configuration? |
||
| edge node using `cloud-init` scripts. However EIM OXM profile does not provide any cluster lifecycle management. | ||
| With EIM+CO modular workflow customer get the capability to delete and create the cluster. CO is currently dependent | ||
| on CAPI for in-place upgrade which is still not available. Give this adding to EIM+CO modular workflow will not give | ||
| considerable benefit to customer until in-place upgrade is supported. | ||
|
|
||
| ```mermaid | ||
| flowchart TD | ||
| %% Classes for styling | ||
| classDef emf fill:#e3f2fd,stroke:#1565c0,stroke-width:2px,color:#0d47a1; | ||
| classDef customer fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px,color:#1b5e20; | ||
| classDef edge fill:#fff3e0,stroke:#ef6c00,stroke-width:2px,color:#e65100; | ||
|
|
||
| subgraph EMF_Scope ["EMF Orchestrator Services"] | ||
| direction TB | ||
| EIM[Edge Infrastructure Manager]:::emf | ||
| CO[Cluster Orchestration]:::emf | ||
| end | ||
|
|
||
| subgraph Edge_Scope ["Edge Infrastructure"] | ||
| Edge_Node[Edge Node Agents]:::edge | ||
| end | ||
|
|
||
| subgraph Customer_Scope ["Customer Managed Scope"] | ||
| direction TB | ||
| Cust_App["Customer App Management Stack"]:::customer | ||
| Obs_Stack["Customer Observability Stack"]:::customer | ||
| end | ||
|
|
||
| %% Management Relationships | ||
| EIM -->|Manages Infrastructure| Edge_Node | ||
| CO -->|Orchestrates Clusters| Edge_Node | ||
| Cust_App -->|Integrates via API| EIM | ||
| Cust_App -->|Integrates via API| CO | ||
| Cust_App -->|Deploys Apps| Edge_Node | ||
|
|
||
| %% Data Flow | ||
| EIM & CO -.->|Logs & Metrics| Obs_Stack | ||
| Edge_Node -.->|Logs & Metrics| Obs_Stack | ||
|
|
||
| %% Styling links for data flow | ||
| linkStyle 5,6,7 stroke:#d32f2f,stroke-width:2px,stroke-dasharray: 5 5; | ||
| ``` | ||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rather than referring to this as Full EMF together with 5 different modular use cases, could we refer to it as "6 modular use cases" whereas one of them if full emf? The full emf use case is still modular, it's just one where all modules are enabled. We should treat it as equal to the other use cases.
Another way to describe this is three base use cases (EIM+CO+AO, EIM+CO, and EIM only) with observability as an optional feature. I feel three base use cases are fundamentally decided by how the customer uses EMF, whereas observability is not fundamental to how EMF is used, but is a facilitator of monitoring, which could be achieved in different ways.
Also, I've been mentally giving CO and AO more descriptive names -- describing the three base use cases with more words:
By using "Advanced" we can still imply that primitive management exists. For example, using EIM alone does not preclude a customer from installing K3s yourself, for example via cloud-init, and handling cluster management manually. Similarly EIM+CO does not preclude from deploying applications via manual helm commands.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, that all are "modular" it is just which modules are enabled. I am less concerned about us implying it precludes someone from doing other options, we should instead have a description that suggests what we believe someone may do (e.g. install 3rd party cluster agents, 3rd party app orch agents, etc) with examples that we believe would be possible. In time it would be great to do some demos of 3rd party agents for open source solutions.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Our focus should be on EMF Full and EIM (and maintaining OXM), I don't support investing in EIM+CO at this time as we have no known need. We should instead focus on EIM as a path to onboard the node to a 3rd party CO (e.g. Portainer or Rancher).