409 CONFLICT has been deprecated by Commonalities

[tanjadegroot]

Problem description
The 409 CONFLICT error has been deprecated by Commonalities 0.8.0. It would be good to remove it.

Expected behavior
In the QoS Booking and Assignment API, instead use the Generic409 "ALREADY_EXISTS" (remove "CONFLICT")
In the QoS Booking API, consider if a dedicated erroro is really needed or if the Generic409 could be used as well.

If applicable, this may need to be documented in the CHANGELOG in both the Breaking changes and the Removed sections wrt to 0.1.0 API versions.

NOTE: This will also impact the test files.

[hdamker]

While looking at this Generic409 block for qos-booking-and-assignment.yaml, one more small drift in the same block, since it'll already be edited to remove CONFLICT:

The GENERIC_409_ABORTED example (code/API_definitions/qos-booking-and-assignment.yaml:1142-1147) still carries an older Commonalities wording rather than the current one:

GENERIC_409_ABORTED:
  description: Concurreny of processes of the same nature/scope
  value:
    status: 409
    code: ABORTED
    message: Concurrency conflict.

Current Commonalities CAMARA_common.yaml (r4.3 / 0.8.0) has:

GENERIC_409_ABORTED:
  description: The resource is undergoing modification by another process
  value:
    status: 409
    code: ABORTED
    message: Resource is being modified by another operation. Please wait, and retry if appropriate.

Worth picking up the current wording (also fixes the "Concurreny" typo) while this block is being touched for the CONFLICT removal.

[Masa8106]

@gmuratk, would you find this issue and creat a PR to resolve the issue?

@hdamker, @jlurien, regarding the dedicated 409 error in QoS Booking API, I can see other CQM APIs such as quality-on-demand API and qos-provisioning API have dedicated 409 error. In my opinion, I would like to prefer the dedicated error in order to keep alignment between APIs in CQM falimies so far. If any comment, please let me know.

[hdamker]

@tanjadegroot re: "In the QoS Booking API, consider if a dedicated error is really needed or if the Generic409 could be used as well" — isn't possible: 409 (like 403/404/422) is a code-subset response: each operation should only expose the specific codes it can produce, not the full (current) common enum — referencing the whole shared object would silently widen the operation's documented contract to codes it was never meant to return. So keeping a dedicated, single-purpose 409 response here is the right shape, not the generic multi-code one. At least until camaraproject/Commonalities#665 lands with Commonalities r4.4.

@Masa8106 agreed — qos-booking.yaml should keep its dedicated 409 (BookingConflict409), consistent with quality-on-demand's and qos-provisioning's dedicated-409 pattern. But the code inside it still needs to move off the deprecated CONFLICT: createBooking's actual scenario ("a booking already exists for this device") matches ALREADY_EXISTS semantics, not CONFLICT — the same fix already proposed above for qos-booking-and-assignment.yaml's createBooking. Keeping the response dedicated and moving off the deprecated code aren't in tension — they're independent choices. quality-on-demand will do this move with the next major version, but not now (as it is a breaking change)

@gmuratk for the PR, concretely:

1. qos-booking.yaml — BookingConflict409 (components/responses): change the code enum and example from CONFLICT to ALREADY_EXISTS; update the description/message text to match (e.g. "The booking that a client tried to create already exists for this device.").
2. qos-booking-and-assignment.yaml — Generic409 (components/responses): remove CONFLICT from the code enum and drop the GENERIC_409_CONFLICT example, per the original issue body. Keep ABORTED/ALREADY_EXISTS/INCOMPATIBLE_STATE.
3. While that block is being touched anyway: update the stale GENERIC_409_ABORTED example (code/API_definitions/qos-booking-and-assignment.yaml:1142-1147) to the current Commonalities r4.3 wording — also fixes the "Concurreny" typo, flagged in the first comment on this issue.
4. Both specs are still in initial phase, so this is a normal fix, not a breaking-change/major-version question — document the removed CONFLICT code in the CHANGELOG's Breaking changes / Removed sections, as the issue body already anticipates.

[Masa8106]

@Masa8106 agreed — qos-booking.yaml should keep its dedicated 409 (BookingConflict409), consistent with quality-on-demand's and qos-provisioning's dedicated-409 pattern. But the code inside it still needs to move off the deprecated CONFLICT: createBooking's actual scenario ("a booking already exists for this device") matches ALREADY_EXISTS semantics, not CONFLICT — the same fix already proposed above for qos-booking-and-assignment.yaml's createBooking. Keeping the response dedicated and moving off the deprecated code aren't in tension — they're independent choices. quality-on-demand will do this move with the next major version, but not now (as it is a breaking change)

@hdamker, I understood. We will update the code from CONFLICT to ALREADY_EXUSTS at this moment, as qos-booking is still in initial phase.

@gmuratk for the PR, concretely:

1. qos-booking.yaml — BookingConflict409 (components/responses): change the code enum and example from CONFLICT to ALREADY_EXISTS; update the description/message text to match (e.g. "The booking that a client tried to create already exists for this device.").
2. Both specs are still in initial phase, so this is a normal fix, not a breaking-change/major-version question — document the removed CONFLICT code in the CHANGELOG's Breaking changes / Removed sections, as the issue body already anticipates.

@gmuratk, I will take the #1 and #4 actions. Would you create a PR for the #2 and #3 actions?