...
...
...
...
...
...
...
...
...
...
...
...
DRAFT
...
MINUTES
Attendees & Representation
...
- Antitrust Policy
- Review of previous meeting minutes
- Overall Topics
- Regular Topics
- Closed PRs and Issues
- Open Pull Requests
- New Issues
- Open Issues relevant for v0.11.0
- Any Other Topics
Minutes
Review of previous meeting minutes
...
- PR #325 List sessions endpoint for quality-on-demand is merged, closing:
- PR #326 Align quality-on-demand with Commonalties regarding optional device object and error message is merged, closing:
- #313 Align with Commonality decision about optional device object and respective documentation
- #315 Return 422 instead of 501 if the service is not implemented for specified device
- #316 Align error responses for Device Object with v0.4.0 of Design Guidelines
- ?? #328 #328 Device in response object need to be omitted or clearer defined
- Is this issue completely addressed or only partly?Closed by the following (additional) description within the SessionInfo schema:
Optional device object only to be returned if provided in createSession. If more than one type of device identifier was provided, only one identifier will be returned (at implementation choice and with the original value provided in createSession). Please note that IP addresses of devices can change and get reused, so the original values may no longer identify the same device. They identified the device at the time of session creation. - Thorsten Lohmar commented that the mentioning of the device object in the SessionInfo description is unclear and therefore potentially confusing for readers. He opened QualityOnDemand/issues/340 to address that.
- The issue will get closed with a reference to Commonalities/issues/259 which is addressing the aspect the error message in cases when both a 3-legged token and a device identifier is presented.
- Is this issue completely addressed or only partly?Closed by the following (additional) description within the SessionInfo schema:
- PR #318 Add query to qos-profiles to query profiles available on a given device is merged and closed:
- #328
- Close and refer to Commonalities "API Misuse" for further discussion and potential changes.
- PR #299 New API QOD Provision is merged and closed:
Open Pull Requests (open for review)
- #336
- #339
New Issues
- 337 ...
- Provide feedback
Issues
- PR #335 Align on Commonalities' subscription-model by using
sinkandsinkCredentialswas created and merged to address:
Open Pull Requests
- #339 Fix of reference to qos-profiles API in quality-on-demand.yaml
- Bug fix for #333 Update reference to the QoS Profiles API
- Approved and merged
- #336 Prepare release r1.1
- Details presented by Herbert Damker
- Contains on the side bug fix for #338 Remove reference to protocol in sink description
- Approved by Rafal Artych on behalf of Release Management
- Approved by Eric Murray and Randy Levensalor and no further comments
- With that the r1.1 is approved and Herbert Damker will create the pre-release in GitHub
New Issues
- 337 Potential enhancement of booking feature for qod-provision
- Masaharu Hattori explained the enhancement proposal for the qod-provisioning API shortly. It was initially discussed within issue #268
- His expectation is to get feedback on this enhancement proposal until the next QoD call
Open Issues
- #245 Update and enhance test definition file for QOD API
- From last meeting
- Jose Luis Urien Pinedo will check if internal test definitions can be adapted
- From last meeting
- #317 Application IPs are not shared by OTT for QOD API
- contiune disucssion, potential enhancement for next release
Review scope and time plan for Release Candidate
- #292 Scope of QualityOnDemand for Fall24 CAMARA release
- Plan remaining task for public release of v0.11.0 & qod-provisioning:
- Test definition files: see
- #245
- User StoryStories
- qos-profiles Randy Levensalor (new issue #341)
- quality-on-demand Herbert Damker (new issue #342)
- Plan remaining task for public release of v0.11.0 & qod-provisioning:
- Reminder from last meeting: We will go for the Meta-Release with an "Initial" API Version
- API Version, which means to keep v0.11.0
- Why we don't go for "Stable":
- Lack of prerequisites (test cases, certification of previous version)
- Too many changes between v0.10.0 and v0.11.0, we should have one cycle where we don't introduce breaking changes
- Why we don't go for "Stable":
Any other topics
- Next QoD meeting will be on August 23rd, at 14:00 CEST / 12:00 UTC
...