SimpleEdgeDiscovery: breaking change introduced

[Kevsy]

The Spring 25 Identity & Consent Management r2.2 changed the behaviour when both an access token AND device identifier are provided in the request.

This is considered a backward incompatible change, so our options are:

• update the SimpleEdgeDiscovery major version to 2.0.0 in the Spring Meta -Release.
• skip the Spring Meta Release

If we choose to move to 2.0.0, there is also a request for SimpleEdgeDiscovery from the TSC Chair (@hdamker) to move device identifiers from the request header to the request body. This is because all the CAMARA template documentation refers to a 'device object' (not headers), and also because SimpleEdgeDiscovery is the only CAMARA API using request headers for device identifiers.

The result would be that the GET will move to a POST, and hence the EdgeCloud 'optimal edge discovery' API would need to do the same for alignment.

Please let me know your preference by end of Friday 31st January end of Friday 6th February

[JoseMConde]

Hi @Kevsy , a couple of doubts:

• You said:This is because all the CAMARA template documentation refers to a 'device object' (not headers), and also because SimpleEdgeDiscovery is the only CAMAAR API using request headers for device identifiers. but Application Endpoint Discovery has the same behaviour and almost the same parameters, hasn't it??
• What is the problem to use request headers for device identifiers?? I have been trying to find some explanation inside the PR that you linked but I didn't see anything.
  For me a priori, my favorite option would be the second one but I want to understand first if there is something that I am missing.

[Kevsy]

HI @JoseMConde

Application Endpoint Discovery has the same behaviour and almost the same parameters, hasn't it??

Correct - I believe @hdamker was referring to stable APIs (and the majority of initial APIs)

What is the problem to use request headers for device identifiers??

Technically no problem - I think Herbert was rather saying that it (and Application profiles) are the exceptions.

Also I note that if we change GET to POST we also need to change the resource name in the path to a verb per API Design Guidelines .

[JoseMConde]

Thanks @Kevsy ,
totally understood, that's wthat I thought.
Thanks a lot for the clarification.
As I said for me the second option is the best but I have not problem with any other option and you know better than anyone this API. :)

[Kevsy]

Just to clarify: we are not in breach of API Design Guidelines from Commonalities v0.5.0-rc.1, which state:

In such cases, it is recommended to use one of the following methods to transfer the sensitive data:
When using GET, transfer the data using headers, which are not routinely logged or cached

So we are following API Design Guidelines using GET with request headers. If we change to POST then we will also need to change the path resource edge-cloud-zones from a noun to a verb, following:

When the POST method is used:
the resource in the path MUST be a verb (e.g. retrieve-location and not location) to differentiate from an actual resource creation

This is a major change for the API and would also result in a change to the way the API Consumer asks for the 'closest' edge. Today we have ?filter=closest, in a POST model we could have e.g. retrieve-closest-edge as an endpoint, or retrieve-edge-cloud-zones and pass the filter value in the POST request body.

In summary: if we move to POST in this release I don't think we have time to resolve the new design (which also has potential impact on the Optimal Edge Discovery API), create the YAML, update and test the .feature file. So instead of rushing to meet the M4 deadline I think we should instead skip the Spring Meta Release, and resolve the discussion for Fall 24 instead. But please everyone let me know if you think differently.

[Kevsy]

(see also comment from @hdamker in the SimpleEdgeDiscovery release management review thread.

[Kevsy]

Vote extended until end of Friday 7th February (as agreed on call 4th February)

[benhepworth]

If we're going to eventually move to a POST anyway, why not just do it now? FYI we will be doing some development using this over the summer and would rather not have to develop it one way, then switch to another later. Anecdotally for QoD, this move was much easier than we thought to move from a GET to a POST.

[Kevsy]

If we're going to eventually move to a POST anyway, why not just do it now?

Simply because this is a late request that has followed 'API code freeze', and it's so close to the M4 deadline :)

Refactoring to POST means:

• agreeing the new path resource name, which must change from a noun to a verb . Note this verb name needs also to be agreed by the other EdgeCloud APIs that are impacted
• agreeing the request object. Will the semantic indicating we want to return the closest EdgeCloudZone be in the path resource verb, or in the request object? I have my view, but it will need agreement from EdgeCloud
• changing documentation to reflect new operation and response object
• changing .feature file to reflect new operation
• generating Test code for Test results statement required as per API Readiness Guidelines.

So the likelihood of the group collectively delivering this by 14 Feb (two weeks before current M4 date) needs to be a consideration for our decision.

[benhepworth]

thanks for the detailed reply @Kevsy - makes sense to me. Given the tight timeline for Spring, sounds like moving to POST won't be able to make it in by next week. Once we decide on the exact details, we can move forward and have this change ready as soon as we can. I would love to help out with some of the PRs. Just because this will punt to the fall release doesn't mean we have to wait until fall to implement it. My vote is to move forward with this change still, realizing that it won't make it into the Spring release, but have it ready shortly thereafter - maybe target having these changes ready in March or April, then tagged in the fall release. Thoughts?

[Kevsy]

Thanks @ben - I'm happy to propose a change to incorporate POST, knowing that it won't be in time for Spring 25. Rather it will allow sufficient time to discuss and agree the points and tasks above in time for Fall 24 - including those that impact other EdgeCloud APIs.

[benhepworth]

sounds good @Kevsy !

[Kevsy]

Hi @JoseMConde - please see my comment in the Release Management review issue for SimpleEdgeDiscovery, which proposes a way forward.

[JoseMConde]

Hi Kev, for me it's fine to follow your plan explained in the comment. As I've commented before all the options were good to me. It also make sense to me not to move to a version 2.0.0 without functional changes, my only concern is how we manage the API if we skip the meta-release, for this I thought that the second option was the best. Do we know what will be the situation of SED if we skip Spring25 until Fall25??

[Kevsy]

Thanks @JoseMConde -

Do we know what will be the situation of SED if we skip Spring25 until Fall25??

The latest public release remains r1.3 , version 1.0.0 of the API.

The SimpleEdgeDiscovery repository will have a wip version of the API that includes the recent changes to align with Commonalities and ICM. Then I will make an initial PR for the POST change, and we will discuss that in EdgeCloud so that the codeowners of the aligned APIs can contribute. Once agreed I will make a v2.0.0-alpha.1 PR and we will add the Fall 25 Commonaliteis and ICM changes on top of that. Does that sound OK?

[JoseMConde]

Sounds good to me! Let's do it in that way.

[Kevsy]

Thanks all - now confirmed with Herbert and Tanja that we will skip the Spring 25 Meta Release. I have updated the Release Tracker to target 'Fall25', and I will change the SimpleEdgeDiscovery Release PR to a wip PR. This means we will keep the latest changes made to align with Commonalities and Identity & Consent Management, and use that as a basis to build the POST operation and device object.