Reported bug: https://bugs.launchpad.net/ceilometer/+bug/1208547
On 8/5/13 8:45 AM, "Thomas Maddox" <thomas.mad...@rackspace.com> wrote: >Yep, I'll do that this morning. Thanks! > >On 8/5/13 8:40 AM, "Julien Danjou" <jul...@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@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev