yahoo-eng-team team mailing list archive

[Rodolfo Alonso <1673142@xxxxxxxxxxxxxxxxxx>]

Bug closed due to lack of activity, please feel free to reopen if
needed.

** Changed in: neutron
       Status: Triaged => Won't Fix

-- 
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:
  Won't Fix

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
  values, and then the binding is committed, that driver takes
  responsibility to reject future updates that change those attributes
  to 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