Question: have you considered how Margo will work with a GitOps-like setup?

PR1-Sandbox-Discussions
1

This post originated from our community discord, which will be deprecated in favor of this new Discourse!

Original Post via Dvy
Hello, congrats on the release of PR1!

Question: have you considered how Margo will work with a GitOps-like setup?
Where a git repo contains the desired state.
I believe in the sandbox it’s Redis that contains the desired state?
How would WFM integrate with git-based workflows?

Response via @Philip_Presson_ABB

In earlier versions of the specification, it was indicated that Git repositories would be used for delivering the application package and the desired state. The Margo technical working group raised several concerns over having a dependency on Git. You can see some of those concerns listed here.

Over the past few months, we received proposals from technical working group members for alternatives to using Git. For the desired state, there was a proposal to use OCI and a proposal for a Margo-defined API. The proposal for a Margo-defined API was the proposal that the technical working group approved. This is what is currently in the specification for how to handle the desired state

There was also a proposal submitted to use OCI for delivering the application package, which was approved as well. This is what is currently in the specification for how to handle the delivery of the application package.

Additional pointed responses provided:

[dvy]I believe in the sandbox it’s Redis that contains the desired state?

One major note is that both the WFM(Symphony) and the storage mechanism for the desired states(redis) is Out of Scope for the Margo specification.

Both of these tools were picked to provide an open-source WFM to enable our end-to-end Code First Sandbox.
How commercial Workload Fleet Management Suppliers store and manage the desired state files, is completely proprietary.
To describe which components are Open Source / Sandbox Enabling components / and Margo specific components within the Code First Sandbox, please see the following drawing:

sandbox/docs/overlay-architecture.png at main · margo/sandbox · GitHub

[dvy]How would WFM integrate with git-based workflows?

If your git-based workflow is north of the WFM, where you might test various configurations in a build/test/staging workflow?

If this is the case, that would be out of scope for Margo and would be a feature the commercial WFM would provide you.
If you utilize a git-based management strategy for the edge devices, that would stay proprietary.

Phil gave great context about that above.
Here is the current Margo standard for preparing and managing the desired states for the edge devices.

Desired State | Margo Documentation

2

Thanks, that was my question.

I found this article on ‘Gitless GitOps’ based on OCI:

Interestinly they refer to Edge-environments.

Basically it’s still GitOps, but with OCI in between.

Now even if Git is not part of Margo, it might still be the recommended implementation.
Especially with agents starting to also make their way into devops.

3

Hey Davy, glad you made your way over here. We did complete research and received a proposal to utilize the OCI distribution specification for desired state dispersion. However, it was not chosen through our SUP voting process.

The current docs website details out the approved strategy for desired state management.

Additionally the full openapi specification can be found here:

We welcome your feedback!
Armand

4

@Davy could you provide more details about the specific use case(s) you have in mind?

With Margo, we have three main personas:

The workload supplier interacts directly with the fleet manager via the application package (using OCI), and the fleet manager supplier interacts directly with the device via the desired state (using REST APIs).

As you pointed out, OCI can be used for GitOps patterns, so from that perspective, nothing prevents the use of GitOps patterns for delivering the application package to the workload fleet manager.

Is there a use case you have in mind for the interaction between the workload fleet manager and the device where you would like to see the ability to support GitOps patterns?

Is there a specific persona you represent? Or are you thinking in general terms?

5

I’m not so much concerned about how the application package is delivered to the workflow fleet manager.

My question is how do we start managing the desired state of a plant declaratively?
I guess it’s up to the workload fleet manager to manage and store the state?
Which then is out of the scope of Margo, because it doesn’t specify how the WFM should store this state?

Even if it’s outsite of Margo’s scope, I believe the future is a declarative approach based on git.
Because that brings version control, rollbacks, and a way to keep agentic workflows under control out of the box.

6

I guess it’s up to the workload fleet manager to manage and store the state?
Which then is out of the scope of Margo, because it doesn’t specify how the WFM should store this state?

Correct, this is an implementation detail for the WFM and a black box for Margo. Mago only defines the Rest APIs that the devices use to retrieve the desired state from the WFM and doesn’t dictate how the WFM maintains the desired state in the backend.

7

We within Margo completely agree with your notion of the future requiring the declarative approach.

  • The Management API is built on the state seeking approach and utilizing edge providers to complete the local orchestration.
    • We hope that our decisions will enable the advantages you mentioned i.e. version control, rollback, audits, etc.
    • Additional benefits include advanced rollout strategies, support for extended downtime, and much more.
8

Ok thanks for the clarification.

1 Like