Extension definition of resource doesn't take uri prefix into account

[Brandon Logan]

When an extension is defined, it usually defines a dictionary that describes the new resources and the attributes of the body of the request. A prefix is also defined as a resource to prepend all resources in the extension. If two extensions define the same resource, but define different attributes of that resource then when a request is made to both resources, the expected attributes will be the union of both resources'.

For example:

ExtensionA defines its resources with this dictionary:

{"pools": {"id": {...}, "lb_method": {...}}

It has prefix of /lb

ExtensionB defines its resources with this dictionary:

{"pools": {"id": {...}, "lb_algorithm": {...}}

it has a prefix of /lbaas

When a POST request is made to /lb/pools and /lbaas/pools then the request MUST contain:

{"pool": {"lb_method": "SOME_METHOD", "lb_algorithm": "SOME_ALGORITHM"}}

The reason is because the extension loader does not take into account the prefix when it comes to loading the resources. The resources are loaded into a dictionary called attr_map and if attr_map already has a resource in it, it just calls an update on the dictionary, which is why both attributes end up being expected.

https://github.com/openstack/neutron/blob/master/neutron/api/extensions.py in extend_resources method.

[ugvddm (271025598-9)]

I can't find a good solution to solve this issue, maybe someone will, so I reopen it.

[Eugene Nikanorov (enikanorov)]

I think this can be closed as Invalid especially in the prospect of API layer refactoring planned for Kilo

[Launchpad Janitor (janitor)]

[Expired for neutron because there has been no activity for 60 days.]