Open Stack

On Tue, May 22, 2012 at 3:40 AM, Nick Barcet <nick.barcet at canonical.com>wrote:

> 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.
>

Yes, that's right. I have updated the wiki page to be more explicit on that
point.

http://wiki.openstack.org/EfficientMetering/ArchitectureProposalV1?action=diff&rev2=8&rev1=7


>
> * "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.
>

I was referring to the config object created by nova.flags (although I
think that module is moving to the common library, if it hasn't already).


>
> * "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.
>

Yes, good point.

http://wiki.openstack.org/EfficientMetering/ArchitectureProposalV1?action=diff&rev2=9&rev1=8


> -> 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.
>

OK. We have a message id, but I assumed those would be used to eliminate
duplicates so this sounds like something different or new. It implies that
the agent knows its own id (not hard) and keeps up with a sequence counter
(more difficult, though not impossible). Did you have something in mind for
how to implement that?


>
> Thanks again,
> Nick
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120522/0a79d008/attachment.html>