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

2017-03-09 Thread zengchen 


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"  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"  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"  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=*)
>>
>>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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
>>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>

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

2017-03-09 Thread Jay Pipes 

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"  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"  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=*)

   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-requ...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-03-08 Thread zengchen 
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"  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"  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=*)

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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-03-08 Thread Jay Pipes 

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"  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=*)

   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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-03-08 Thread zengchen 
Hi, jayThanks 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.

Best Wishes
zeng chen


At 2017-03-08 00:57:51, "Jay Pipes"  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=*)
>>
>>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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-03-07 Thread Jay Pipes 

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=*)

   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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

2017-03-06 Thread zengchen 
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
class DateTimeField(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=)


   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):


best wishes
zeng chen













__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev