Combining EDS API with EAM API

[javierlozallu]

Problem description 1. GET /mecplatforms ESD API vs GET /edge-cloud-zones EAM API:

GET /mecplatforms ESD API: Returns a list of optimal MEC Platforms where you can register your deployed application. You can choose to search without passing any of the inputs parameters or combination of Application Profile, Region, Subscriber or UEIdentity.

This method is very interesting and covers part of intent 20, which is outside the scope of the MVP proposal, but was considered for the improvement phase.

GET /edge-cloud-zones EAM API: Returns a list of Edge Cloud Zones and their status, ordering the results by location (region) and filtering by status (active/inactive/unknown)

2. Application Profiles capabilites

This Operation allows to: Create and manage profiles that describe the application requirements of your MEC applications, such as the required connection bandwidth and maximum latency.

Expected behavior

• Improve Edge Cloud Zones discovery capability combining the functionalities, allowing developers to discover them based on Application Profile, Region, Subscriber, UEIdentity and Status.

• There is a conflict with the Application Profiles capability of the EDS API and the requiredResources object of the EAM API, we need to combine them into one API.

Alternative solution

Additional context

[JoseMConde]

Hi @maheshc01, this is one of the issues that we discussed on the last meeting, as you can see the idea is to reuse the existing yaml(API), and add the funcionality of EDS to EAM. Do you think is possible?? I think we can add this new funcionalities in EAM, create a PR and review the code and discuss in this PR about it,doing this we avoid to create a new API.

[maheshc01]

Summarizing the discussion we have on this topic during the weekly call: My recommendation was to separate out and group the APIs in different yaml based on the intents they address. EAM will be more focussed on edge application deployment and life cycle management. Edge discovery service (EDS) will be more focussed on optimal edge cloud zone discovery and end point discovery for users to connect to.

This would ensure that we are inline with TSC recommendation to not make API very big leading to partial implementations. This way operators can choose to implementation both application orchestration/mgmt APIs and Application endpoint discovery APIs or just 1 of them but have a complete implementation of a given yaml.

Action based on the discussion: Have created a new branch(https://github.com/camaraproject/EdgeCloud/tree/Edge-Discovery-Service-API) for carving out edge discovery related APIs. the yaml needs few more updates post which PR will be raised. As part of this change EAM api also will need to be updated to remove GET /edge-cloud-zones as it a discovery API.

[gainsley]

Unfortunately I think the GET /edge-cloud-zones API still needs to be in EAM, because EAM APIs (like POST /appinstances) use the edge-cloud-zone-ID in their requests. Without the GET /edge-cloud-zones API, it's unclear how the user would figure out what the possible edge-cloud-zone-IDs are for the POST /appinstances requests.

[maheshc01]

Hi @gainsley ,

here is an similar example where id/name from 1 api is used as input in another API. https://github.com/camaraproject/QualityOnDemand qos profile name from qos-profiles.yaml is used as 1 of the inputs in quality-on-demand.yaml

Point i am trying to make is, even though edge-cloud-zone-ID is required in EAM as an input param, its not necessary that the GET /edge-cloud-zone API is in the same yaml. there can be in 2 different yamls. and its up to the developers to decide if they want to use the GET /edge-cloud-zone to get the cloud-zone-ID or they use other means to decide on it.

[gainsley]

I see, this is a tricky issue. Some comments:

• In the QoD example you gave, there are 3 different yaml files which all define QosProfileName. This hurts maintainability, as any change to the definition now needs to be done in 3 different places, and there is no validation that they are all consistent. It would probably be better to define common specs in a common file. $ref can refer to definitions in another yaml file. Just something to think about for EDS vs EAM APIs.
• If GET /edge-cloud-zones is in only in EDS when EAM still needs it, that means a platform implementing EAM also needs to implement EDS partially to provide GET /edge-cloud-zones, but I think we want to avoid partial implementations. So maybe it needs to be in a third "common" yaml. Or, if we think that EDS and EAM may provide different data to calls of GET /edge-cloud-zones because they are targeting different intents, then we may have separate versions in each yaml.
• Finally, our platform also provides for managing edge-cloud-zones, so we also have POST/DELETE (CRUD) APIs. If we consider APIs for managing edge-cloud-zones as part of some CAMARA API in the future, potentially the GET should be bundled with the POST/DELETE for /edge-cloud-zones. Or, it could potentially be a separate version that returns different information, such as used/available resources.