Margo Preview Release 1 Scope: Application Management Scope

[ajcraig]

Purpose

The goal of this Issue is to establish the Margo Preview Release 1 scope. The scope snippet below covers the Application Management Scope. 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.

Application Management Scope

Packaging Applications

Application Vendors shall be able to publish their OCI container-based application by creating an application definition package as defined in Margo specification

1. It is possible for an application Vendor to package their OCI container-based application using one, or both, of these deployment profiles:

   • Defining one, or more, Helm charts to deploy to devices running Kubernetes.
   • Defining one, or more, Docker compose packages to deploy to devices not running Kubernetes (e.g., Docker, Podman).

2. It is possible to describe an application using the Application Description file format defined in the Margo specification. The Application Description format allows for defining the following:

   • Identifying information about the application such as the name, version and description
   • Application metadata to facilitate the ability for a workload orchestration vendor to display the application to the end-user so they can see what applications are available. This includes information such as:
     • An application's icon, tagline, release notes, etc.
     • Information about the application's author
     • Information about the organization distributing the application
   • The ability to define how the application can be deployed by defining one, or more, deployment profiles
   • The ability to request configuration input from the end-user to be used when deploying the application
   • The ability to provide information about how to validate configuration input values from the end-user before deploying the application

3. It is possible to provide the metadata artifacts (license file, release node, application icon, etc.) alongside the application definition file (margo.yaml) for the workload orchestration vendor to import along with the application definition file.

Decisions

1. For this preview release, web assembly (WASM) applications are only supported as long as they are deployed using either a Helm chart or Docker Compose package
2. For this preview release, an operator can be deployed as part of the application's helm chart and will not be restricted by security policies for the preview release. We are discussing how this will be handled for the release*
   • Update January 8th following the app package meeting we will remove support/mentions of Operators for preview release 1.

* This is only for the preview release. Container security policies will be enforced in subsequent releases.

Publishing Applications

Application packages are made available to workload orchestration vendor's solution by storing the files in a git repository (requiring no credentials*) accssible to the workload orchestration vendor's solution.

* This is only for the preview release. Secure connectivity will be required in subsequent releases.

1. It is possible for a single git repository to contain one, or more, application packages.

2. It is possible for the workload orchestration vendor's solution to pull in the application packages using the repository URL and branch name provided by the end user

Artifact Hosting

The Helm charts, Docker Compose packages and OCI container images are hosted in an OCI registry (requiring no credentials*) accessible to the device.

* This is only for the preview release. Secure connectivity will be required in subsequent releases.

1. It is possible for a device to a deploy a Kuberentes application by pulling down the helm chart and OCI container images from the registry without modifying the container registry location in the Helm chart.

2. It is possible for a device to deploy a Docker-Compose based application by pulling down the docker-compose package and OCI container images from the OCI registry without modifying the container registry location in the docker-compose file.

Application Observability

Application vendors may choose to emit observability data via OTEL to the OTEL collector running on the device as defined in the Margo specification.

1. It is possible for the application containers to connect to the OTEL collector using the OTEL environment variables injected into the container as defined in the Margo specification.

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

[arne-broering]

This sounds good. Thanks a lot @ajcraig for nailing this down.
Do you think we should also mention some hint to conformance tests and reference implementation?
Do we want to define a deadline for this?

[tomcounihan]

Section 1 - the " or more," - I wonder should this be removed? If an app is complex, would it still not be encapsulated in 1 such spec file? Otherwise you may have multiple margo.yaml s for a single app?

[phil-abb]

Section 1 - the " or more," - I wonder should this be removed? If an app is complex, would it still not be encapsulated in 1 such spec file? Otherwise you may have multiple margo.yaml s for a single app?

@tomcounihan, this is referring the ability to specify one, or more, components in the deployment profile as indicated in the specification. So, in one margo.yaml file you can have multiple components that are part of that application's deployment.

[phil-abb]

Do you think we should also mention some hint to conformance tests and reference implementation?

@arne-broering the purpose of this preview release is mentioned in this issue which talks about reference implementation and no conformance tests.

[effndc]

On behalf of Intel I am submitting an approval.

[abbottjd]

From ABB, I approve this proposal for the PR1 scope.

[stormc]

The vote is: Approval.

Additional note: From my perspective, it's in particular important to gather feedback on the margo "look+feel" with respect to writing applications, including the limitations and desired improvements for later (preview) releases.

[pauldbrooks]

Rockwell Automation approves

[merrill-harriman-se]

Schneider Electric approves

[jjaswanson4]

Red Hat approves with the following comments:

• We'd like to see a bit more focus given on the observability side in the next iteration, specifically around lifecycle management, but for a first pass this is excellent.
• We don't mind requiring credentials to access software. The spec doesn't need to cover this element, as authentication/authorization to container registries or code repositories already have a ton of available solutions, but allowing for gated access to content is something that should be considered.

[adamqiu-emerson]

Emerson approves.