Open Stack

Reported bug: https://bugs.launchpad.net/ceilometer/+bug/1208547


On 8/5/13 8:45 AM, "Thomas Maddox" <thomas.maddox at RACKSPACE.COM> wrote:

>Yep, I'll do that this morning. Thanks!
>
>On 8/5/13 8:40 AM, "Julien Danjou" <julien at danjou.info> wrote:
>
>>On Mon, Aug 05 2013, Thomas Maddox wrote:
>>
>>> Thinking about it, the latter option seems to describe a very real
>>>concern
>>> going forward that didn't occur to me when I was wandering around the
>>> code. Specifically regarding option 2a, if message 2 arrives at CM
>>>before
>>> message 1 because it ended up on a faster route, then message 1 will
>>> overwrite the metadata from message 2 and we record an incorrect state.
>>> Isn't the nature of network comms for messages at the application layer
>>>to
>>> potentially be out of order and in the case of UDP, even lost? What is
>>>the
>>> leftover purpose of resource-show when we can't trust its output to
>>> represent the actual state of whatever resource is in question? It
>>>seems
>>> that timestamps could be used to prevent overwriting of the latest
>>>state
>>> by checking that the incoming notification doesn't have a timestamp
>>>less
>>> than the already recorded one. I hope I'm not seeing a problem that
>>> doesn't exist here or misunderstanding something. If so, please correct
>>>me!
>>
>>No you're absolutely right. Checking the timestamp before we override
>>resource metadata would be a great idea. Would you mind reporting a bug
>>first, so we can schedule to fix it?
>>
>>-- 
>>Julien Danjou
>>;; Free Software hacker ; freelance consultant
>>;; http://julien.danjou.info
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev