openstack team mailing list archive
-
openstack team
-
Mailing list archive
-
Message #12070
Re: [metering] high-level design proposal
-
To:
openstack@xxxxxxxxxxxxxxxxxxx
-
From:
Nick Barcet <nick.barcet@xxxxxxxxxxxxx>
-
Date:
Tue, 22 May 2012 08:40:14 +0100
-
In-reply-to:
<CADb+p3QaMjp7kR49uMRjR=bpB_RDe0yF1eASpF5Eubaizp6qUQ@mail.gmail.com>
-
Openpgp:
id=5FECBD92
-
User-agent:
Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
On 05/21/2012 10:52 PM, Doug Hellmann wrote:
> I have written up some of my thoughts on a proposed design for
> ceilometer in the wiki [1]. I'm sure there are missing details, but I
> wanted to start getting ideas into writing so they could be discussed
> here on the list, since I've talked about different parts with a couple
> of you separately.
>
> Let me know what you think, and especially if I am not clear or have
> left out any details.
>
> Thanks,
> Doug
>
> [1] http://wiki.openstack.org/EfficientMetering/ArchitectureProposalV1
Thanks a lot for putting this together Doug.
A few questions:
* "The collector runs on one or more central management servers to
monitor the message queues (for notifications and for metering data
coming from the agent). Notification messages are processed and turned
into metering messages and sent back out onto the message bus using the
appropriate topic. Metering messages are written to the data store
without modification."
-> Is the reason behind why collectors do not write directly to the
database a way to allow db less implementations as Francis suggested
earlier? In this case it may be useful to say it explicitly.
* "Plugins may require configuration options, so when the plugin is
loaded it is asked to add options to the global flags object, and the
results are made available to the plugin before it is asked to do any work."
-> I am not sure where the "global flags object" resides and how option
are populated. I think it would make sense for this to be globally
controlled, and therefore may require for a simple discovery exchange on
the queue to retrieve values and set defaults if it does not exist yet.
* "Metering messages are signed using the hmac module in Python's
standard library. A shared secret value can be provided in the
ceilometer configuration settings. The messages are signed by feeding
the message key names and values into the signature generator in sorted
order. Non-string values are converted to unicode and then encoded as
UTF-8. The message signature is included in the message for verification
by the collector."
-> The signature is also kept in the database for future audit
processes, maybe worth mentioning it here.
-> In addition to a signature, I think we would need a sequence number
to be embedded by the agent for each message sent, so that loss of
messages, or forgery of messages, can be detected by the collector and
further audit process.
Thanks again,
Nick
Attachment:
signature.asc
Description: OpenPGP digital signature
Follow ups
References