[openstack-dev] [nova][keystone] Message Queue Security

David Chadwick d.w.chadwick at kent.ac.uk
Thu Apr 25 16:19:36 UTC 2013

What happens in a very fast system if two sub-processes create a message 
at the same time and therefore contain the same timestamp?


On 25/04/2013 15:41, Davanum Srinivas wrote:
> Now i see it. you are right. we don't need it.
> -- dims
> On Thu, Apr 25, 2013 at 10:26 AM, Simo Sorce <simo at redhat.com> wrote:
>> On Thu, 2013-04-25 at 10:12 -0400, Davanum Srinivas wrote:
>>> Please see below:
>>> Dropping the counter/nonce for the first cut sounds good to me.
>> Ok then I will just drop it, I am writing some code to play with and the
>> counter is just annoying and requires more state to be kept. I'll change
>> the page and get rid of it.
>>>>> 5. Can we please use ISO 8601 timestamps instead of unixtime?
>>>> At the moment I am experimenting with python time.time() values that
>>>> have sub-second resolution. ISO8601 timestamp do not really make sense
>>>> here, This timestamp is not for human consumption, and having to parse
>>>> it back and forth is unnecessary. Also ISO 8601 does not have sub-second
>>>> resolution, while we may want to use it so that we can also drop the
>>>> counter as the chance of 2 message being sent to the same target to end
>>>> up with the same timestamp are low, and we can make it 0 by simply
>>>> keeping around the old timestamp and increasing it by 1 if the new one
>>>> matches exactly.
>>> ISO8601 here is not for human consumption. In my environment, we make
>>> sure all components are synced using NTPD and we like adding code to
>>> reject messages outside of a time window.
>> And you really should use NTP, but what has that to do with how you
>> represent time in the metadata?
>> time.time() gives you the numbers of seconds since the epoch in UTC, int
>> his case with subseconds as well. If you can help me find better
>> language to define the format I'll be happy to. But I think number of
>> seconds since the epoch is fine, we do not need a structured date format
>> here.
>> Simo.
>> --
>> Simo Sorce * Red Hat, Inc * New York
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list