[openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th

Robert Kukura rkukura at redhat.com
Thu Jan 30 12:58:58 UTC 2014


On 01/30/2014 01:42 AM, Irena Berezovsky wrote:
> Please see inline
> 
>  
> 
> *From:*Ian Wells [mailto:ijw.ubuntu at 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 <rkukura at redhat.com
> <mailto:rkukura at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 




More information about the OpenStack-dev mailing list