yahoo-eng-team team mailing list archive

[Robert Kukura <1673142@xxxxxxxxxxxxxxxxxx>]

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