QoS Parameter for notification listeners

Registered by Mark McLoughlin

From Gordon in https://review.openstack.org/59713

Obviously durable (and/or replicated), reliable delivery is a little more computationally expensive (and potentially operationally complex, since there may be a need to deal with backlogs building in queues etc). If it is not needed/wanted in all cases, (and I suspect it is not), t would be nice to have some way to indicate which subscriptions had this particular QoS requirement. I guess that is what the autodelete/durable configuration options are for. I would think it would be better to have a uniform way of requesting a given QoS when creating the transport, and have it fail at that point if that QoS is not available. Throwing not implemented when you hit a problem is a little too late.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

(?)

Work Items

Dependency tree

* Blueprints in grey have been implemented.

This blueprint contains Public information 
Everyone can see this information.