Re: [openstack-dev] [Magnum] New Core Reviewers

[Grant, Jaycen V]

Thank you all for your support.  I look forward to being able to support the 
Magnum community in this new role.

Jaycen

-Original Message-
From: Yatin Karel [mailto:yatin.ka...@nectechnologies.in] 
Sent: Sunday, November 13, 2016 11:04 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: Re: [openstack-dev] [Magnum] New Core Reviewers

Hi All,

Thanks all for your votes and support for this new Role.

It is an honour to work with all of you and will continue my participation in 
the community.

Regards,
Yatin


From: Adrian Otto [adrian.o...@rackspace.com]
Sent: Monday, November 14, 2016 9:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum] New Core Reviewers

Jaycen and Yatin,

You have each been added as new core reviewers. Congratulations to you both, 
and thanks for stepping up to take on this new role!

Cheers,

Adrian

> On Nov 7, 2016, at 11:06 AM, Adrian Otto  wrote:
>
> Magnum Core Team,
>
> I propose Jaycen Grant (jvgrant) and Yatin Karel (yatin) as new Magnum Core 
> Reviewers. Please respond with your votes.
>
> Thanks,
>
> Adrian Otto


__
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] [Magnum] Microversioning implementation

[Grant, Jaycen V]

To be clear, the idea of the decorator and the base code comes from Nova, but 
it is not the Nova implementation. I didn't just copy the code over, that 
wouldn't have worked. What I liked from the Nova implementation was the 
decorator.  Vijendar and I went through several different projects(Ironic, 
Keystone, Nova, etc...) looking for examples of how we wanted to implement 
this. We POC'ed a couple of them to compare.  The decorator method of 
organizing and labeling was the one we liked best from a future development 
point of view. It kept the API code easy to read and easy to understand what 
code belonged to each microversion.  I took the structure and some of the code 
from Nova and then changed it to work for Pecan.  Nova's implementation was 
mixed into their WSGI code and we don't need to recreate that since we use 
pecan in magnum. So the concern of the complexity of the nova router is not 
really part of this. Take a look at the code review, I feel the code is not too 
complex and provides additional error checking that we would have to add to 
each method without it. 

Quick summary of how it works:
1) The decorators create a dictionary attaching method name to a list of 
available methods with version information.
2) That dictionary is added to the controller object
3) When a request comes in and Pecan selects the correct method needed for the 
API call, the controller  __getattribute__ call uses the dictionary to return 
the correct method based on the request version. It then returns the selected 
method and Pecan proceeds as before.

That said, if we really believe that we won't do more than a few microversion 
changes then I'll agreed that it might be not be critical that we have 
something like this. If that is what is decided, I can resubmit this with just 
the Version class updates and response header fixes. The microversion checking 
can then be done in each method as needed.

Jaycen


-Original Message-
From: taget [mailto:qiaoliy...@gmail.com] 
Sent: Thursday, July 28, 2016 6:46 PM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Magnum] Microversioning implementation

Hongbin & team

Please forget Semantic Versioning API, that should not be done in short term 
especially API WG had defined lots of Microversion API docs, sorry to make 
confusions.

Of cause that Microversion API is important to OpenStack, and it has documented 
well in API WG [1].
For Magnum, I remember that the implementation idea is from ironic [2], it is 
simple.

For [3] which comes from Nova is complex because that nova implement router 
itself, but Magnum
(Ironic) use pecan. We need to maintain it Magnum as well, also when I doing 
some testing, I still find some unexpected exception if passing bad 
Microversion, it should follow API WG.

At last Magnum has very few APIs entry point now, baymodel.py bay.py 
certificate.py magnum_services.py

Seen from Ironic, it has bump the version to v1.21 [2] with current Magnum's 
microversion's infra

I am okay to go with [3] as long as [3] fellows up with APIWG[1] and have 
better testing, I really don't want to maintain an infra which won't be used 
frequently.

[1] https://wiki.openstack.org/wiki/VersionDiscovery
[2] https://github.com/openstack/ironic/blob/master/doc/source/webapi/v1.rst
[3]
https://review.openstack.org/#/c/343060/8/magnum/api/controllers/v1/bay.py


On 2016年07月29日 03:19, Hongbin Lu wrote:
> OK. My replies are inline.
>
>> -Original Message-
>> From: Grant, Jaycen V [mailto:jaycen.v.gr...@intel.com]
>> Sent: July-28-16 2:31 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Magnum] Microversioning implementation
>>
>> I was completely unaware of any discussion of Semantic Versioning.
>> That was brought up by Eli Qiao in the code review, so he might be the
>> one to point us in the right direction for that.
>>
>> Jaycen
>>
>> -Original Message-
>> From: Hongbin Lu [mailto:hongbin...@huawei.com]
>> Sent: Thursday, July 28, 2016 11:10 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> <openstack-dev@lists.openstack.org>
>> Subject: Re: [openstack-dev] [Magnum] Microversioning implementation
>>
>> Added this to the agenda of next team meeting [1].
>>
>> I would like to ask clarification for " the community are discussing to
>> using Semantic Versioning(X.Y.Z) instead of microversion X.Y ". Could
>> anyone provide more information about that?
>>
>> Best regards,
>> Hongbin
>>
>>> -Original Message-
>>> From: Grant, Jaycen V [mailto:jaycen.v.gr...@intel.com]
>>> Sent: July-28-16 10:52 AM
>>> To: OpenStack Development Mailing List (not for usage questions)
>>> Subject: [openstack-dev] [Magnum] 

Re: [openstack-dev] [Magnum] Microversioning implementation

[Grant, Jaycen V]

I was completely unaware of any discussion of Semantic Versioning.  That was 
brought up by Eli Qiao in the code review, so he might be the one to point us 
in the right direction for that.

Jaycen

-Original Message-
From: Hongbin Lu [mailto:hongbin...@huawei.com] 
Sent: Thursday, July 28, 2016 11:10 AM
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject: Re: [openstack-dev] [Magnum] Microversioning implementation

Added this to the agenda of next team meeting [1].

I would like to ask clarification for " the community are discussing to using 
Semantic Versioning(X.Y.Z) instead of microversion X.Y ". Could anyone provide 
more information about that?

Best regards,
Hongbin

> -Original Message-----
> From: Grant, Jaycen V [mailto:jaycen.v.gr...@intel.com]
> Sent: July-28-16 10:52 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [Magnum] Microversioning implementation
> 
> 
> There has been a discussion around micro versioning implementation 
> going on in the following patch:
> https://review.openstack.org/#/c/343060/8 and I was asked to bring it 
> to the mailing list for further discussion.
> 
> Magnum added header support for microversioning according to the 
> Openstack spec[1] but since we haven’t had any changes yet it was not 
> being used.  In the patch mentioned above I added code that provides 
> infrastructure for implementing micro versions for our API methods.  I 
> took the idea from how Nova implemented micro versioning and used some 
> of their code modified to work with Pecan.  The basic idea is that you 
> version a method using api_version decorator as shown below:
> 
> @base.Controller.api_version("1.1")
> @expose.expose(BayCollection, types.uuid)
> def get_all(self, marker=None):
> """Retrieve a list of bays.
> # code for version 1.1
> 
> @base.Controller.api_version(“1.2”, “1.3") 
> @expose.expose(BayCollection,
> types.uuid) def get_all(self, marker=None):
> """Retrieve a list of bays.
> # code for versions 1.2 through 1.3
> 
> @base.Controller.api_version("1.4")
> @expose.expose(BayCollection, types.uuid) def get_all(self,
> marker=None):
> """Retrieve a list of bays.
> # code for version 1.4 to latest version
> 
> 
> The api_version code takes care of selecting the correct version based 
> on version requested in the header. It also checks for version 
> overlaps in the methods and gaps in the method versions.
> 
> 
> While working on this Vijendar(working on the first api changes that 
> need api versioning) and myself, evaluated several other alternatives:
> 
> 1) Just have each method check the version object and handle the 
> differences. This was the most basic solution and will work but we 
> were concerned it would add a lot of duplicate code. We were also 
> concerned it would be messy in the future as more and more micro 
> versions were added. Each method would now be responsible for 
> additional checking and more places to change code if there were 
> overall micro version code changes in the future.
> 
> 2) Separate pecan controllers for each micro version. When a new micro 
> version is added a new controller would be created inheriting from the 
> previous version controller. The new controller would override the 
> modified methods. Routing changes would be added to make sure that the 
> correct controller was used depending on the API header.  We felt that 
> the api_version decorator was slightly less complicated and less code 
> overhead on each api version change.
> 
> I’d appreciate feedback on whether this is the right way to go or if 
> it would be better to go to alternative option 1 or 2. Here were some 
> of the concerns by one of the cores in the code review:
> 
> I don't accept this patch, mark it as -2:
> Reason:
> 1. we have already support microversion in our code base, and your 
> propose (copied from nova) make things complicated.
> 2. I think you want to support "Support for async bay operations"
> for youadding microversion support, right?
> I would like suggest you as
> http://paste.openstack.org/show/543105/ , it should work for you
> 3. we don't have too may requirements to bump our microversion (I 
> know you want to use it in bay-creation async), so we don't want bring 
> much code here then we need to maintain it later.
> 4. the community are discussing to using Semantic 
> Versioning(X.Y.Z) [1] instead of microversion X.Y [1]http://semver.org/
>If you have any questions , please discuss it in mailing list or 
> weekly meeting.
>

[openstack-dev] [Magnum] Microversioning implementation

[Grant, Jaycen V]

There has been a discussion around micro versioning implementation going on in 
the following patch: https://review.openstack.org/#/c/343060/8 and I was asked 
to bring it to the mailing list for further discussion.  

Magnum added header support for microversioning according to the Openstack 
spec[1] but since we haven’t had any changes yet it was not being used.  In the 
patch mentioned above I added code that provides infrastructure for 
implementing micro versions for our API methods.  I took the idea from how Nova 
implemented micro versioning and used some of their code modified to work with 
Pecan.  The basic idea is that you version a method using api_version decorator 
as shown below:

@base.Controller.api_version("1.1")
@expose.expose(BayCollection, types.uuid)
def get_all(self, marker=None):
"""Retrieve a list of bays.
# code for version 1.1

@base.Controller.api_version(“1.2”, “1.3")
@expose.expose(BayCollection, types.uuid)
def get_all(self, marker=None):
"""Retrieve a list of bays.
# code for versions 1.2 through 1.3

@base.Controller.api_version("1.4")
@expose.expose(BayCollection, types.uuid)
def get_all(self, marker=None):
"""Retrieve a list of bays.
# code for version 1.4 to latest version


The api_version code takes care of selecting the correct version based on 
version requested in the header. It also checks for version overlaps in the 
methods and gaps in the method versions.


While working on this Vijendar(working on the first api changes that need api 
versioning) and myself, evaluated several other alternatives:

1) Just have each method check the version object and handle the differences. 
This was the most basic solution and will work but we were concerned it would 
add a lot of duplicate code. We were also concerned it would be messy in the 
future as more and more micro versions were added. Each method would now be 
responsible for additional checking and more places to change code if there 
were overall micro version code changes in the future.

2) Separate pecan controllers for each micro version. When a new micro version 
is added a new controller would be created inheriting from the previous version 
controller. The new controller would override the modified methods. Routing 
changes would be added to make sure that the correct controller was used 
depending on the API header.  We felt that the api_version decorator was 
slightly less complicated and less code overhead on each api version change.

I’d appreciate feedback on whether this is the right way to go or if it would 
be better to go to alternative option 1 or 2. Here were some of the concerns by 
one of the cores in the code review:

I don't accept this patch, mark it as -2:
Reason:
1. we have already support microversion in our code base, and your propose 
(copied from nova) make things complicated.
2. I think you want to support "Support for async bay operations" for you   
 adding microversion support, right?
I would like suggest you as http://paste.openstack.org/show/543105/ , it 
should work for you
3. we don't have too may requirements to bump our microversion (I know you 
want to use it in bay-creation async), so we don't want bring much code here 
then we need to maintain it later.
4. the community are discussing to using Semantic Versioning(X.Y.Z) [1] 
instead of microversion X.Y
[1]http://semver.org/
   If you have any questions , please discuss it in mailing list or weekly 
meeting.
   Eli.



Jaycen Grant
OSIC 




[1] 
http://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html?highlight=microversioning

>>
__
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] [Magnum] Select our project mascot/logo

[Grant, Jaycen V]

Stallion(horse) - think something like this: 
http://free-icon-download.com/modules/PDdownloads/singlefile.php?cid=11=44

Snake - http://www.freeiconspng.com/uploads/snake-jungle-22.png

Wave - http://www.123rf.com/photo_11649085_set-of-waves.html

Some ideas that come to mind.

Jaycen

From: Hongbin Lu [mailto:hongbin...@huawei.com]
Sent: Monday, July 25, 2016 3:55 PM
To: OpenStack Development Mailing List (not for usage questions) 

Subject: [openstack-dev] [Magnum] Select our project mascot/logo

Hi team,

OpenStack want to promote individual projects by choosing a mascot to represent 
the project. The idea is to create a family of logos for OpenStack projects 
that are unique, yet immediately identifiable as part of OpenStack. OpenStack 
will be using these logos to promote each project on the OpenStack website, at 
the Summit and in marketing materials.

We can select our own mascot, and then OpenStack will have an illustrator 
create the logo for us. The mascot can be anything from the natural world-an 
animal, fish, plant, or natural feature such as a mountain or waterfall. We 
need to select our top mascot candidates by the first deadline (July 27, this 
Wednesday). There's more info on the website: 
http://www.openstack.org/project-mascots

Action Item: Everyone please let me know what is your favorite mascot. You can 
either reply to this ML or discuss it in the next team meeting.

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