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" <rkuk...@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 > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev