Open Stack

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.

It seems to me that profileid is something that only make sense to an
administrator of the underlying cloud environment. Where would a normal
cloud user get a value to use for this?

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?

-Bob

> 
> 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
>>
>