Agenda

Antitrust Policy

1.Summer Planning

2.API Current Situation

3.Edge Cloud Repository Maintenance

4.Other topics

Minutes

1.Summer Planning

As summer is a complex time for meetings due to holidays and reduced working hours, this issue was discussed in order to reach an agreement.
The agreement is that at least the main maintainers and codeowners will attend all meetings during the summer season so that we have enough quorum to continue working on the development of the APIs.

2.API Current Situation

1.Edge Cloud Family.

• • SED API to be the only member of the family that will be part of the Meta-Release FALL 24
  • E2E Use case/User Story first draft based on Discussion 206 contributed in PR 265 and to be reviewed

2.Edge Discovery Service (Old Exposure & Experience Management API)

• • PR 263 to fix
    • Issue 38 unused definitions in the yaml
    • Issue 151 resource names: naming conventions and descriptions.

The name of the API looks like is a global API for Edge Discovery so it could generate some confusions in Developers as currently we have 2 separate APIs for Edge Discovery (Edge Cloud Zone and Enpoint of an App).

Jhon Javier Loza Llucoto create a discussion to address possible overlaps and decide on the next steps for the Edge Discovery Service API.

Mahesh Chapalamaduguto update the current PR to cover the following points:

• • • MEC is still used in this API but it was agree at Discussion 196 to avoid this term and replace it with Edge Cloud
    • Documentation should be integrated in the yaml file according to Discussion 229
    • Version should be wip

3.Traffic Influence API, Edge Application Management API and Application Endpoint Discovery API

• • Keep working on the existing PRs and Discussions 
  • Update according to commonalities v0.4.0

4. Simple Edge Discovery API

• • Update according to commonalities v0.4.0
  • Move the corresponding files from Edge Cloud Repository to Simple Edge Repository 

3.Edge Cloud Repository Maintenance

FIRST TOPIC:

DEVICE OBJECT - Discussion 247

Objective: Have a common object to identify a device across Edge Cloud Family

Status: Currently a Device could be identified by:

• ipv4Address
• ipv6Address
• phoneNumber
• networkAccessIdentifier

Action: Consider commonalities v0.4.0 and Commonalities PR to simplify Device Object. Summarize the discussions from SED API and TI API to agree on a common Device Object.

Update:

1.Commonalities - PR to simplify Device Object is already approved to merge:

• The first proposal was to remove `networkAccessIdentifier` as it is not being implemented by any subgroup
• The agreement is to keep the parameter within the Device Object scheme for future-proof but CAMARA does not permit it use. In the case where only `networkAccessIdentifier` is provided, error 422 should be returned and if is provided along with other IDs, it should be ignored.

Conclusion: Keep NetworkAccessIdentifier and update it accordingly, remove the example.

2.SED API - PR 119 has a final conclusion (?):

• Be aligned with other CAMARA APIs (QoD API mainly) and Commonalities v0.4.0

Conclusion: For IpAddress Identifier, add a unique tuple consisting of publicAddress and publicPort to identify a Device.

3.TI API - Issue 123 and Discussion 230

• From Issue 123:
• Be aligned with other CAMARA APIs (QoD API mainly) and Commonalities v0.4.0

Conclusion: For IpAddress Identifier, add a unique tuple consisting of publicAddress and publicPort to identify a Device.

• • From Discussion 230:
  • It is necessary to identify each traffic flow from the Device to the Edge.

Proposal: Add the objects sourceTrafficFilters and destinationTrafficFilters separate from the Device object to identify a Traffic Flow. The Traffic Filter Object contains a single port (sourcePort:destinationPort), so for multiple flows, multiple calls must be made.

Jhon Javier Loza Lluco to summarize the conclusions and write the resolution in Discussion 247

SECOND TOPIC:

APP IP ADDRESS OBJECT – Discussion 264 / Discussion 230 was introduced by Jhon Javier Loza Lluco to summarize the current Discussions

Objective: Define the IP Address Model for App Onboarding-Instantiation

Status: Currently an App Manifest allows:

• Single image
• Multiple interfaces for the single image
• Single Endpoint for the image instantiated per Edge Cloud Zone

Problem: Usually, applications are composed by a set of services (DBs, Storage, Web Servers, etc), each service is instantiated as a separate instance, so it is very important to allow the onboarding of each service, the internal communication between services and the external communication that expose the services to the user clients.

Proposal:

EAM API - Evolve AppManifest Onboarding to allow:

• Multiple images (Container and VMs based) for an application - Issue 262 / Discussion 220
• Internal and external connectivity for each image of the application

EAM API - Evolve AppInstanceInfo to retrieve:

• Multi Endpoints – One endpoint per image of the application if external connectivity was set. The use case should be explained in detail
• Include the protocol for each Endpoint (Current implementation doesn’t consider the protocol) – Issue 271

AED API – Add MultiEndpoints Discovery:

• If an application has several public endpoints, the user must know all of them.

TI API – Add the capability to influence each Traffic Flow:

• If an application has several endpoints for connectivity, then the user should be allowed to influence the traffic of each flow.

Is being covered as part of Discussion 230

4.Other topics

Luis Velarde presented a proposal for a contribution to the Edge Application Management API. He will create a PR to solve some of the current issues for EAM API..

Action items