Open Stack

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130805/8914ea22/attachment.pgp>