2024-01-26 Quality on Demand - Meeting Minutes
- Herbert Damker
- Maximilian Laue
- Rafal Artych
Attendees & Representation
Type @ and your name to indicate your attendance
LF Staff:
Community: @Rafal Artych @Herbert Damker @Jose Luis Urien Pinedo
@Andrew Wajs @Jorge Garcia Hospital @Akos Hunyadi @Eric Murray , Emil Zhang, Joshua Peng, Maximilian Laue, Patrice Conil
Agenda
General Topics
New and existing Issues
Open Pull Requests for v0.10.0
Plan for release v0.10.0
Any Other Topics
Minutes
New and existing Issues
#257 Error behaviour when session cannot be created due to "time cap" limitation
Jose explained the issue
Agreement: The enhancement is a candidate for v0.11.0 and got labeled with "QoD"
Herbert shortly explained the labeling of the issues:
Issues and PRs with 'v0.10.0' are relevant for the release candidate/release of v0.10.0
Issues with "QoD" label are candidates to be addressed within the next release after v0.11.0
"Backlog" issues are currently not considered for a release
Two issues are labeled still as "discussion".
Open Pull Requests for v0.10.0
Summary of the open pull requests presented within issue #260 Proposal to create RC2 of v0.10.0
The following PR were merged during the call:
PR #258 Added clarification of notifications to be sent and added StatusInfo "DELETE_REQUESTED" to address #241 was discussed but not merged:
The PR addressed two issues
Open point is the period of time in
"NOTE: in case of a `QOS_STATUS_CHANGED` event with `qosStatus` as `UNAVAILABLE` and `statusInfo` as `NETWORK_TERMINATED` the resources of the QoS session are not directly released, but will get deleted automatically only 360 seconds after the event"With this formulation it is too restrictive for implementations.
Herbert stated that API consumers need a defined time period in case they want to poll to QoS session status instead of using notifications
Agreement: the statement should only define the time minimum period in which the QoS session resource is still available, but leave it up to implementations when the resources will be released after this period
- Herbert will update the PR and then ask for final reviews
PR #255 Updating the project scope in the ReadMe
Not ready for merge, as there are different opinions
Herbert argues that the scope of CAMARA includes mobile and fixed networks, the API should be technically agnostic regarding the underlying technology, and that the qosProfiles functionality allows to define different profiles and therefore products for different networks based on the offered products
Jorge García sees that the extension to fixed access networks will raise question on the product side, as the API should be offered completely, not partially raise error messages. He would prefer to see atomic APIs for the different scopes to be able to offer them as separate products
Agreement: the explicit change of scope will not done for the release v0.10.0, but targeted for the next release (where it will be addressed together with issue #166).
Jorge García: It is important to communicate the scope change also back to GSMA OGW to ensure a consistent communication.
The PR will kept open for discussion of the wording (changed to draft until the release of v0.10.0)
Plan for release v0.10.0
PR #258 need to be updated, reviewed and merged before the creation of the second release (RC2) candidate as proposed in issue #260
Within next QoD call on Feb 9th we will decide if the RC2 will be final v0.10.0
Any other topics
Herbert asked about opinions about a necessary split of QoS Sessions and QoS Profiles into two separate YAML Files/APIs
There were no opinion raised but the motion came up to open an issue for this discussion
Next QoD will be February, 9th, at 14:00 CET / 13:00 UTC.