openstack team mailing list archive

["Francis J. Lacoste" <francis.lacoste@xxxxxxxxxxxxx>]

On 12-05-17 08:14 AM, Doug Hellmann wrote:
> 
> 
> On Thu, May 17, 2012 at 5:47 AM, Nick Barcet <nick.barcet@xxxxxxxxxxxxx
> <mailto:nick.barcet@xxxxxxxxxxxxx>> wrote:
> 
>     On 05/17/2012 11:13 AM, Loic Dachary wrote:
>     > On 05/16/2012 11:00 PM, Francis J. Lacoste wrote:
>     >>
>     >> I'm now of the opinion that we exclude storage and API from the
>     >> metering project scope. Let's just focus on defining a metering
>     >> message format, bus, and maybe a client-library to make it easy to
>     >> write metering consumers.
> 
> 
> The plan, as I understand it, is to ensure that all metering messages
> appear on a common bus using a documented format. Deployers who do not
> want the storage system and REST API will not need to use it, and can
> set up their own clients to listen on that bus. I'm not sure how much of
> a client library is needed, since the bus is AMQP and the messages are
> JSON, both of which have standard libraries in most common languages.

Like Thierry Carrez mentioned, the main use for a library was to handle
validation of message signature in a handy fashion. Bug I agree that
this client library would just be a thin convenience wrapper around the
bus protocol.


> 
>     >
>     > Getting rid of the storage imposes a constraint on the billing system
>     > : it must make 100% sure that once a message is consumed it will be
>     > reliably archived. It also adds a constraint on the chosen bus : it
>     > must be able to retain all messages for as long as a consumer needs,
>     > which may be days or weeks. Or it adds a constraint on the billing
>     > system which must make 100% sure it will consume all relevant
>     > messages the bus at all times before they expire.
> 
> 
> That's exactly right. It will be easier for me to bridge between our two
> systems by pulling a day's worth of details from the ceilometer API and
> storing them in the billing system using a batch job, rather than trying
> to ensure that the billing database performs well enough to record the
> information in real time. My goal is to not have to change the billing
> system at all.

That's good information to have. Which means that a REST API + storage
component definitively has some values for some integration cases.

-- 
Francis J. Lacoste
francis.lacoste@xxxxxxxxxxxxx

Attachment: signature.asc
Description: OpenPGP digital signature