Closed hdamker closed 1 month ago
For scope management it also makes sense to split the current API in 2, as QoS Profiles has no Personal Information, and QoS Profiles may be used in other APIs, not only for QoD sessions.
QoD Call Feb 19th: Agreed to split the APIs
Additionally discussed:
@hdamker do you think we can propose a PR already, or should we discuss further on the additional points?
I would approach the task as:
I started with this task. The key point to discuss is which basePath and API version is applied tor each split API:
For qod-sessions.yaml:
a) We keep qod
and v0.11.0
b) We change to qod-sessions
with same or other versioning
For qod-profiles,yaml:
qod-profiles
or other?This is to be agreed prior to the PR
Results from discussion of the above issue within the QoD Call on March 22nd:
qos-profiles
agreed for the profiles (not qod-profiles
)qod
(as of today)qod-sessions
qos-sessions
quality-on-demand
(long form of qod)Request for action: please raise your opinion regarding the right basepath here in the issue
We have to decide also the title for the split yaml, which currently is "QoD for enhanced communication". It should be aligned with the baseBath, so we may choose "Quality on Demand" for the title, and quality-on-demand
for the basePath
But if we are moving to an approach where we have more granular APIs, as we are keeping only the endpoints under the tag "QoS sessions", another option would be qos-sessions
, and call the new split API "QoS sessions"
So maybe deciding on the API title is more relevant.
Problem description
We have currently within the QoD API (v0.10.0) two different resources:
There are several arguments why it would make sense to split the API in two separate ones:
Possible evolution
Split the current API definition into two different "QoS Sessions on Demand" (to be discussed to keep in the basepath
qod
for backward compatibility) "QoS Profiles"Potentially define a YAML with common definitions between the APIs (if not already available within https://github.com/camaraproject/Commonalities/blob/main/artifacts/CAMARA_common.yaml)
Alternative solution
?
Additional context
From discussion within #244:
Splitting the API may have all sense. BTW, we are facing some new use cases where QoS profiles may be used by other APIs as well, so that would ease reusing this functionality.
Originally posted by @jlurien in https://github.com/camaraproject/QualityOnDemand/issues/244#issuecomment-1932642055