Decision Tracker - Workload Management Interface Rest API

[ajcraig]

Purpose The goal of this Issue is to establish a Margo member consensus decision on baseline technology utilized by a specification function. Finalizing this decision will enable the focus group to complete specification section, reference implementation, and test/compliance suite.

Proposal Utilize Rest API interface from Edge Device to Workload Orchestration Software(WOS) to enable the following functionality:

• Onboarding of the API Interface
• Providing WOS with Device Capabilities information (content of message in another Decision tracker issue)
• Providing WOS with workload deployment status updates
• It is assumed there would be additional functionality outlined in the future.

Response Options:

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

@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.

[phil-abb]

@ajcraig Approve Proposal

[stormc]

• [x] Approve Proposal

Remark: We need to have some sort of command & control channel and this commonly is REST for Edge systems, so fully agree.

[hsinghcg]

• [x] Approve Proposal

[adamqiu-emerson]

• [x] Approve Proposal

[tomcounihan]

As someone new in, and for potentially future new people, can someone direct me to the decision criteria applied here? For example, its hard to talk about REST without gRPC being mentioned -I'd like to understand the discussion, if any, had on these choices. Is there a reference that can be shared? What would happen if I wanted to create devices that used gRPC - would that render them inoperable with Margo Management functions?

[phil-abb]

@tomcounihan gRPC was mentioned previously and the request was for someone to put together a proposal for why gRPC would be a better option than REST.

I'm not too familiar with gRPC but I have some specific concerns:

• gRPC is not as well known/familiar as REST/OpenAPI which might make adoption a bit more difficult
• REST/OpenAPI is well-known for industrial networking infrastructure so the services and tools used for networking security expect REST/OpenAPI traffic. I'm not sure how they would handle gRPC traffic.
• Also, at this point, the APIs we have, and the number of times the APIs would be called, is very small so I'm not seeing the value of gRPC for this.

If someone would like to put together a presentation showing the value of gRPC over REST/OpenAPI I would be interested in learning more.

[hsinghcg]

+1 for the reasons/points listed by @phil-abb above. Additionally, there have been discussions around Content Inspection/Data Leakage Prevention proxies being used in some environments. How well gRPC would play with those is also something to be assessed.

[adamqiu-emerson]

Echoing what @phil-abb mentioned, the implementation of gRPC (HTTP/2) on constrained edge device and other network infrastructure may encounter challenges in OT environment. Although for the use case of observability (OTEL) in the other discussion, grpc is supported transport along with http/protobuf.

[tomcounihan]

@phil-abb - the first point I'm not sure how one would put metrics around to make a meaningful measurement. For the second - that is valuable information - can you list the tools? My gut is saying if companies are focused on network security it would be in their fiscal interest to expand the protocol suite to expand market - but a list of typical products would give some insight there. On the 3rd, that statement can lead to a valuable info for the community. Can you point to the existing rest APIs so I can look, along with some info on the 'very small' position. For new-to-industrial, this type of tribal knowledge is invaluable. warm regards, t.

[phil-abb]

@tomcounihan

For the second - that is valuable information - can you list the tools? My gut is saying if companies are focused on network security it would be in their fiscal interest to expand the protocol suite to expand market - but a list of typical products would give some insight there

I don't have any specific tools in mind but from some of the information I've read this seems to be a potential concern, especially when dealing with different types of proxies being used. For example: here, here, and the downside of gRPC mentioned here

If, as part of Margo, we are using a protocol that may require end-users to make changes to their network configuration, or not work at all, it is a risk we need to take into account. This is a point where I'm interested to hear what people's experience have been with using gRPC in OT networks.

On the 3rd, that statement can lead to a valuable info for the community. Can you point to the existing rest APIs so I can look, along with some info on the 'very small' position. For new-to-industrial, this type of tribal knowledge is invaluable. warm regards

We've talked a lot about this in previous meetings and @ajcraig PR is starting to document the Workload Managment API. This is what we've talked about so far for workload management:

• Endpoint for onboarding the device to the WOS - only called when onboarding the device to the WOS
• Endpoint for downloading WOS CA - only called when onboarding the device to the WOS.
• Endpoint for sending device capabilities - called during the onboarding process and when there are hardware changes that need to be reported.
• Endpoint for reporting the deployment status - called when applying the desired state. This would be called most but only during the period when a new desired state is being applied.

[srberard]

• [X] Approve proposal

Remark: We should also consider what encodings/content-types are required as this will have an impact on implementation and compatibility. RESTful APIs often support the use JSON encoding.

[ajcraig]

Consensus has been reached, closing out this decision tracker as it is part of the pre-draft specification.