On 01/30/2014 01:42 AM, Irena Berezovsky wrote: > Please see inline > > > > *From:*Ian Wells [mailto:ijw.ubu...@cack.org.uk] > *Sent:* Thursday, January 30, 2014 1:17 AM > *To:* OpenStack Development Mailing List (not for usage questions) > *Subject:* Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on > Jan. 29th > > > > On 29 January 2014 23:50, Robert Kukura <rkuk...@redhat.com > <mailto:rkuk...@redhat.com>> wrote: > > On 01/29/2014 05:44 PM, Robert Li (baoli) wrote: > > 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" > > Maybe, but a normal user that owns a network has no visibility into the > underlying details (such as the providernet extension attributes. > > > > I'm with Bob on this, I think - I would expect that vnic_type is passed > in by the user (user readable, and writeable, at least if the port is > not attached) and then may need to be reflected back, if present, in the > 'binding' attribute via the port binding extension (unless Nova can just > go look for it - I'm not clear on what's possible here). > > */[IrenaB] I would prefer not to add new extension for vnic_type. I > think it fits well into port binding extension, and it may be reasonable > to follow the policy rules as Robert suggested. The way user specifies > the vnic_type via nova API is currently left out for short term. Based > on previous PCI meeting discussions, it was raised by John that regular > user may be required to set vNIC flavor, but he definitely not expected > to manage ‘driver’ level details of the way to connect vNIC./* > > */For me it looks like neutron port can handle vnic_type via port > binding, and the question is whether it is standalone attribute on port > binding or a key,val pair on port binding:profile./*
I do not think we should try to associate different access policies with different keys within the binding:profile attribute (or any other dictionary attribute). We could consider changing the policy for binding:profile itself, but I'm not in favor of that because I strongly feel normal cloud users should not be exposed to any of these internal details of the deployment. If vnic_type does need to be accessed by normal users, I believe it should be a top-level attribute or a key/value pair within a user-accessible top-level attribute. -Bob > > > > > Also, would a normal cloud user really know what pci_flavor to use? > Isn't all this kind of detail hidden from a normal user within the nova > VM flavor (or host aggregate or whatever) pre-configured by the admin? > > > > Flavors are user-visible, analogous to Nova's machine flavors, they're > just not user editable. I'm not sure where port profiles come from. > -- > > Ian. > > > > > > _______________________________________________ > 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