openstack team mailing list archive

[Caitlin Bestler <Caitlin.Bestler@xxxxxxxxxxx>]

Nick Barcet wrote:


> a) the queue must guaranty the delivery of messages.
> To the contrary of monitoring, loss of events may have important billing impacts, it therefore cannot be an option that message be lost.

I don't think absolute reliability is desirable for this application. SCTP partial reliability may be a better model.

Ultimately, full reliability requires the ability to block new messages from being produced. In the context of billing, that would mean that
a failure of the billing system to consume its messages would result in stopping new services from being provided.

Obviously you want to avoid that, but if the billing system fails do you want to stop providing services as well? You get no billable time in
either case, but I think providing services without metering for billing will keep your customers so that you can bill them for their usage
after you have restarted the billing system.

A partial reliability system would provide a finite amount of storage for in-flight messages that probably should be configured for something
Like3x the longest anticipated failure by the consuming entities to drain the queue. And it should guarantee that there will be no loss of
Messages without an explicit exception being produced (somethink like "EMERGENCY: 2000 billing messages just erased. Interim storage
is fully committed. Where is the consumer?")