[openstack-dev] [oslo] question about oslo_utils and oslo_versonedobjects

zengchen chenzeng765 at 163.com
Thu Mar 9 06:37:31 UTC 2017


I'm contributing on Karbor (https://wiki.openstack.org/wiki/Karbor). 
Recently, I find a bug in the following codes.


def resume_operation(self, operation_id, **kwargs):
    end_time = kwargs.get('end_time_for_run')
    now = datetime.utcnow()
    if not isinstance(end_time, datetime) or now > end_time:
        return


'end_time_for_run' comes from DB with following definition.
    class ScheduledOperationState():
        fields = {
            'end_time_for_run': fields.DateTimeField(nullable=True),
        }
when 'now' compares to 'end_time', it will raise an exception as I described before.


I mean now that timeutils.untcnow and datetime.utcnow will return a time without
a timezone info attached by default, why not  change DateTimeField to keep it
coincidence with them. I should be a good optimize in the point of view of easy of use.
Certainly, I can change the codes as you described.


Really appreciate your reply.


Best Wishes!
zeng chen



At 2017-03-09 10:43:23, "Jay Pipes" <jaypipes at gmail.com> wrote:
>On 03/08/2017 09:07 PM, zengchen wrote:
>> Hi, jay
>> Thanks for your reply. Do you means it is no need to do that optimization?
>> In my opinion, It is better if do some change. Thanks again.
>
>I'm not quite following you. I don't believe there's any need to change 
>anything nor any need to optimize anything.
>
>Can you elaborate on what issue you are facing?
>
>Best,
>-jay
>
>> At 2017-03-08 00:57:51, "Jay Pipes" <jaypipes at gmail.com> wrote:
>>>On 03/07/2017 01:34 AM, zengchen wrote:
>>>> Hi, guys:
>>>>      I find a non-coincidence definition in Oslo,
>>>>
>>>>      oslo_utils.timeutils.utcnow is defined like this:
>>>>          def utcnow(with_timezone=False):
>>>>
>>>>     oslo_versonedobjects.fields.DateTimeField is defined like this
>>>> classDateTimeField(AutoTypedField): def__init__(self, tzinfo_aware=True,
>>>> **kwargs):
>>>>
>>>>     a = utcnow()
>>>>     class ABC(VersionedObject):
>>>>         fields = {
>>>>             created_at = fields.DateTimeField()
>>>>         }
>>>>     b = ABC(), and fill it by db record.
>>>>
>>>>     If I compare a and b.created_at,  it will raise an exception like this:
>>>>        'TypeError: can't compare offset-naive and offset-aware datetimes'
>>>>     because a's value is like this:
>>>>         datetime.datetime(2017, 3, 7, 2, 34, 50, 859002)
>>>>     b.created_at 's value is like this:
>>>>          datetime.datetime(2017, 3, 7, 2, 35, 27,
>>>> 400786,*tzinfo=<iso8601.Utc>*)
>>>>
>>>>    Can these two kinds of time's definition be coincident? For example:
>>>>        def utcnow(with_timezone=*False*):
>>>>
>>>>        class DateTimeField(AutoTypedField):
>>>>             def __init__(self, tzinfo_aware=*False*, **kwargs):
>>>
>>>Hi Zeng,
>>>
>>>Yes, you will want to use utcnow(with_timezone=True) and the default
>>>ovo.fields.DateTimeField definition *or* use utcnow() and a
>>>ovo.fields.DateTimeField(tzinfo_aware=False) definition.
>>>
>>>Best,
>>>-jay
>>>
>>>__________________________________________________________________________
>>>OpenStack Development Mailing List (not for usage questions)
>>>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170309/0bbd5674/attachment.html>


More information about the OpenStack-dev mailing list