Margo Preview Release 1 Scope: Workload Management Interface

[ajcraig]

Purpose

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

Workload Management Interface Scope

1. The ability for the workload orchestration service to provide deployment specification(s) that follow the Margo standard. Link

   • This features enabled via the deployment specification include:
     • Deploy one to many workloads
     • Delete one to many existing workloads
     • Update workload(s) to a newer version of source code(container)
     • Reconfigure currently running workload(s) via parameters

2. The ability to build a Workload Orchestration Management service for orchestrating workloads to Margo compliant devices. Link

   • Host a API server endpoint that:
     • Receive the workload deployment status updates
     • Receive device capabilities
   • Host a Gitops enabled repository for providing desired state to the edge devices:
     • Deployment specification storage
     • Deployment specification retrieval

3. Device Workload Management Interface

   • The ability to build a Rest API Client that enables the features below:
   • Send the workload deployment status updates as defined in the current specification
   • Send device capability information as defined in the current specification
     • Upon device reconfiguration, the interface should update the workload orchestrator of the new or changed capabilities.
   • The ability to use a Git client or library to enable enable the following features:
   • Retrieve deployment specification associated with the device
   • Configure a polling schedule

* Secure communication is not a priority for this release, although some details might be provided. Secure connectivity will be required in subsequent releases.

Decisions:

• Do we go with the initial implementation of OpenGitops, which is currently detailed in the specification, or work through various technical options before release.
• The following envisioned features are not included within the preview release 1:
  • Auditability and tracking history of deployment specification IDs
  • Rollback functionality
  • Disaster recovery requirements
  • Maintenance of the workload orchestration service components
  • Enabling container runtime configuration changes.

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:

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

[merrill-harriman-se]

Does this statement imply that GitOps will be required by the device to get access to the deployment spec?
"Host a Gitops enabled repository for providing desired state to the edge devices: Deployment specification storage Deployment specification retrieval"

I am not yet comfortable with requiring GitOps at the end device - not until we have fully analyzed and justified this over a simple REST interface. I suspect REST is simpler, less resource requirements, no need to open yet another network path, smaller attack surface, less maintenance, and can very likely provide all the needed functionality.

[effndc]

On behalf of Intel I am submitting an approval.

[phil-abb]

I am not yet comfortable with requiring GitOps at the end device - not until we have fully analyzed and justified this over a simple REST interface.

@merrill-harriman-se Would you consider this a blocker for any preview release, or would you be ok if there was a statement somewhere indicating we are still looking into how the desired state is handled and the use of GitOps may change?

[abbottjd]

From ABB, I approve this proposal for the PR1 scope. For the preview release, I don't see a problem with basing on GitOps but acknowledge that it makes sense to continue exploring alternative methods for storing/retrieving desired state before progressing to a formal specification release.

[srberard]

I have similar concerns regarding GitOps at the end device. While GitOps is a powerful deployment technique/paradigm, I feel that requiring it as part of Margo would add complexity, impede implementation, and be overly prescriptive.

A core strength of systems like Kubernetes is their flexibility. K8s does not, itself, prescribe GitOps but instead provides APIs that allow GitOps workflows via tools such as ArgoCD, FluxCD, etc. For those that desire to use GitOps, they can select the appropriate tool that fits their needs. I feel the Margo should strive to do something similar. That is, provide mechanisms to enable GitOps but not require it directly.

[phil-abb]

I have similar concerns regarding GitOps at the end device.

@srberard Same question to you. Would you consider this a blocker for any preview release, or would you be ok if there was a statement somewhere indicating we are still looking into how the desired state is handled and the use of GitOps may change?

[srberard]

I'd rather this not be part of the Preview. While I don't want to block progress, I think including it in the Preview gives the impression that this will be supported.

[securidee]

There is also no mention of a GitOps in the Release 1 scope for device requirements. That seems like a conflict between the workload management interface scope and the device scope.

[phil-abb]

There is also no mention of a GitOps in the Release 1 scope for device requirements.

@securidee I see this part of 3. The ability to host the Margo management interface service(s) that enable workload deployment and maintenance. because for this to be possible, the implementation the device vendor chooses to use would need to be able to work with a Git repository.

Do you see it differently? What do you feel should be added?

[securidee]

There is also no mention of a GitOps in the Release 1 scope for device requirements.

@securidee I see this part of 3. The ability to host the Margo management interface service(s) that enable workload deployment and maintenance. because for this to be possible, the implementation the device vendor chooses to use would need to be able to work with a Git repository.

Do you see it differently? What do you feel should be added?

You are correct. Sorry, I missed the nested requirements in 3. The ability to host the Margo management interface service(s) that enable workload deployment and maintenance. I mistakenly thought a device vendor could just read that portion of the spec, but the Device Workload Management Interface has more specific requirements that apply to the device.