Group Based Policy

Refactor mapping extension to expose essential models

Registered by Ivar Lazzaro

This blueprint tracks a proposal to simplify the current GBP mapping extension in order to be compliant with most of the present/future Vendor Drivers and still satisfy most of the GBP use cases.

As is today, the mapping extension expose to the user the following model [GBP->Neutron: Permission]:

- PT -> Port: R/W
- PTG -> Subnet: R/W
- L2_Domain -> Netwotk: R/W
- L3_Domain -> Router: R/W

The proposed model will be simplified to the following:

- PT -> Port: RO
- PTG;
- L2_Domain;
- L3_Domain.

Note that the GBP model will still exist in the API, but the mapping is not exposed.

The above is all that is needed in order to make GBP work with Nova, and still covers most of the use cases (eg. it's not very likely for a user to manually specify a Network or a Router).
The advantage, besides simplicity, is that all the future drivers can use this as a common base so that the final user doesn't need to change his scripts when going from a driver to another.

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
Ivar Lazzaro
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

rkukura 10/9/14: I suggest we treat this BP as dependent on https://blueprints.launchpad.net/group-based-policy/+spec/gbp-extension-drivers, and use this BP to split the existing group-policy-mapping extension into a group-policy-base-mapping extension that is just readonly PT->port, and a group-policy-resource-mapping extension that includes the rest of the attributes used in the resource_mapping driver. The group-policy-resource-mapping extension would likely leave out the put and/or post support for the attributes for which the resource_mapping driver always raises exceptions, so that code can be eliminated. Other drivers can choose to use the group-policy-base-mapping and group-policy-resource-mapping extensions, the group-policy-base-mapping and their own specific mapping extensions, or just the group-policy-base-mapping extension.

ivar 10/9/14: Why do we need to have a group-policy-resource-mapping extension? Can't the current mapping_driver work with the group-policy-base-mapping extension alone?

rkukura 10/9/14: That is an option, but if access to the mapping details is useful, a driver-specific extension can provide it. Given that all of that is already implemented, it seems to make sense not to drop it unless we are sure its not needed. One case mapping details might be needed (at least until we automate it) is that users will likely need to manually add an external network to the router that is created for each L3P.

ivar 10/9/14: The code will not change, the API will just not expose that model. A proper cleanup can
be done in a later time. The reference implementation IMHO should provide the common abstraction that the user can always rely on. If we expose those mapping in the reference implementation we are setting a certain expectation for the user which is false (not all the drivers will rely on Neutron's mapping). As far as the external network is concerned, that is an Hack you need to do until we support external PTGs... I wouldn't build a use case around that! Moreover, a workaround exists since you can understand which router is connected to your network by indirection starting from the Port.

rkukura 10/13/14: Ivar, I'm not sure why you are now so adamant that the mapping to neutron resources should not be exposed, even for the resource_mapping driver. Completely dropping this from the API is a significant change from the initial model and design, and we'd need to have consensus within the team to make that change. Refactoring it into different extensions utilizing the extension driver framework is a less drastic change.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.