Open Stack

Hi jay:
    Understand you. It is a good method!
    I will try to update my codes.


    Really appreciate your reply. Thanks!


Best Wishes!
zeng chen



At 2017-03-10 02:52:55, "Jay Pipes" <jaypipes at gmail.com> wrote:
>On 03/09/2017 01:37 AM, zengchen wrote:
>> 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()
>
>Instead of datetime.utcnow(), do:
>
>  from oslo_utils import timeutils
>  ...
>
>  now = timeutils.utcnow(with_timezone=True)
>
>Alternately, you might consider creating a closure that masks the 
>with_timezone=True parameter. For instance, you could have a 
>karbor.utils file that contains something like this:
>
>  import functools
>
>  from oslo_utils import timeutils
>
>
>  utcnow = functools.partial(timeutils.utcnow, with_timezone=True)
>
>and then in the file that has your resume_operation() method, you would 
>instead:
>
>  from karbor import utils
>  ...
>
>  now = utils.utcnow()
>
>Best,
>-jay
>
>>     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
>>
>>
>>
>> __________________________________________________________________________
>> 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/20170310/20cbf7d8/attachment-0001.html>