Emf modular usecase #1194
Emf modular usecase #1194
Conversation
Introduces a new design proposal document outlining supported modular deployment use cases for Edge Manageability Framework (EMF) starting with the 2025.02 release. Details specific modular combinations, interface limitations, and user stories to guide requirements and validation.
Added clarification that AO only, CO only, OB only, and AO+CO+OB domains are not supported in modular usecases. Also updated section heading for EIM+CO+AO to 'User Stories'.
Expanded the EMF modular use case proposal with user stories focused on customers deploying only EIM, CO, and AO domains, enabling them to manage their own observability stack. Details include requirements for configuring edge node agents and orchestrator services to use a customer-provided observability stack.
Introduced a mermaid flowchart to visually represent the relationships and data flow between EMF orchestrator services, edge infrastructure, and customer-managed observability stack. This enhances the documentation by providing a clear, visual overview of the modular use case.
Revised modular deployment list formatting and order for clarity. Updated user stories to distinguish admin-user and developer-user roles. Added detailed EIM modular deployment section with new user stories and mermaid diagrams to illustrate integration scenarios.
Expanded user stories to include detailed configuration instructions for edge node agents, collectors, and orchestrator services. Added a new user story for standalone EIM and observability domains, and clarified section headings for EIM and EIM+OB user stories.
Expanded the design proposal to include user stories and limitations for EIM+CO and EIM+CO+OB modular deployments. Added a mermaid diagram to illustrate the relationships and data flow between EMF orchestrator services, edge infrastructure, and customer-managed components.
krishnajs
requested review from
Ram-srini,
SushilLakra,
cjnolan,
damiankopyto,
garyloug,
guptagunjan,
hyunsun,
johnoloughlin,
palade,
rranjan3,
scottmbaker,
shankarsrinivas1,
soniabha-intc and
sys-orch-approve
as code owners
|
|
||
| ## Supported Modular Use Cases | ||
|
|
||
| The following modular use cases will be supported in EMF starting 2025.02 release along with the full EMF deployment.: |
There was a problem hiding this comment.
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:
- "Device Management with Advanced Cluster Management and Advanced Application Management"
- "Device Management with Advanced Cluster Management"
- "Device Management"
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.
There was a problem hiding this comment.
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.
| Name | Onboarding | OS Provisioning | OOB Management | Multi-Cluster Management | Policy Enabled App Orchestration | Observability Stack |
|---|---|---|---|---|---|---|
| EMF (full) | X | X | X | X | X | X |
| OXM | X | |||||
| EIM | X | X | X | Optional | ||
| EIM + Cluster | X | X | X | X | Optional |
|
|
||
| ### 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 |
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.
|
|
||
| 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 |
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.
|
|
||
| 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 |
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 ?
|
|
||
| #### 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 |
There was a problem hiding this comment.
Can we describe EIM OXM as subclass of the EIM-only configuration?
| 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. |
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.
Description
This pull request adds a new design proposal document for modular deployments of the Edge Manageability Framework (EMF). The document outlines supported modular deployment scenarios, clarifies which EMF domains are available in each use case, and provides user stories to guide requirements and validation for these scenarios.
Documentation: Modular EMF Deployment
design-proposals/emf-modular-usecase.mddescribing modular deployment options for EMF, including supported combinations of domains and excluded configurations.Checklist: