Public bug reported:
The ML2 core plugin implements certain API extensions through mix-in
classes, and allows additional API extensions to be implemented using
extension drivers. All of these extensions are then considered to be
"supported" by the plugin. But supporting an extension's API does not,
in itself, guarantee that the semantics a user requests using that API
will be supported and enforced by the applicable mechanism drivers.
One potential solution might be to require all mechanism drivers to
provide a property listing the extension aliases they support, and then
for the plugin to only claim to support those extensions supported by
all configured mechanism drivers. But this solution does not address
important use cases involving multiple mechanism drivers. For example,
an SR-IOV mechanism driver may not be able to enforce security groups
itself, so shouldn't claim to support that extension. But then security
groups wouldn't be available for non-SR-IOV ports either. This might be
resolved by the SR-IOV mechanism driver claiming to support security
groups, and refusing to bind when the list of security groups on the
port is not empty. But then what if a ToR switch mechanism driver could
support security groups? The SR-IOV mechanism driver should not have
know whether a specific ToR mechanism driver is part of the binding and
what its capabilities are. Furthermore, the ToR mechanism driver might
only be able to enforce certain kinds of security groups, so whether an
SR-IOV binding is valid might depend on the specific security group
rules applied to the port. And, unlike security groups or other mixed-in
extensions, those supported via configured extension drivers might not
even be meaningful to some of the configured mechanism drivers.
Requiring all mechanism drivers to understand and support all extensions
is clearly not a viable solution.
We therefore propose a more dynamic solution to ensure that the
semantics requested via extension APIs are enforced. This solution
prevents port bindings from being created unless the semantics expressed
through all configured extension APIs can be provided by that port
binding. This will result in invalid port bindings being passed over
until a valid one is found, or potentially in a failure to bind. It will
not address the harder problem of making Nova's scheduling of instances
take extension semantics into account, but will work in conjunction with
using Nova host aggregates to influence scheduling.
The proposed solution adds a method each to the ML2 ExtensionDriver and
MechanismDriver APIs. It does not require any change in Neutron APIs,
existing extension APIs, or any database schema. The driver base classes
will implement default versions of these methods, so existing drivers
will not be broken. After a potential port binding has been determined,
within the transaction that will commit the result, ML2 will perform a
new extension semantics validation phase.
For each registered extension driver, the
ExtensionDriver.validation_mode method will first be called, which will
return a "none", "one", or "all" value indicating what type of mechanism
driver validation is needed for that extension. This method can examine
the attribute values if needed to determine the mode. In the example
above, a security group extension driver would examine the port's
security_groups value and return "none" if there are no security groups
on the port, and "one" otherwise.
ML2's extension semantics validation then proceeds based on the
validation mode determined for that extension. If the validation mode is
"none", no further validation is needed for that extension. Otherwise,
the potential binding is validated by calling the
MechanismDriver.validate_extension method on the mechanism drivers
making up the potential binding. For an enforcement mode of "one",
validation proceeds from the bottom to top mechanism drivers until one
indicates it can enforce that extension's semantics by returning True.
For "all", each mechanism driver in the potential binding must indicate
it can it can enforce the semantics. In the example above, the
openvswitch or linuxbridge mechanism driver would always return True to
indicate it can enforce any security group semantics, an SR-IOV
mechanism driver would always return False to indicate it cannot enforce
any security group semantics, and a ToR switch mechanism driver might
have to examine the security group rules to determine whether it can
enforce them for that port.
If validation succeeds, the binding is committed. If not, the next
potential binding is tried. Note that when a mechanism driver claims it
can enforce the semantics for an extension based on the attribute value,
and then the binding is committed, it takes responsibility to reject
future changes to those values that it could no longer enforce.
Followup RFEs will be needed to implement enforcement of specific
extensions, such as security groups and QoS. These may require adding
extension drivers for extensions that are currently mixed-into the ML2
core plugin.
** Affects: neutron
Importance: Undecided
Status: New
** Tags: rfe
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1673142
Title:
[RFE][ML2] Enforce extension semantics
Status in neutron:
New
Bug description:
The ML2 core plugin implements certain API extensions through mix-in
classes, and allows additional API extensions to be implemented using
extension drivers. All of these extensions are then considered to be
"supported" by the plugin. But supporting an extension's API does not,
in itself, guarantee that the semantics a user requests using that API
will be supported and enforced by the applicable mechanism drivers.
One potential solution might be to require all mechanism drivers to
provide a property listing the extension aliases they support, and
then for the plugin to only claim to support those extensions
supported by all configured mechanism drivers. But this solution does
not address important use cases involving multiple mechanism drivers.
For example, an SR-IOV mechanism driver may not be able to enforce
security groups itself, so shouldn't claim to support that extension.
But then security groups wouldn't be available for non-SR-IOV ports
either. This might be resolved by the SR-IOV mechanism driver claiming
to support security groups, and refusing to bind when the list of
security groups on the port is not empty. But then what if a ToR
switch mechanism driver could support security groups? The SR-IOV
mechanism driver should not have know whether a specific ToR mechanism
driver is part of the binding and what its capabilities are.
Furthermore, the ToR mechanism driver might only be able to enforce
certain kinds of security groups, so whether an SR-IOV binding is
valid might depend on the specific security group rules applied to the
port. And, unlike security groups or other mixed-in extensions, those
supported via configured extension drivers might not even be
meaningful to some of the configured mechanism drivers. Requiring all
mechanism drivers to understand and support all extensions is clearly
not a viable solution.
We therefore propose a more dynamic solution to ensure that the
semantics requested via extension APIs are enforced. This solution
prevents port bindings from being created unless the semantics
expressed through all configured extension APIs can be provided by
that port binding. This will result in invalid port bindings being
passed over until a valid one is found, or potentially in a failure to
bind. It will not address the harder problem of making Nova's
scheduling of instances take extension semantics into account, but
will work in conjunction with using Nova host aggregates to influence
scheduling.
The proposed solution adds a method each to the ML2 ExtensionDriver
and MechanismDriver APIs. It does not require any change in Neutron
APIs, existing extension APIs, or any database schema. The driver base
classes will implement default versions of these methods, so existing
drivers will not be broken. After a potential port binding has been
determined, within the transaction that will commit the result, ML2
will perform a new extension semantics validation phase.
For each registered extension driver, the
ExtensionDriver.validation_mode method will first be called, which
will return a "none", "one", or "all" value indicating what type of
mechanism driver validation is needed for that extension. This method
can examine the attribute values if needed to determine the mode. In
the example above, a security group extension driver would examine the
port's security_groups value and return "none" if there are no
security groups on the port, and "one" otherwise.
ML2's extension semantics validation then proceeds based on the
validation mode determined for that extension. If the validation mode
is "none", no further validation is needed for that extension.
Otherwise, the potential binding is validated by calling the
MechanismDriver.validate_extension method on the mechanism drivers
making up the potential binding. For an enforcement mode of "one",
validation proceeds from the bottom to top mechanism drivers until one
indicates it can enforce that extension's semantics by returning True.
For "all", each mechanism driver in the potential binding must
indicate it can it can enforce the semantics. In the example above,
the openvswitch or linuxbridge mechanism driver would always return
True to indicate it can enforce any security group semantics, an SR-
IOV mechanism driver would always return False to indicate it cannot
enforce any security group semantics, and a ToR switch mechanism
driver might have to examine the security group rules to determine
whether it can enforce them for that port.
If validation succeeds, the binding is committed. If not, the next
potential binding is tried. Note that when a mechanism driver claims
it can enforce the semantics for an extension based on the attribute
value, and then the binding is committed, it takes responsibility to
reject future changes to those values that it could no longer enforce.
Followup RFEs will be needed to implement enforcement of specific
extensions, such as security groups and QoS. These may require adding
extension drivers for extensions that are currently mixed-into the ML2
core plugin.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1673142/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
