On 01/31/2014 03:47 PM, Robert Kukura wrote: > On 01/29/2014 10:26 AM, Robert Kukura wrote: >> The neutron patch [1] and nova patch [2], proposed to resolve the >> "get_firewall_required should use VIF parameter from neutron" bug [3], >> replace the binding:capabilities attribute in the neutron portbindings >> extension with a new binding:vif_security attribute that is a dictionary >> with several keys defined to control VIF security. When using the ML2 >> plugin, this binding:vif_security attribute flows from the bound >> MechanismDriver to nova's GenericVIFDriver. >> >> Separately, work on PCI-passthru/SR-IOV for ML2 also requires >> binding-specific information to flow from the bound MechanismDriver to >> nova's GenericVIFDriver. See [4] for links to various documents and BPs >> on this. >> >> A while back, in reviewing [1], I suggested a general mechanism to allow >> ML2 MechanismDrivers to supply arbitrary port attributes in order to >> meet both the above requirements. That approach was incorporated into >> [1] and has been cleaned up and generalized a bit in [5]. >> >> I'm now becoming convinced that proliferating new port attributes for >> various data passed from the neutron plugin (the bound MechanismDriver >> in the case of ML2) to nova's GenericVIFDriver is not such a great idea. >> One issue is that adding attributes keeps changing the API, but this >> isn't really a user-facing API. Another is that all ports should have >> the same set of attributes, so the plugin still has to be able to supply >> those attributes when a bound MechanismDriver does not supply them. See [5]. >> >> Instead, I'm proposing here that the binding:vif_security attribute >> proposed in [1] and [2] be renamed binding:vif_details, and used to >> transport whatever data needs to flow from the neutron plugin (i.e. >> ML2's bound MechanismDriver) to the nova GenericVIFDriver. This same >> dictionary attribute would be able to carry the VIF security key/value >> pairs defined in [1], those needed for [4], as well as any needed for >> future GenericVIFDriver features. The set of key/value pairs in >> binding:vif_details that apply would depend on the value of >> binding:vif_type. > > I've filed a blueprint for this: > > https://blueprints.launchpad.net/neutron/+spec/vif-details
An initial patch implementing the vif-details BP is at https://review.openstack.org/#/c/72452/. We need to decide if this approach is acceptable in order to proceed with the SR-IOV and VIF security implementations. > > Also, for a similar flow of binding-related information into the > plugin/MechanismDriver, I've filed a blueprint to implement the existing > binding:profile attribute in ML2: > > https://blueprints.launchpad.net/neutron/+spec/ml2-binding-profile I should have a patch implementing the ml2-binding-profile BP tomorrow. -Bob > > Both of these are admin-only dictionary attributes on port. One is > read-only for output data, the other read-write for input data. Together > they enable optional features like SR-IOV PCI passthrough to be > implemented in ML2 MechanismDrivers without requiring feature-specific > changes to the plugin itself. > > -Bob > >> >> If this proposal is agreed to, I can quickly write a neutron BP covering >> this and provide a generic implementation for ML2. Then [1] and [2] >> could be updated to use binding:vif_details for the VIF security data >> and eliminate the existing binding:capabilities attribute. >> >> If we take this proposed approach of using binding:vif_details, the >> internal ML2 handling of binding:vif_type and binding:vif_details could >> either take the approach used for binding:vif_type and >> binding:capabilities in the current code, where the values are stored in >> the port binding DB table. Or they could take the approach in [5] where >> they are obtained from bound MechanismDriver when needed. Comments on >> these options are welcome. >> >> Please provide feedback on this proposal and the various options in this >> email thread and/or at today's ML2 sub-team meeting. >> >> Thanks, >> >> -Bob >> >> [1] https://review.openstack.org/#/c/21946/ >> [2] https://review.openstack.org/#/c/44596/ >> [3] https://bugs.launchpad.net/nova/+bug/1112912 >> [4] https://wiki.openstack.org/wiki/Meetings/Passthrough >> [5] https://review.openstack.org/#/c/69783/ >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
