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
signature.asc
Description: PGP signature
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
