Re: [openstack-dev] [Nova] v2 or v3 for new api

2014-11-17 Thread Pasquale Porreca
Thank you for the clarification, yes I know about the 
blueprint/specification, I submitted yet them and the spec is currently 
under review :)


I noticed there are several steps one has always to do to enable and 
make a v3 api to work and pass the tests. It would be awesome to have a 
guideline or something similar that explain these steps, but I didn't 
find anything in wiki or documentation.


In particular I noticed I had to modify the file 
nova/nova.egg-info/entry_points.txt to make my v3 api to load, but this 
file seems not to be under versioning, is this file modified only after 
the changes are merged?


On 11/16/14 23:55, Christopher Yeoh wrote:
On Thu, Nov 13, 2014 at 12:14 AM, Pasquale Porreca 
pasquale.porr...@dektech.com.au 
mailto:pasquale.porr...@dektech.com.au wrote:


Hello

I am working on an api for a new feature in nova, but I am
wondering what is the correct way to add a new extension: should
it be supported by v2, v3 or both?


You need now to have at least a v2.1 (formerly known as v3) extension. 
V2 support if you want but I think once v2.1 is fully merged and 
tested (which may not be that far away at all) we should freeze v2 and 
rely just on v2.1 for new features. Otherwise the interaction between 
v2.1 being exactly equivalent to v2 plus having microversion support 
for v2.1 will get a bit confusing.
As the other Chris mentioned, the first step however is to get a 
nova-spec submitted which needs to fully describe the API additions 
that you want to make.


Regards,

Chris

BR

-- 
Pasquale Porreca


DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805 tel:%2B39%203394823805
Skype paskporr


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] v2 or v3 for new api

2014-11-17 Thread Christopher Yeoh
On Mon, Nov 17, 2014 at 7:30 PM, Pasquale Porreca 
pasquale.porr...@dektech.com.au wrote:

  Thank you for the clarification, yes I know about the
 blueprint/specification, I submitted yet them and the spec is currently
 under review :)

 I noticed there are several steps one has always to do to enable and make
 a v3 api to work and pass the tests. It would be awesome to have a
 guideline or something similar that explain these steps, but I didn't find
 anything in wiki or documentation.


Yes, sorry documentation has been on our todo list for too long. Could I
get you to submit a bug report about the lack of developer documentation
for api plugins? It might hurry us up :-)

In the meantime, off the top of my head. you'll need to create or
modify the following files in a typical plugin:

setup.cfg - add an entry in at least the nova.api.v3.extensions section

etc/nova/policy.json - an entry for the permissions for you plugin, perhaps
one per api method for maximum flexibility. Also will need a discoverable
entry (lots of examples in this file)

nova/tests/unit/fake_policy.json (similar to policy.json)

nova/api/openstack/compute/plugins/v3/your_plugin.py - please make the
alias name something os-scheduler-hints rather than OS-SCH-HNTS. No
skimping on vowels. Probably the easiest way at this stage without more
doco is look for for a plugin in that directory that does the sort of the
thing you want to do.

nova/tests/unit/nova/api/openstack/compute/contrib/test_your_plugin.py - we
have been combining the v2 and v2.1(v3) unittests to share as much as
possible, so please do the same here for new tests as the v3 directory will
be eventually removed. There's quite a few examples now in that directory
of sharing unittests between v2.1 and v2 but with a new extension the
customisation between the two should be pretty minimal (just a bit of
inheritance to call the right controller)

nova/tests/unit/integrated/v3/test_your_plugin.py
nova/tests/unit/integrated/test_api_samples.py

Sorry the api samples tests are not unified yet. So you'll need to create
two. All of the v2 api sample tests are in one directory, whilst the the
v2.1 are separated into different files by plugin.

There's some rather old documentation on how to generate the api samples
themselves (hint: directories aren't made automatically) here:

https://blueprints.launchpad.net/nova/+spec/nova-api-samples

Personally I wouldn't bother with any xml support if you do decide to
support v2 as its deprecated anyway.

Hope this helps. Feel free to add me as a reviewer for the api parts of
your changesets.

Regards,

Chris



 In particular I noticed I had to modify the file
 nova/nova.egg-info/entry_points.txt to make my v3 api to load, but this
 file seems not to be under versioning, is this file modified only after the
 changes are merged?


 On 11/16/14 23:55, Christopher Yeoh wrote:

  On Thu, Nov 13, 2014 at 12:14 AM, Pasquale Porreca 
 pasquale.porr...@dektech.com.au wrote:

 Hello

 I am working on an api for a new feature in nova, but I am wondering what
 is the correct way to add a new extension: should it be supported by v2, v3
 or both?


  You need now to have at least a v2.1 (formerly known as v3) extension.
 V2 support if you want but I think once v2.1 is fully merged and tested
 (which may not be that far away at all) we should freeze v2 and rely just
 on v2.1 for new features. Otherwise the interaction between v2.1 being
 exactly equivalent to v2 plus having microversion support for v2.1 will get
 a bit confusing.

 As the other Chris mentioned, the first step however is to get a nova-spec
 submitted which needs to fully describe the API additions that you want to
 make.

  Regards,

  Chris

  BR

 --
 Pasquale Porreca

 DEK Technologies
 Via dei Castelli Romani, 22
 00040 Pomezia (Roma)

 Mobile +39 3394823805
 Skype paskporr


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




 ___
 OpenStack-dev mailing 
 listOpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 --
 Pasquale Porreca

 DEK Technologies
 Via dei Castelli Romani, 22
 00040 Pomezia (Roma)

 Mobile +39 3394823805
 Skype paskporr


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] v2 or v3 for new api

2014-11-17 Thread Pasquale Porreca

Thank you very much Christopher

On 11/17/14 12:15, Christopher Yeoh wrote:
Yes, sorry documentation has been on our todo list for too long. Could 
I get you to submit a bug report about the lack of developer 
documentation for api plugins? It might hurry us up :-)


I reported as a bug and subscribed you to it. 
https://bugs.launchpad.net/nova/+bug/1393455




In the meantime, off the top of my head. you'll need to create or 
modify the following files in a typical plugin:


setup.cfg - add an entry in at least the nova.api.v3.extensions section

etc/nova/policy.json - an entry for the permissions for you plugin, 
perhaps one per api method for maximum flexibility. Also will need a 
discoverable entry (lots of examples in this file)


nova/tests/unit/fake_policy.json (similar to policy.json)


I wish I had asked about this before, I found yet these files, but I 
confess it took quite a bit of time to guess I had to modify them (I 
actually didn't modify yet fake_policy, but my tests are still not 
completed).

What about nova/nova.egg-info/entry_points.txt I mentioned earlier?



nova/api/openstack/compute/plugins/v3/your_plugin.py - please make 
the alias name something os-scheduler-hints rather than OS-SCH-HNTS. 
No skimping on vowels. Probably the easiest way at this stage without 
more doco is look for for a plugin in that directory that does the 
sort of the thing you want to do.


Following the path of other plugins, I created a module 
nova/api/openstack/compute/plugins/v3/node_uuid.py, while the class is 
NodeUuid(extensions.V3APIExtensionBase) the alias is os-node-uuid and 
the actual json parameter is node_uuid. I hope this is correct...




nova/tests/unit/nova/api/openstack/compute/contrib/test_your_plugin.py 
- we have been combining the v2 and v2.1(v3) unittests to share as 
much as possible, so please do the same here for new tests as the v3 
directory will be eventually removed. There's quite a few examples now 
in that directory of sharing unittests between v2.1 and v2 but with a 
new extension the customisation between the two should be pretty 
minimal (just a bit of inheritance to call the right controller)




Very good to know. I put my test in 
nova/tests/unit/api/openstack/plugins/v3 , but I was getting confused by 
the fact only few tests were in this folder while the tests in 
nova/tests/unit/api/openstack/compute/contrib/ covered both v2 and v2.1 
cases.
So should I move my test in 
nova/tests/unit/api/openstack/compute/contrib/ folder, right?



nova/tests/unit/integrated/v3/test_your_plugin.py
nova/tests/unit/integrated/test_api_samples.py

Sorry the api samples tests are not unified yet. So you'll need to 
create two. All of the v2 api sample tests are in one directory, 
whilst the the v2.1 are separated into different files by plugin.


There's some rather old documentation on how to generate the api 
samples themselves (hint: directories aren't made automatically) here:


https://blueprints.launchpad.net/nova/+spec/nova-api-samples

Personally I wouldn't bother with any xml support if you do decide to 
support v2 as its deprecated anyway.


After reading your answer I understood I have to work more on this part :)



Hope this helps. Feel free to add me as a reviewer for the api parts 
of your changesets.


It helps a lot! I will add you for sure as soon as I will upload my 
code. For now the specification has still to be approved, so I think I 
have to wait before to upload it, is that correct?


This is the blueprint link anyway: 
https://blueprints.launchpad.net/nova/+spec/use-uuid-v1




Regards,

Chris


--
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] v2 or v3 for new api

2014-11-17 Thread Christopher Yeoh
On Tue, Nov 18, 2014 at 2:31 AM, Pasquale Porreca 
pasquale.porr...@dektech.com.au wrote:

 Thank you very much Christopher

 On 11/17/14 12:15, Christopher Yeoh wrote:

 Yes, sorry documentation has been on our todo list for too long. Could I
 get you to submit a bug report about the lack of developer documentation
 for api plugins? It might hurry us up :-)


 I reported as a bug and subscribed you to it. https://bugs.launchpad.net/
 nova/+bug/1393455


Thanks!



 In the meantime, off the top of my head. you'll need to create or
 modify the following files in a typical plugin:

 setup.cfg - add an entry in at least the nova.api.v3.extensions section

 etc/nova/policy.json - an entry for the permissions for you plugin,
 perhaps one per api method for maximum flexibility. Also will need a
 discoverable entry (lots of examples in this file)

 nova/tests/unit/fake_policy.json (similar to policy.json)


 I wish I had asked about this before, I found yet these files, but I
 confess it took quite a bit of time to guess I had to modify them (I
 actually didn't modify yet fake_policy, but my tests are still not
 completed).
 What about nova/nova.egg-info/entry_points.txt I mentioned earlier?


The entry points file is automatically updated based on setup.cfg



 nova/api/openstack/compute/plugins/v3/your_plugin.py - please make the
 alias name something os-scheduler-hints rather than OS-SCH-HNTS. No
 skimping on vowels. Probably the easiest way at this stage without more
 doco is look for for a plugin in that directory that does the sort of the
 thing you want to do.


 Following the path of other plugins, I created a module
 nova/api/openstack/compute/plugins/v3/node_uuid.py, while the class is
 NodeUuid(extensions.V3APIExtensionBase) the alias is os-node-uuid and the
 actual json parameter is node_uuid. I hope this is correct...


 nova/tests/unit/nova/api/openstack/compute/contrib/test_your_plugin.py -
 we have been combining the v2 and v2.1(v3) unittests to share as much as
 possible, so please do the same here for new tests as the v3 directory will
 be eventually removed. There's quite a few examples now in that directory
 of sharing unittests between v2.1 and v2 but with a new extension the
 customisation between the two should be pretty minimal (just a bit of
 inheritance to call the right controller)


 Very good to know. I put my test in nova/tests/unit/api/openstack/plugins/v3
 , but I was getting confused by the fact only few tests were in this folder
 while the tests in nova/tests/unit/api/openstack/compute/contrib/ covered
 both v2 and v2.1 cases.
 So should I move my test in nova/tests/unit/api/openstack/compute/contrib/
 folder, right?


Yes



  nova/tests/unit/integrated/v3/test_your_plugin.py
 nova/tests/unit/integrated/test_api_samples.py

 Sorry the api samples tests are not unified yet. So you'll need to create
 two. All of the v2 api sample tests are in one directory, whilst the the
 v2.1 are separated into different files by plugin.

 There's some rather old documentation on how to generate the api samples
 themselves (hint: directories aren't made automatically) here:

 https://blueprints.launchpad.net/nova/+spec/nova-api-samples

 Personally I wouldn't bother with any xml support if you do decide to
 support v2 as its deprecated anyway.


 After reading your answer I understood I have to work more on this part :)


 Hope this helps. Feel free to add me as a reviewer for the api parts of
 your changesets.


 It helps a lot! I will add you for sure as soon as I will upload my code.
 For now the specification has still to be approved, so I think I have to
 wait before to upload it, is that correct?

 This is the blueprint link anyway: https://blueprints.launchpad.
 net/nova/+spec/use-uuid-v1


So it won't hurt to upload the code before the spec is approved if you're
looking for some early feedback, but I'd recommend setting it to Work in
Progress otherwise it's likely to get -2'd pending spec approval

Regards,

Chris
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] v2 or v3 for new api

2014-11-16 Thread Christopher Yeoh
On Thu, Nov 13, 2014 at 12:14 AM, Pasquale Porreca 
pasquale.porr...@dektech.com.au wrote:

 Hello

 I am working on an api for a new feature in nova, but I am wondering what
 is the correct way to add a new extension: should it be supported by v2, v3
 or both?


You need now to have at least a v2.1 (formerly known as v3) extension. V2
support if you want but I think once v2.1 is fully merged and tested (which
may not be that far away at all) we should freeze v2 and rely just on v2.1
for new features. Otherwise the interaction between v2.1 being exactly
equivalent to v2 plus having microversion support for v2.1 will get a bit
confusing.

As the other Chris mentioned, the first step however is to get a nova-spec
submitted which needs to fully describe the API additions that you want to
make.

Regards,

Chris

BR

 --
 Pasquale Porreca

 DEK Technologies
 Via dei Castelli Romani, 22
 00040 Pomezia (Roma)

 Mobile +39 3394823805
 Skype paskporr


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Nova] v2 or v3 for new api

2014-11-14 Thread Chris Buccella
Do you have a blueprint for the new feature? If you want it accepted
upstream, you'll need a blueprint and spec:

https://wiki.openstack.org/wiki/Blueprints#Spec_.2B_Blueprints_lifecycle



On Wed, Nov 12, 2014 at 2:44 PM, Pasquale Porreca 
pasquale.porr...@dektech.com.au wrote:

 Hello

 I am working on an api for a new feature in nova, but I am wondering what
 is the correct way to add a new extension: should it be supported by v2, v3
 or both?

 BR

 --
 Pasquale Porreca

 DEK Technologies
 Via dei Castelli Romani, 22
 00040 Pomezia (Roma)

 Mobile +39 3394823805
 Skype paskporr


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [Nova] v2 or v3 for new api

2014-11-12 Thread Pasquale Porreca

Hello

I am working on an api for a new feature in nova, but I am wondering 
what is the correct way to add a new extension: should it be supported 
by v2, v3 or both?


BR

--
Pasquale Porreca

DEK Technologies
Via dei Castelli Romani, 22
00040 Pomezia (Roma)

Mobile +39 3394823805
Skype paskporr


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev