Open Stack

Hi,

We made a lot of progress today. We agreed that:
-- vnic_type will be a top level attribute as binding:vnic_type
-- BPs:
     * Irena's https://blueprints.launchpad.net/neutron/+spec/ml2-request-vnic-type for binding:vnic_type
     * Bob to submit a BP for binding:profile in ML2. SRIOV input info will be encapsulated in binding:profile
     * Bob to submit a BP for binding:vif_details in ML2. SRIOV output info will be encapsulated in binding:vif_details, which may include other information like security parameters. For SRIOV, vlan_id and profileid are candidates.
-- new arguments for port-create will be implicit arguments. Future release may make them explicit. New argument: --binding:vnic_type {virtio, direct, macvtap}.
I think that currently we can make do without the profileid as an input parameter from the user. The mechanism driver will return a profileid in the vif output.

Please correct any misstatement in above.

Issues:
  -- do we need a common utils/driver for SRIOV generic parts to be used by individual Mechanism drivers that support SRIOV? More details on what would be included in this sriov utils/driver? I'm thinking that a candidate would be the helper functions to interpret the pci_slot, which is proposed as a string. Anything else in your mind?

  -- what should mechanism drivers put in binding:vif_details and how nova would use this information? as far as I see it from the code, a VIF object is created and populated based on information provided by neutron (from get network and get port)

Questions:
  -- nova needs to work with both ML2 and non-ML2 plugins. For regular plugins, binding:vnic_type will not be set, I guess. Then would it be treated as a virtio type? And if a non-ML2 plugin wants to support SRIOV, would it need to  implement vnic-type, binding:profile, binding:vif-details for SRIOV itself?

 -- is a neutron agent making decision based on the binding:vif_type?  In that case, it makes sense for binding:vnic_type not to be exposed to agents.

Thanks,
Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140130/d31d6343/attachment.html>