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.

[maheshc01]

Hi @gainsley please find my response to the points you raise below:

1. In QoD, i am not clear on what you mean by all 3 yamls define QosProfileName, as each operator can have their own set of supported Qos Profiles, there is a yaml "QoS Profiles" which allows developers to retrieve the list of support qos profiles and view more details about each qos profile. Qos profile from this API can then further be used in the other 2 APIs in the request body while making a request for quality on demand for a specific session.
   Similarly in Edge cloud, each operator can have their unique set of edge cloud zone which needs to be discovered/retrieved by the app developers and then use it in various other apis, like EAM (for orchestration/mgmt), traffic influence etc.

2. data from /edge-cloud-zone is not the only way for app developers to identify which edge cloud zone there was to orchestrate the app on. App developers will have other means to get the list of edge cloud zone, for example if its hyperscaler provided edge cloud, then they can find the details in hyperscaler API or portal. they might also have other business logic to select a preferred edge cloud zone.
   By separating out /edge-cloud-zone API into discovery API, we would be grouping the APIs based on the intents that we identified in edge cloud. Operators can then choose to implement either discovery API or EAM API or both. while there are dependencies across the APIs , it would still not mandate implementing all the APIs as there would be other non CAMARA ways of performing the action or getting the data. For example, App developers could only use discovery APIs to identify the most optimal edge cloud zone based on network data but then do the orchestration via hyperscaler provided tools.

3. how i am envisioning the GET /edge-cloud-zone as of now is to cater for discovery related intents(please refer to the yaml in the edge discovery service branch) and not from an inventory data perspective. It would be a valid usecase to provide an API for edge cloud zone inventory intent as part of a future edge-cloud-zone mgmt api. having the complete set of CRUD operations in one yaml makes sense. but the intents across these APIs would be different and aligns with having a discovery specific yaml with GET /edge-cloud-zone. possibly the API could look like this GET dicovery/edge-cloud-zone vs GET edgeCloud/edge-cloud-zone

[gainsley]

Hi @maheshc01 thanks for you reply, just trying to understand the intent better here.
For (1), I was just saying each QoD yaml defines #/components/schemas/QosProfileName as a string with bounded lengths, and a specific format ^[a-zA-Z0-9_.-]+$ that must be adhered to. Assuming a QosProfileName can be created via one API yaml, and then referenced by another (not really sure on this), then these definitions are intended to always be the same. But having them defined 3 times means if I want to change the definition, I need to update it in 3 different places, which somewhat weakens the purpose of having a definition in the first place. In this case, maybe this is just the best approach to be able to split up the APIs, and we just need to live with it.

Regarding the other comments, I need to understand better how things are intended to work. I'll ask some questions on the PR directly. Thanks.

[maheshc01]

thanks for clarifying on the QosProfile multiple definition. I could see that as a generic and valid concern. We do the same for the definition of Device across most of the CAMARA APIs. I am not sure if linting rules already checks for consistentcy but if not it would be great to have it incorporated.

Tagging @JoseMConde @Kevsy and @hdamker as this i a good discussion with lot of details. Please chime in if there is anything you would like to add.

[JoseMConde]

Thanks @maheshc01 , I am preparing some slides to disccus about this tomorrow in our meeting, this is a very interesting discussion and we will have to get an agreement. My view is more closely to the Jon's comments but we can discuss deeply in the meeting.

[hdamker]

thanks for clarifying on the QosProfile multiple definition. I could see that as a generic and valid concern.

In this case it is only QosProfileName (and not the QosProfile schema) which is duplicated across the (three) API definitions which are using this identifier. Luckily the format of such identifier should anyway not be changed by all means.

But I agree that the copy&past approach is not perfect, but we decided in this and also other cases to use the approach for now, as otherwise - when using references - we wouldn't have yet the appropriate tooling, starting with the presentation of the API within swagger editor. One approach could be to have a source file with references and a generated "bundled" API definition which has all references resolved ... but that would require the introduction of scripting and GitHub actions. If there are volunteers we can start such activity, most probably in Commonalities.