Proposal for new API for application endpoint discovery #212
Replies: 4 comments
-
|
In general I agree with the proposal. However I also feel that there is a need to establish a relationship between the edges or edge cloud zones and the edge applications in order to show a unification between the two related objects. In my understanding the edge applications are supposed to be hosted in these edges or edge cloud zones only so an application endpoint discovery will have an underlying edge cloud zone too. |
Beta Was this translation helpful? Give feedback.
-
Yes, that is the "Edge Cloud Zone Info" as noted above in the output for the Simple App Instance Discovery. This may include EdgeCloudZone ID, GPS coords, etc.
Sure, but that's not really discovery. That's LCM being done by the app provider. Querying for what app instances are in an EdgeCloudZone should be the GET /appinstances endpoint, with a query param that specifies the EdgeCloudZone identifier(s). That will return a list of app instances filtered by which app instances are on the specified EdgeCloudZone. |
Beta Was this translation helpful? Give feedback.
-
|
As discussed in the last two meetings we are in agreement to create this new API so the proposal from @ThomasEdgeXR is accepted. Now we need a volunteer to be the owner of this new API, this means to be in charge of creating the PR with a draft of the yaml and the minimum requirements to have a first release version in CAMARA #170. All the members of the subgroup will provide feedback and improvements to the draft as we usually work. It would be appreciated to have the volunteer for the next meeting at 9th of April. |
Beta Was this translation helpful? Give feedback.
-
|
In PR #245 we uploaded a first contribution for this API to use it as a base to start discussing the functionality. @ThomasEdgeXR, @nicolacdnll, @gunjald take a look and put your comments/proposals to enhance the API. |
Beta Was this translation helpful? Give feedback.
-
Background:
A PR (https://github.com/camaraproject/EdgeCloud/pull/159) was filed to add an optional parameter to the Simple Edge Discover API in order to also include discovery of an application. As commented here #159 (comment) i believe though this needs to be a fully separated API for the reasons explained below. This discussion is supposed to come to a consensus in the group on this matter.
Summary:
There are different layers of edge assets which may be required to be discovered. There are also potentially different users/roles of a discovery if we assume generally a distinction between the roles “application provider” and “application client” as defined in https://github.com/camaraproject/EdgeCloud/blob/main/documentation/SupportingDocuments/edge_terminology.md. The different layers of edge assets to be discovered include
Note: Those terminologies seem to have some overlaps and should be clarified & harmonized to establish a common language and avoid confusion. For the remainder of this summary we will use the terms “Cloudlet” and “Application Instance” for simplicity.
With regards to the topic of discovery we defined several intents related to discovery https://github.com/camaraproject/EdgeCloud/blob/main/documentation/SupportingDocuments/Harmonisation%20of%20APIs/describing%20and%20harmonising%20the%20Edge%20APIs.md
(Provisioning Intents)
2. "I can discover the capabilities/resources available at an operator’s MEC: CPU, Memory, Storage, GPU"
3. "I can discover the geographical regions covered by the operators MECs"
4. "I can discover the closest MEC platform to a specific terminal (closest in terms of shortest network path)"
(Runtime Intents)
19. "I can discover the closest MEC platform to a particular terminal (closest in terms of shortest network path)" 5SED 5MEE EXRC
20. "I can discover the optimal MEC platform for my application and a particular terminal, taking into account connectivity, shortest network path, cost, network load etc." (A) 5SED 5MEE EXRC
21. "I can discover the optimal application service endpoint for a specific terminal, taking into account mobility events, connectivity, shortest network path, cost, network load, MEC platform load etc." 5SED 5MEE EXRC
As noted here https://github.com/camaraproject/EdgeCloud/blob/main/documentation/SupportingDocuments/Harmonisation%20of%20APIs/describing%20and%20harmonising%20the%20Edge%20APIs.md and here https://github.com/camaraproject/EdgeCloud/tree/main/code/API_definitions/Discovery the current “Simple Edge Discovery” based on 5GFF’s Simple Edge Discovery
Note that this API is intended to be called either from the application client or the application provider.
The problem with the intent of PR-159 of adding an optional AppID parameter to the simple discovery API is that it overloads the API with no commonality between the two intents. APIs should have a clear separation of concerns. Adding the optional parameter essentially combines two separate APIs:
Simple Edge Discovery
Simple App Instance Discovery
Note that there is no overlap anywhere, either in input data, output data, or API permissions. If these two are combined into a single API, this makes both documenting, consuming, and implementing this API more confusing and difficult. It is better to keep these two APIs separate.
Note that the current flow of Simple Edge Discovery (as outlined here https://github.com/camaraproject/EdgeCloud/blob/main/documentation/SupportingDocuments/Harmonisation%20of%20APIs/describing%20and%20harmonising%20the%20Edge%20APIs.md#api-workflows) implies that the information about available service endpoints is managed by the developer itself (“Developer server”). This is a possible architecture but is also a different architecture option that e.g. the GSMA OP which internally keeps a record of those endpoints and thus makes it discoverable for the the application developer.
Proposal:
We therefore propose to develop a separate API with the following scope:
Beta Was this translation helpful? Give feedback.
All reactions