Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: RFC for edge workload #17

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

feat: RFC for edge workload #17

wants to merge 2 commits into from

Conversation

ctron
Copy link
Member

@ctron ctron commented Apr 21, 2022

Copy link
Member

@lulf lulf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice proposal! Left some comments inline as it feels like there are alternatives that could lead to less coupling.

In Drogue IoT, we don't have an edge orchestration layer, as we intend to integrate with an existing solution for edge
workload distribution and management.

However, we do want to distribute edge workload, and manage this, possibly through Drogue IoT from the cloud side.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do we want to do both workload configuration and deployment through drogue cloud? What are the alternatives and why is it better than the alternatives? (Just to make sure we got this written down)

As an example, what if we instead created an API in drogue cloud to retrieve the workload configuration, and make agents for the different edge platforms (like kanto?) that connects to drogue cloud to retrieve the configuration and "deploy" the workload as they best see fit?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had some thoughts on that in the later sections. So the actual deployment should be handled by some system we integrate with (e.g. OCM/ACM). If we focus on Kubernetes as a deployment model, that will make our life easier, I guess.

If we define "general purpose workload", we would create our own workload model, and would need to reconcile/map this to all the others we would want to support (Kubernetes, Kanto, ioFog, ...). I don't really want to invent the "Drogue IoT deployment" model. Which would probably need to be a subset of all the others.

Instead, I would reconcile this way: [OPC UA, BLE, XYZ] -> Kubernetes --(OCM)--> Edge.

If someone wants to use a different tool than OCM/ACM for edge connectivity, that would only require to re-write the "OCM" part.

If someone wants to use a different deployment model than Kubernetes, that would indeed mean re-writing all the reconcilers.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although I understand the current design and agree with the approach, I still think the 'alternatives' at the end doesn't address the 'why do we want to distribute edge workloads using Kubernetes' question, which I think should be answered at the top.

Basically I'd like your reply to my comment to be in the RFC :)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I elaborated a bit on "why kubernetes" at the end of the document. Linking to that from the top section. Does that go into the right direction?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Exactly what I was looking for! 🚀


The user defines some use case specific edge workload. Like with the OPC UA example:

```yaml
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this a standalone resource?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, that should be part of the device. I will make that more clear.

@ctron ctron force-pushed the feature/edge_workload_1 branch from e542469 to f027144 Compare April 21, 2022 11:44
@lulf
Copy link
Member

lulf commented Jul 1, 2022

Should this be merged or should we think some more about how flotta pattern fits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants