[openstack-dev] [Nova] v2 or v3 for new api
cbkyeoh at gmail.com
Tue Nov 18 00:09:23 UTC 2014
On Tue, Nov 18, 2014 at 2:31 AM, Pasquale Porreca <
pasquale.porreca at 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/
>> 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
> 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?
>> 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:
>> 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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev