Agenda

Antitrust Policy

1. Edge Dicovery Services API

2. Update Edge Application Mangement API

3. TI API Planning

4. AOB

Minutes

Edge Discovery Service

The evolution of Edge Discovery Service API:

1.Deep analysis and different options about the new functionalities. Ppt with the analysis. We have a PR-326 about this API.

2.There are three issues created by Javier to update the new functionalities of EDS in the existing APIS, trying to avoid to create new APIs.

1.Issue 285, this issue proposes to combine AED with EDS: Mahesh created a new Branch.

¡GET /app-endpoints AED API: Returns the closest endpoint of the App Instance for an specific UE. Based on UEIdentity and AppID
This functionality can be merged to improve Application Endpoint Discovery capability, allowing endpoint discovery based on App Profile, Region, Subscriber Density, UEIdentity and AppId.

2.Issue 288, this issue proposes to combine EAM with EDS: Mahesh created a new Branch.

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

3.Issue 286, EDS API: Application Endpoints functionality to be a new API. The PR-321, please review it.

Still pending to merge or close PR263, update old exposure and experience management API to Edge Discovery Services.

Update Edge Application Mangement

We have four new PRs opened by Jon:

• PR-316, is related to:

•Deploy an AppInstance to a single Zone instead of multiple zones.

•Assign a name to the AppInstance.

•Adds more necessary information to the returned AppInstanceInfo, including the AppId (previously no way to figure out which App the AppInstance was an instance of).

• PR-318, is related to:

•Addresses a comment in #280 regarding the addition of the KubernetesClusterRef, and how users would expect to find it. While the KubernetesClusterRef can be found in the AppInstanceInfo, there may be clusters present without any AppInstances. The only way to see those clusters is via a cluster API to list the clusters.

  -PR-319, related to:

¡Clarifies the behavior of the GET appinstances API if there are no matching instances to return. Implementors may consider returning 404 in this case, but I believe it is more correct to return 200 with an empty list.

  -PR-322, related to:

§This removes an unnecessary layer of hierarchy in the GET appinstances response, so it returns an array of objects rather than an array of objects encased in a parent object. 

Traffic Influence

New PR-315:

This PR address two problems:

The TI API adopts 3Legs for any endpoints while sensitive data are not always exchanged.

The description of the usage of the API for "user mobility" related scenarios is not good enough.

There is also a discussion(313), related to create a dedicated repository for this API.

Action items