Open Stack

Hi Bob,

that's a good find. profileid as part of IEEE 802.1br needs to be in
binding:profile, and can be specified by a normal user, and later possibly
the pci_flavor. Would it be wrong to say something as in below in the
policy.json?
 "create_port:binding:vnic_type": "rule:admin_or_network_owner"
 "create_port:binding:profile:profileid": "rule:admin_or_network_owner"

If it's not appropriate, then I agree with you we may need another
extension. 


--Robert

On 1/29/14 4:57 PM, "Robert Kukura" <rkukura at redhat.com> wrote:

>On 01/29/2014 09:46 AM, Robert Li (baoli) wrote:
>
>> Another issue that came up during the meeting is about whether or not
>> vnic-type should be part of the top level binding or part of
>> binding:profile. In other words, should it be defined as
>> binding:vnic-type or binding:profile:vnic-type.
>
>I'd phrase that choice as "top-level attribute" vs. "key/value pair
>within the binding:profile attribute". If we go with a new top-level
>attribute, it may or may not end up being part of the portbindings
>extension.
>
>Although I've been advocating making vnic_type a key within
>binding:profile (minimizing effort), it just occurred to me that
>policy.json contains:
>
>    "create_port:binding:profile": "rule:admin_only",
>    "get_port:binding:profile": "rule:admin_only",
>    "update_port:binding:profile": "rule:admin_only",
>
>This means that only administrative users (including nova's integration
>with neutron) can read or write the binding:profile attribute by default.
>
>But my (limited) understanding of the PCI-passthru use cases is that
>normal users need to specify vnic_type because this is what determines
>the NIC type that their VMs see for the port. If that is correct, then I
>think this tips the balance towards vnic_type being a new top-level
>attribute to which normal users have read/write access. Comments?
>
>If I'm mistaken on the above, please ignore the rest of this email...
>
>If vnic_type is a new top-level attribute accessible to normal users,
>then I'm not sure it belongs in the portbindings extension. First,
>everything else in that extension is only visible to administrative
>users. Second, from the normal user's point of view, vnic_type has to do
>with the type of NIC they want within their VM, not with how the port is
>bound outside their VM to some underlying network segment and networking
>mechanism they aren't even aware of. So we need a new extension for
>vnic_type, which has the advantage of not requiring any change to
>existing plugins that don't support that extension.
>
>If vnic_type is a new top-level attribute in a new API extension, it
>deserves its own neutron BP covering defining the extension and
>implementing it in ML2. This is probably an update of Irena's
>https://blueprints.launchpad.net/neutron/+spec/ml2-request-vnic-type.
>Implementations for other plugins could follow via separate BPs as they
>choose to implement the extension.
>
>If anything else we've been planning to put in binding:profile needs
>normal user access, it could be defined in this new extension instead.
>For now, I'm assuming other input data for PCI-passthru (such as the
>slot info from nova) is only accessible to administrators and will go in
>binding:profile. I'll submit a separate BP for generically implementing
>the binding:profile attribute in ML2, as we've discussed.
>
>This leaves us with potentially 3 separate generic neutron/Ml2 BPs
>providing the infrastructure for PCI-passthru:
>
>1) Irena's
>https://blueprints.launchpad.net/neutron/+spec/ml2-request-vnic-type
>2) My BP to implement binding:profile in ML2
>3) Definition/implementation of binding:vif_details based on Nachi's
>binding:vif_security patch, for which I could submit a BP.
>
>-Bob
>