Re: [openstack-dev] [fuxi][kuryr] Where to commit codes for Fuxi-golang

2017-06-05 Thread zengchen
Hi all:
The repository of Fuxi-golang has been set up! We can submit bugs and 
bps[1] through launchpad now.
To Antoni Segura, this patch[2] will need your +1 to be merged. So could 
you please take a look at it. Thanks very much!


[1] https://launchpad.net/fuxi-golang
[2] https://review.openstack.org/#/c/470111/


Best Wishes
zengchen





At 2017-05-31 23:55:15, "Hongbin Lu" <hongbin...@huawei.com> wrote:


Please find my replies inline.

 

Best regards,

Hongbin

 

From: Spyros Trigazis [mailto:strig...@gmail.com]
Sent: May-30-17 9:56 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [fuxi][kuryr] Where to commit codes for Fuxi-golang

 

 

 

On 30 May 2017 at 15:26, Hongbin Lu <hongbin...@huawei.com> wrote:

Please consider leveraging Fuxi instead.

 

Is there a missing functionality from rexray?

 

[Hongbin Lu] From my understanding, Rexray targets on the overcloud use cases 
and assumes that containers are running on top of nova instances. You mentioned 
Magnum is leveraging Rexray for Cinder integration. Actually, I am the core 
reviewer who reviewed and approved those Rexray patches. From what I observed, 
the functionalities provided by Rexray are minimal. What it was doing is simply 
calling Cinder API to search an existing volume, attach the volume to the Nova 
instance, and let docker to bind-mount the volume to the container. At the time 
I was testing it, it seems to have some mystery bugs that prevented me to get 
the cluster to work. It was packaged by a large container image, which might 
take more than 5 minutes to pull down. With that said, Rexray might be a choice 
for someone who are looking for cross cloud-providers solution. Fuxi will focus 
on OpenStack and targets on both overcloud and undercloud use cases. That means 
Fuxi can work with Nova+Cinder or a standalone Cinder. As John pointed out in 
another reply, another benefit of Fuxi is to resolve the fragmentation problem 
of existing solutions. Those are the differentiators of Fuxi.

 

Kuryr/Fuxi team is working very hard to deliver the docker network/storage 
plugins. I wish you will work with us to get them integrated with 
Magnum-provisioned cluster.

 

Patches are welcome to support fuxi as an *option* instead of rexray, so users 
can choose.

 

Currently, COE clusters provisioned by Magnum is far away from 
enterprise-ready. I think the Magnum project will be better off if it can adopt 
Kuryr/Fuxi which will give you a better OpenStack integration.

 

Best regards,

Hongbin

 

fuxi feature request: Add authentication using a trustee and a trustID.

 

[Hongbin Lu] I believe this is already supported.

 

Cheers,
Spyros

 

 

From: Spyros Trigazis [mailto:strig...@gmail.com]
Sent: May-30-17 7:47 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [fuxi][kuryr] Where to commit codes for Fuxi-golang

 

FYI, there is already a cinder volume driver for docker available, written

in golang, from rexray [1].


Our team recently contributed to libstorage [3], it could support manila too. 
Rexray
also supports the popular cloud providers.

Magnum's docker swarm cluster driver, already leverages rexray for cinder 
integration. [2]

Cheers,
Spyros 

 

[1] https://github.com/codedellemc/rexray/releases/tag/v0.9.0 

[2] https://github.com/codedellemc/libstorage/releases/tag/v0.6.0

[3] 
http://git.openstack.org/cgit/openstack/magnum/tree/magnum/drivers/common/templates/swarm/fragments/volume-service.sh?h=stable/ocata

 

On 27 May 2017 at 12:15, zengchen <chenzeng...@163.com> wrote:

Hi John & Ben:

 I have committed a patch[1] to add a new repository to Openstack. Please take 
a look at it. Thanks very much!

 

 [1]: https://review.openstack.org/#/c/468635

 

Best Wishes!

zengchen






在 2017-05-26 21:30:48,"John Griffith" <john.griffi...@gmail.com> 写道:

 

 

On Thu, May 25, 2017 at 10:01 PM, zengchen <chenzeng...@163.com> wrote:

 

Hi john:

I have seen your updates on the bp. I agree with your plan on how to 
develop the codes.

However, there is one issue I have to remind you that at present, Fuxi not 
only can convert

 Cinder volume to Docker, but also Manila file. So, do you consider to involve 
Manila part of codes

 in the new Fuxi-golang?

Agreed, that's a really good and important point.  Yes, I believe Ben 
Swartzlander

 

is interested, we can check with him and make sure but I certainly hope that 
Manila would be interested.

Besides, IMO, It is better to create a repository for Fuxi-golang, because

 Fuxi is the project of Openstack,

Yeah, that seems fine; I just didn't know if there needed to be any more 
conversation with other folks on any of this before charing ahead on new repos 
etc.  Doesn't matter much to me though.

 

 

   Thanks very much!

 

Best Wishes!

zengchen

 


At 2017-05-25 22:47:29, "John Griffith&quo

Re: [openstack-dev] [fuxi][kuryr] Where to commit codes for Fuxi-golang

2017-05-31 Thread zengchen
Hi, Spyros:
Recently, Rexray can supply volume for Docker by integrating Cinder. It is 
great!  However, comparing to Fuxi,  Rexray is a little heavier. Because Rexray 
must depend on Libstorage to communicate with Cinder. Fuxi-golang is just a new 
project which re-implements Fuxi in go language. From the standpoint of Fuxi, 
Fuxi-golang is just her 'sister'.


By the way, you said you have been integrating Manila to Libstorage. But I 
don't see the relevant materials from the link[1]. Is the link wrong or do I 
miss something. Could you give more details about your work on integrating 
Manila?  Thanks very much!


Best Wishes!
zengchen
. 
[1] 
http://git.openstack.org/cgit/openstack/magnum/tree/magnum/drivers/common/templates/swarm/fragments/volume-service.sh?h=stable/ocata





At 2017-05-30 19:47:26, "Spyros Trigazis" <strig...@gmail.com> wrote:

FYI, there is already a cinder volume driver for docker available, written
in golang, from rexray [1].

Our team recently contributed to libstorage [3], it could support manila too. 
Rexray
also supports the popular cloud providers.

Magnum's docker swarm cluster driver, already leverages rexray for cinder 
integration. [2]

Cheers,
Spyros 


[1] https://github.com/codedellemc/rexray/releases/tag/v0.9.0 
[2] https://github.com/codedellemc/libstorage/releases/tag/v0.6.0
[3] 
http://git.openstack.org/cgit/openstack/magnum/tree/magnum/drivers/common/templates/swarm/fragments/volume-service.sh?h=stable/ocata


On 27 May 2017 at 12:15, zengchen <chenzeng...@163.com> wrote:

Hi John & Ben:
 I have committed a patch[1] to add a new repository to Openstack. Please take 
a look at it. Thanks very much!


 [1]: https://review.openstack.org/#/c/468635


Best Wishes!
zengchen






在 2017-05-26 21:30:48,"John Griffith" <john.griffi...@gmail.com> 写道:





On Thu, May 25, 2017 at 10:01 PM, zengchen <chenzeng...@163.com> wrote:



Hi john:
I have seen your updates on the bp. I agree with your plan on how to 
develop the codes.
However, there is one issue I have to remind you that at present, Fuxi not 
only can convert
 Cinder volume to Docker, but also Manila file. So, do you consider to involve 
Manila part of codes
 in the new Fuxi-golang?
Agreed, that's a really good and important point.  Yes, I believe Ben 
Swartzlander
 
is interested, we can check with him and make sure but I certainly hope that 
Manila would be interested.
Besides, IMO, It is better to create a repository for Fuxi-golang, because
 Fuxi is the project of Openstack,
Yeah, that seems fine; I just didn't know if there needed to be any more 
conversation with other folks on any of this before charing ahead on new repos 
etc.  Doesn't matter much to me though.
 


   Thanks very much!


Best Wishes!
zengchen





At 2017-05-25 22:47:29, "John Griffith" <john.griffi...@gmail.com> wrote:





On Thu, May 25, 2017 at 5:50 AM, zengchen <chenzeng...@163.com> wrote:

Very sorry to foget attaching the link for bp of rewriting Fuxi with go 
language.
https://blueprints.launchpad.net/fuxi/+spec/convert-to-golang




At 2017-05-25 19:46:54, "zengchen" <chenzeng...@163.com> wrote:

Hi guys:
hongbin had committed a bp of rewriting Fuxi with go language[1]. My 
question is where to commit codes for it.
We have two choice, 1. create a new repository, 2. create a new branch.  IMO, 
the first one is much better. Because
there are many differences in the layer of infrastructure, such as CI.  What's 
your opinion? Thanks very much
 
Best Wishes
zengchen

__
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


Hi Zengchen,


For now I was thinking just use Github and PR's outside of the OpenStack 
projects to bootstrap things and see how far we can get.  I'll update the BP 
this morning with what I believe to be the key tasks to work through.


Thanks,
John



__
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] [fuxi][kuryr] Where to commit codes for Fuxi-golang

2017-05-27 Thread zengchen
Hi John & Ben:
 I have committed a patch[1] to add a new repository to Openstack. Please take 
a look at it. Thanks very much!


 [1]: https://review.openstack.org/#/c/468635


Best Wishes!
zengchen






在 2017-05-26 21:30:48,"John Griffith" <john.griffi...@gmail.com> 写道:





On Thu, May 25, 2017 at 10:01 PM, zengchen <chenzeng...@163.com> wrote:



Hi john:
I have seen your updates on the bp. I agree with your plan on how to 
develop the codes.
However, there is one issue I have to remind you that at present, Fuxi not 
only can convert
 Cinder volume to Docker, but also Manila file. So, do you consider to involve 
Manila part of codes
 in the new Fuxi-golang?
Agreed, that's a really good and important point.  Yes, I believe Ben 
Swartzlander
 
is interested, we can check with him and make sure but I certainly hope that 
Manila would be interested.
Besides, IMO, It is better to create a repository for Fuxi-golang, because
 Fuxi is the project of Openstack,
Yeah, that seems fine; I just didn't know if there needed to be any more 
conversation with other folks on any of this before charing ahead on new repos 
etc.  Doesn't matter much to me though.
 


   Thanks very much!


Best Wishes!
zengchen





At 2017-05-25 22:47:29, "John Griffith" <john.griffi...@gmail.com> wrote:





On Thu, May 25, 2017 at 5:50 AM, zengchen <chenzeng...@163.com> wrote:

Very sorry to foget attaching the link for bp of rewriting Fuxi with go 
language.
https://blueprints.launchpad.net/fuxi/+spec/convert-to-golang




At 2017-05-25 19:46:54, "zengchen" <chenzeng...@163.com> wrote:

Hi guys:
hongbin had committed a bp of rewriting Fuxi with go language[1]. My 
question is where to commit codes for it.
We have two choice, 1. create a new repository, 2. create a new branch.  IMO, 
the first one is much better. Because
there are many differences in the layer of infrastructure, such as CI.  What's 
your opinion? Thanks very much
 
Best Wishes
zengchen

__
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


Hi Zengchen,


For now I was thinking just use Github and PR's outside of the OpenStack 
projects to bootstrap things and see how far we can get.  I'll update the BP 
this morning with what I believe to be the key tasks to work through.


Thanks,
John



__
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] [fuxi][kuryr] Where to commit codes for Fuxi-golang

2017-05-25 Thread zengchen


Hi john:
I have seen your updates on the bp. I agree with your plan on how to 
develop the codes.
However, there is one issue I have to remind you that at present, Fuxi not 
only can convert
 Cinder volume to Docker, but also Manila file. So, do you consider to involve 
Manila part of codes
 in the new Fuxi-golang? Besides, IMO, It is better to create a repository for 
Fuxi-golang, because
 Fuxi is the project of Openstack,


   Thanks very much!


Best Wishes!
zengchen





At 2017-05-25 22:47:29, "John Griffith" <john.griffi...@gmail.com> wrote:





On Thu, May 25, 2017 at 5:50 AM, zengchen <chenzeng...@163.com> wrote:

Very sorry to foget attaching the link for bp of rewriting Fuxi with go 
language.
https://blueprints.launchpad.net/fuxi/+spec/convert-to-golang




At 2017-05-25 19:46:54, "zengchen" <chenzeng...@163.com> wrote:

Hi guys:
hongbin had committed a bp of rewriting Fuxi with go language[1]. My 
question is where to commit codes for it.
We have two choice, 1. create a new repository, 2. create a new branch.  IMO, 
the first one is much better. Because
there are many differences in the layer of infrastructure, such as CI.  What's 
your opinion? Thanks very much
 
Best Wishes
zengchen

__
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


Hi Zengchen,


For now I was thinking just use Github and PR's outside of the OpenStack 
projects to bootstrap things and see how far we can get.  I'll update the BP 
this morning with what I believe to be the key tasks to work through.


Thanks,
John

__
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] [fuxi][kuryr] Where to commit codes for Fuxi-golang

2017-05-25 Thread zengchen
Very sorry to foget attaching the link for bp of rewriting Fuxi with go 
language.
https://blueprints.launchpad.net/fuxi/+spec/convert-to-golang




At 2017-05-25 19:46:54, "zengchen" <chenzeng...@163.com> wrote:

Hi guys:
hongbin had committed a bp of rewriting Fuxi with go language[1]. My 
question is where to commit codes for it.
We have two choice, 1. create a new repository, 2. create a new branch.  IMO, 
the first one is much better. Because
there are many differences in the layer of infrastructure, such as CI.  What's 
your opinion? Thanks very much
 
Best Wishes
zengchen__
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] [fuxi][kuryr] Where to commit codes for Fuxi-golang

2017-05-25 Thread zengchen
Hi guys:
hongbin had committed a bp of rewriting Fuxi with go language[1]. My 
question is where to commit codes for it.
We have two choice, 1. create a new repository, 2. create a new branch.  IMO, 
the first one is much better. Because
there are many differences in the layer of infrastructure, such as CI.  What's 
your opinion? Thanks very much
 
Best Wishes
zengchen__
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] [fuxi][stackube][kuryr] IRC meeting

2017-05-23 Thread zengchen
Hi Hongbin:
   I am very intresting to this topic. Can you give more details about it.
You said this topic may regarding to kuryr and stackube. I am not very 
understand the scope of this topic. Is this topic
going to talk about how to supply storage for K8S by Openstack in project of 
Stackube?
 
best wishes!
zengchen


At 2017-05-22 23:37:29, "Hongbin Lu" <hongbin...@huawei.com> wrote:


Hi all,

 

We will have an IRC meeting at UTC 1400-1500 Tuesday (2017-05-23). At the 
meeting, we will discuss the k8s storage integration with OpenStack. This 
effort might cross more than one teams (i.e. kuryr and stackube). You are more 
than welcomed to join us at #openstack-meeting-cp tomorrow.

 

Best regards,

Hongbin

 __
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 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" <jaypi...@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" <jaypi...@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" <jaypi...@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=*)
>>>>>>
>>>>>>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 

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


Re: [openstack-dev] [heat] A question on the endpoint of Heat

2016-12-20 Thread zengchen


Zane Bitter:
Thank you for your replay. I read the codes of Keystone by your reminding.  
Maybe the following codes can help us understand. Thanks again!



https://github.com/openstack/keystone/blob/master/keystone/common/utils.py#L633

https://github.com/openstack/keystone/blob/master/keystone/catalog/backends/templated.py#L68



cheers
zengchen






At 2016-12-20 22:22:17, "Zane Bitter" <zbit...@redhat.com> wrote:
>On 20/12/16 02:29, zengchen wrote:
>> Hi, Heat stackers:
>> May I ask a question about the endpoint of Heat. I see the endpoints
>> of Heat registered to Keystone look like this.
>> 'http://10.229.45.150:8004/v1/$(project_id)s' . My question is that why
>> use '$' instead of '%' as the replacement symbol.
>> Is there some kind of rule?
>
>Keystone supports either syntax. IIRC this one is slightly preferred. 
>It's really not important.
>
>- ZB
>
>
>__
>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-dev] [heat] A question on the endpoint of Heat

2016-12-19 Thread zengchen
Hi, Heat stackers:
May I ask a question about the endpoint of Heat. I see the endpoints of 
Heat registered to Keystone look like this.
'http://10.229.45.150:8004/v1/$(project_id)s' . My question is that why use '$' 
instead of '%' as the replacement symbol.
Is there some kind of rule? 


cheers
zengchen__
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] [heat] A question on creating Manila Share

2016-12-12 Thread zengchen
Rabi Mishra & Rico Lin:
Thanks very much for your reply! 
I have submitted a bug report at 
https://bugs.launchpad.net/heat/+bug/1649217, and will submit a patch to fix it 
later.


cheers
zengchen



在 2016-12-09 12:45:01,"Rabi Mishra" <ramis...@redhat.com> 写道:

Hi zengchen,

Yeah, the constraint looks incorrect. Not sure if we got it wrong or manila has 
changed it afterwards. It would be good raise a bug/propose a fix.




On Fri, Dec 9, 2016 at 8:26 AM, zengchen <chenzeng...@163.com> wrote:

Hi, Heat stackers:
May I ask a question about creating Manila Share. I see Heat define some 
constraints
 for property schema 'ACCESS_TYPE' at
 heat.engine.resources.openstack.manila.share.properties_schema[ACCESS_RULES].
 I copy the codes as bellow. The allowed values for 'ACCESS_TYPE' are  'ip', 
'domain'.
ACCESS_TYPE: properties.Schema(
properties.Schema.STRING,
_('Type of access that should be provided to guest.'),
constraints=[constraints.AllowedValues(
['ip', 'domain'])],
required=True
),
However, I see manila has defined different allowed value for 'ACCESS_TYPE', 
which
 includes 'ip', 'user', 'cert', 'cephx'. So, my question is does heat need some 
updates? Or
do I miss something?  Hope for your reply. Thanks very much!


cheers
zengchen



__
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





--

Regards,
Rabi Misra

__
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] [heat] A question on creating Manila Share

2016-12-08 Thread zengchen
Hi, Heat stackers:
May I ask a question about creating Manila Share. I see Heat define some 
constraints
 for property schema 'ACCESS_TYPE' at
 heat.engine.resources.openstack.manila.share.properties_schema[ACCESS_RULES].
 I copy the codes as bellow. The allowed values for 'ACCESS_TYPE' are  'ip', 
'domain'.
ACCESS_TYPE: properties.Schema(
properties.Schema.STRING,
_('Type of access that should be provided to guest.'),
constraints=[constraints.AllowedValues(
['ip', 'domain'])],
required=True
),
However, I see manila has defined different allowed value for 'ACCESS_TYPE', 
which
 includes 'ip', 'user', 'cert', 'cephx'. So, my question is does heat need some 
updates? Or
do I miss something?  Hope for your reply. Thanks very much!


cheers
zengchen

__
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] [Karbor] Questions about algorithm of building resource graph

2016-10-12 Thread zengchen


Hi karbor guys:


Yesterday, I had discussed this question with other guys on the weekly 
meeting. Maybe I have not described the question clearly.
Today, I discussed with chenying and reached an agreement with him. I update 
the question again in the attached file and hope for
the ideas from you. Please, take a look at it. Thanks very much!


zengchen





At 2016-10-11 09:06:33, "zengchen" <chenzeng...@163.com> wrote:

Hi karbor guys:


I have some questions about algorithm of building resource graph. I have 
described them in the attached file.
Any thoughts will be welcomed. Thanks very much!


zengchen

Questions about algorithm of building resource graph.pptx
Description: MS-Powerpoint 2007 presentation
__
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] [Karbor] Questions about algorithm of building resource graph

2016-10-10 Thread zengchen
Hi karbor guys:


I have some questions about algorithm of building resource graph. I have 
described them in the attached file.
Any thoughts will be welcomed. Thanks very much!


zengchen

Questions about algorithm of building resource graph.pptx
Description: MS-Powerpoint 2007 presentation
__
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