Margo Preview Release 1 Scope: Device Requirements - Enable Margo Workloads

[ajcraig]

Purpose

The goal of this Issue is to establish the Margo Preview Release 1 scope. The scope snippet below covers the Device Requirements that enable Margo workloads. The goal of this issue is to gain approval on the proposed Preview Release 1 scope. Additional issues will be released for approval regarding the full scope.

** Updated 10/28/2024 to provide additional details regarding scope.

Device Requirements Scope - Enable Margo Workloads

1. The ability to build a Margo compliant device that fits one of the described roles. specification link.
   • Supported device roles include:
     1. Standalone Cluster (single-node cluster)
        • Serves both the Kubernetes Cluster Leader and Worker roles
        • Supports Helm deployment profile type described in application package definition.
     2. Standalone device
        • Supports Docker compose deployment type described in application package definition.
2. The ability to host Margo compliant workloads via OCI container runtime
3. The ability to host the Margo management interface service(s) that enable workload deployment and maintenance.
   • This feature includes the following items:
     • Interpret deployment specification provided via the workload orchestrator. Subsequently deploy the described workloads on the local container runtime.
     • Provide workload deployment status updates to the workload orchestrator
     • Provide device capabilities information to the workload orchestrator.
4. The ability to provide Margo compliant workloads an observability interface and collector to consolidate metrics, traces, and logs.
   • OTEL Collector deployed and running on device
   • OTEL Collector configured to collect the required runtime observability data as stated in the specification.
   • Device is able to inject the required environment variables indicated in the specification into the locally hosted workloads.

Decisions:

• Policy agent and how far we define / require this component within the Device specifications.
• Within this release do we support the extended Kubernetes roles that include worker and leader? Or just the Standalone Cluster role.
• Enrollment of the management interface services currently out of scope.
• Specific operating system requirements are not included in this release.
• Secure certificate and communication requirements not included in this release.

Review/Approval Options:

@margo/approvers Please respond below and consolidate your company's response to a single reply. If additional information is needed to provide your response, please reach out.

Response Options:

• Approve Proposal
• Reject Proposal - Provide reasoning for rejection
• Abstain from Vote - No strong opinion either way

[merrill-harriman-se]

These two questions are listed in the "Decisions" sections:

1. Policy agent and how far we define / require this component within the Device specifications.
2. Within this release do we support the extended Kubernetes roles that include worker and leader? Or just the Standalone Cluster role

If they are questions, then they are not decisions. Does having them here suggest that the feedback of the prerelease will be used to make the decision? If so, that should be more clear.

[effndc]

On behalf of Intel I am submitting an approval.

[abbottjd]

For ABB, I approve this proposal for PR1 scope. We are okay with excluding the following items referenced as questions in the decision list:

• policy agent (requires significant definition and should be considered as a later incremental update)
• multi-node clusters (desired for formal specification release, but not essential to a preview)

[stormc]

The vote is: Approval.

To be defined is in what order and priority – given a timeline – things should be integrated. I guess standalone mode is mandatory and top priority. Things like OPA needn't be in the first shot but have to be in mind when building so to be easily integrated later on.

Having said that, basing an example (virtual) device on ISAR CIP Core from the Civil Infrastructure Platform as pitched by me a few weeks ago could help in velocity. @michaeladler has some very capable hands in these topics.

[hsinghcg]

Capgemini Vote:

• Approve Proposal

On the decision points:

• Policy Agent to be excluded from Preview Release 1
• OK to target single node (master + worker) mode of kubernetes
• Specific OS requirements to be kept out of scope, but I believe the OS type/family is so far (implicitly) assumed to be Linux

[pauldbrooks]

Rockwell Automation approves

[merrill-harriman-se]

Schneider Electric approves with comments -

Specifically - do not include a requirement to support GitOps - there is no way to test conformance.

My assumption about the statement: "Device is able to inject the required environment variables indicated in the specification into the locally hosted workloads."

• For Kubernetes / Helm this implies the use of values.yaml in the deployment
• For Docker / Docker Compose this implies the use of a ".env" file in the deployment

I concur with Capgemini and ABB comments -

1. Policy Agent to be excluded from Preview Release 1
2. Single node Kubernetes for Preview Release 1
3. Specific OS requirements out of scope - state general support for Linux

[jjaswanson4]

Red Hat approves with the following comments:

• We shouldn't be in the business of defining architectures for deployment targets - it doesn't matter if you're deploying to a single-node k8s cluster, or one with 1000 nodes, what's important is conformity to the API spec.

[adamqiu-emerson]

Emerson approves with the following comment:
Consider removing Policy Agent from PR1 scope.