Open Stack

Hi Bob,

Those are all good questions. But as with nova VM flavor, could profileid
be created by the admin, and then used by normal users? For the Icehouse
release, we won't have time to develop the profileid management API. I
think that next release we should have it available. Personally, I don't
like PCI flavor (which will be created by the admin as well), and I think
neutron may not need to use it at all unless a special use case warrants
it.  

For provider net, I see that a normal user can create a neutron net that
uses the provider net, but it doesn't have privilege to select a specific
vlan, which the admin does.

Those are just my thoughts, which may be wrong. And we can continue our
discussion tomorrow.

thanks,
Robert

On 1/29/14 5:50 PM, "Robert Kukura" <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.
>
>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
>>>
>> 
>