Impact of Edge Discovery ServiceAPI (old MEC Exposure & Experience Management API)

[javierlozallu]

As discussed at the Edge Cloud Meeting (25/06) this new API could overlap with the existing SED API and AED API.

Objective: Agree on next steps for the ESD API to maintain CAMARA's mission: to have a single standard API that exposes a capability to customers.

[javierlozallu]

Analysis:

There are 3 Operations:

1. Discovery
   

2. Application Endpoints
   

3. Application Profile
   

• In my opinion an API named Discovery should contain only GET methods to discovery status/attributes for a given parameter but currently EDS API contains CRUD methods.

Impact Analyse

• 1. Discovery:
  • This operation has two methods GET /application-endpoints (at first glance and because of the name, it might overlap with AED API) and GET /mecplatforms (at first glance it might overlap with SED API or GET /edge-cloud-zones of EAM API).

  GET /application-endpoints ESD API vs GET /app-endpoints AED API:

  • GET /application-endpoints ESD API: Returns a list of optimal Application Endpoints that client devices can connect to. You can search based on Application Profile, Region, Suscriber Density or UEIdentity.

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

  • GET /app-endpoints AED API: Returns the closest endpoint of the App Instance for an specific UE. Based on UEIdentity and AppID

  My conclusion is that each method has different functionality but can be merged to improve Application Endpoint Discovery capability, allowing endpoint discovery based on App Profile, Region, Subscriber Density, UEIdentity and AppId.

  Note: There are some considerations to take into account if we agree on the merger.

  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)

  My conclusion is that each method has different functionality but can be merged to improve Edge Cloud Platforms(?) discovery capability, allowing developers to discover them based on Application Profile, Region, Subscriber, UEIdentity and Status.

  Note: There are some considerations to take into account if we agree on the merger.

• 2. Application Endpoints:
  • This Operation allows to: Register and manage the routable Application Endpoints of your deployed applications.
  • Currently the approach is that endpoints are fully managed by the Edge Platform and Developers can ask for this information through GET /apps/{appId}/instances EAM API method.
  • I don't found any intent related to this capability but I think is very interesting to have it because of two reasons:
    • If the developer deploys the application on a hyperscaler
    • If the developer wants to use their own domains, this relates to a comment in Shouldn't the AccessEndpoints also contain the protocol  #271 to have a new API: Bring Your Own DNS/Endpoint/Whatever which allows the developer to use and manage third party domains (other than the Edge platform). So this contribution will serve as a basis for this.
    • A different approach I see here is to add it in the onboarding process within the EAM API, but I don't quite like it.
• 3. Application Profiles:
  • 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.
  • In my opinion this Operation is very interesting and covers part of intent 5, which is outside the scope of the MVP proposal but was considered for the enhancement phase. But it should be placed in the onboarding process within the Edge Application Management API.

Note: I have not added the impact to the SED API because, as far as I understand, the approaches are different, but feel free to add it to the analysis if needed.

This is our analysis and proposals to start the debate, please @Kevsy, @maheshc01, @nicolacdnll, @ThomasEdgeXR, @gunjald give your opinion.

[maheshc01]

Hi @javierlozallu

Thank your the details analysis and recommendation.

Edge Discovery Service(EDS) was always designed to be the more functionality rich version of Simple Edge Discovery Service(SED). SED was meant for operators wanting to go to market quickly with basic functionality the developers need but for operators to provide a more expansive intent based API, EDS is the way to go.

Key functionalities in EDS are (in the sequence developers use) :

1. Ability for developer to share and manage their application requirements via application profiles.
2. Discover the most optimal Edge Cloud site based on various criteria for deploying their application.
3. Register the application end points for the deploy instances
4. discover the most optimal application end point for an end user to connect to.

We went through a tedious exercise in the past to deal with the multiple contributions already submitted to Edge Cloud project and we were able to manage it with creating new sub projects focussed on specific intents. We should try out best to avoid to introduce to API spec if there is a existing proposal addressing it.
In this case Application Endpoint Discovery (AED) definitely overlaps with EDS and i agree with the proposal that we should combine the capability into 1 yaml.

With respect to EDS having a combination of POST, PUT , GET and DELETE functions. In my opinion the ideal end state for the API is:

1. Create separate yaml for Application profiles management- process started with discussions in connectivity insights and QoD as well as commonalities. becomes a reusable API across multiple CAMARA project
2. Create separate yaml for Application end point registry. This is more edge cloud specific but still reusable across the sub projects.
3. EDS will be more focussed on discovery of edge cloud sites and application end points

I expect it would take time to reach this end state and till then we need the functionalities to exist in one place. But we need to agree on the end state target and plan for it.

[javierlozallu]

Agree with you that we need to agree on the end state and plan for it

[maheshc01]

My recommendation is to create a pull request for combining EDS and AED yaml and take this discussion further to action.

[javierlozallu]

Agree with you, in addition I will create an Issue to describe the problem that will be fixed by the PR you mentioned

[maheshc01]

Hi @javierlozallu ..i tried to look for an associated issue but didnt find one which matches this discussion. Please share the number if you have created or let me know once you have created it.

As we work through the process of identifying the common common API and combining them. can we also go ahead and approve PR #263 so that we have the Edge Discovery Service API available in the main branch for everyone's reference rather than having to search for it in the commits.

[javierlozallu]

Sorry for the delay, I have created #285 to address the combination between EDS and AED API and #286 to create a new API for Application Endpoint registry.

[javierlozallu]

The yaml still has Mec platform names and not the Edge Cloud Zones names, do you want to merge the yaml as it is and update the names and harmonize it in future combinations/new yamls?

[maheshc01]

@javierlozallu i would prefer to go ahead and merge the yaml in its current state and make the updates as part of the harmonization efforts.

[maheshc01]

Next steps as per discussion on 8/6.

Moved the edge discovery service yaml in its current form to the API proposals documents. This yaml has replaced existing/older MEC Experience and exposure mgmt API.
Next steps would be to break down the functionality of edge discovery service api into 3 different yaml

1. Application profiles API
2. Application end point registration API
3. Discovery API (2 discovery APIs- 1 for optimal edge cloud discovery and other for optimal application end point discovery)

each of the API contribution will be tracked as separate issues and have corresponding PR to resolve them.

Please comment if there is any change required to the action items listed above.
@javierlozallu

[hdamker]

1. Application profiles API

Short question: how is this API related to https://github.com/camaraproject/ConnectivityInsights/blob/main/code/API_definitions/application-profiles.yaml? Wouldn't it make sense to have one of these APIs?

[javierlozallu]

@maheshc01 if the Application Profiles functionality of the Ede Discovery Services API allows developers to define the network and compute requirements of an application, there is a conflict with the existing Edge Application Management API:

Current definition of App Profiles:

• I fully agree with the concept of App Profiles as it is defined, as it allows developers to manage the lifecycle of the required resources of an application.

1. Conflict with Connectivity Insights API (left) and Edge Discovery Services (right):

I see two different APIs offering the same functionality, so I have the same concern as @hdamker.

2. Conflict with Edge Discovery Services (left) and Application Management API (right):

The concept of App profiles is to allow developers to define the required resources: network and compute.

Currently, in the Edge Application Management API there is the concept of an on-boarding process where developers upload the application information to be instantiated in an Edge Cloud zone as well as the required resources, as defined in Egde Cloud API intents, the developer must be able to "provision the application in the optimal Edge Cloud zone taking into account connectivity, resources (e.g. vCPU, memory, network interfaces, storage, GPU), network load, application privacy considerations, etc." (intent 5).

Based on the agreed Intents I see that App Profiles covers the missing part of Network Required Resources (Edge App Management API only covers computational resources at the moment, as was the first approach of the MVP API), so I think we have to combine the functionalities because they cover the same Intent. Note that the computational resources inside Edge App Management API are getting new contributions to extend the functionalities PR 280 so from my point of view it is easier to add the networkResources object from Edge Discovery Services API inside requiredResources in Edge App Management API.

If it is a complex method, we can divide it into two parts, POST APP manifest (which includes the application information needed for instantiation) and POST APP PROFILES (which includes the necessary network and computational resources), the parameter that relates both capabilities is the appId, which is created once the developer uses the POST APP. Thus, an App Profile is created for a specific appId, as a developer may have more than one application and each has specific requirements.

[maheshc01]

n Edge App Manage

Hi @hdamker,

here is how i am envisioning the application profiles API to evolve from its current state(as part of connectivity insights) to end state(being a common API reused across CAMARA- connectivity insights, Quality on Demand, Edge Cloud and any future CAMARA API which needs to understand the application's needs).

We started out with using the concept in Connectivity insights where the application profile only captures the network KPIs required for the application to work in an optimal/satisfactory way.
I have already created an issue and PR to reuse the concept and yaml in Quality on Demand. (current status is that the issue is in backlog, last time i checked)
Now, we are looking to reuse the same in edge cloud but the application profiles API will need to be enhanced to accept beyond the network requirements and include compute requirements as well such that the data can be used to make decisions on optimal edge cloud platform for hosting the platform.

Considering the TSC direction of not having APIs where there is a lot of data which is optional. I am thinking of creating 2 different application profile yaml file. 1 is already created with the name application profile. other can be part of Edge Application mgmt API or have it as a separate yaml with a different name.
What are your thoughts on this and any recommendations for the name?