Community Attendees:
Jose Conde Ankita Kohli deepak gunjal Alberto Estévez Caldas Kevin Smith Mark Cornall Sergi Alonso
Community Attendees:
LF Staff:
Agenda
Antitrust Policy
Edge Dicovery Services API
Update Edge Application Mangement API
TI API Planning
AOB
Minutes
Topic 1
Comments
Action items
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
- Mahesh Chapalamadugu bring up to the backlog meeting the possibility to have Application Profiles API in several Camara groups.