Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th
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
Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th
Hi folks, I'd like to do a recap on today's meeting, and if possible we should continue the discussion in this thread so that we can be more productive in tomorrow's meeting. Bob suggests that we have these BPs: One generic covering implementing binding:profile in ML2, and one specific to PCI-passthru, defining the vnic-type (wherever it goes) and any keys for binding:profile. Irena suggests that we have three BPs: 1. generic ML2 support for binding:profile (corresponding to Bob's covering implementing binding:profile in ML2 ?) 2. add vnic_type support for binding Mech Drivers in ML2 plugin 3. support PCI slot via profile (corresponding to Bob's any keys for binding:profile ?) Both proposals sound similar, so it's great that we are converging. I think that it's important that we put more details in each BP on what's exactly covered by it. One question I have is about where binding:profile will be implemented. I see that portbinding is defined/implemented under its extension and neutron.db. So when both of you guys are saying that implementing binding:profile in ML2, I'm kind of confused. Please let me know what I'm missing here. My understanding is that non-ML2 plugin can use it as well. 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. We also need one or two BPs to cover the change in the neutron port-create/port-show CLI/API. Another thing is that we need to define the binding:profile dictionary. Thanks, Robert On 1/29/14 4:02 AM, Irena Berezovsky ire...@mellanox.commailto:ire...@mellanox.com wrote: Will attend From: Robert Li (baoli) [mailto:ba...@cisco.com] Sent: Wednesday, January 29, 2014 12:55 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th Hi Folks, Can we have one more meeting tomorrow? I'd like to discuss the blueprints we are going to have and what each BP will be covering. thanks, Robert ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th
Hi Robert, I think that I can go with Bob's suggestion, but think it makes sense to cover the vnic_type and PCI-passthru via two separate patches. Adding vnic_type will probably impose changes to existing Mech. Drivers while PCI-passthru is about introducing some pieces for new SRIOV supporting Mech. Drivers. More comments inline BR, IRena From: Robert Li (baoli) [mailto:ba...@cisco.com] Sent: Wednesday, January 29, 2014 4:47 PM To: Irena Berezovsky; rkuk...@redhat.com; Sandhya Dasu (sadasu); OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th Hi folks, I'd like to do a recap on today's meeting, and if possible we should continue the discussion in this thread so that we can be more productive in tomorrow's meeting. Bob suggests that we have these BPs: One generic covering implementing binding:profile in ML2, and one specific to PCI-passthru, defining the vnic-type (wherever it goes) and any keys for binding:profile. Irena suggests that we have three BPs: 1. generic ML2 support for binding:profile (corresponding to Bob's covering implementing binding:profile in ML2 ?) 2. add vnic_type support for binding Mech Drivers in ML2 plugin 3. support PCI slot via profile (corresponding to Bob's any keys for binding:profile ?) Both proposals sound similar, so it's great that we are converging. I think that it's important that we put more details in each BP on what's exactly covered by it. One question I have is about where binding:profile will be implemented. I see that portbinding is defined/implemented under its extension and neutron.db. So when both of you guys are saying that implementing binding:profile in ML2, I'm kind of confused. Please let me know what I'm missing here. My understanding is that non-ML2 plugin can use it as well. [IrenaB] Basically you are right. Currently ML2 does not inherit the DB Mixin for port binding. So it supports the port binding extension, but uses its own DB table to store relevant attributes. Making it work for ML2 means not adding this support to PortBindingMixin. 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. [IrenaB] As long as existing binding capable Mech Drivers will take vnic_type into its consideration, I guess doing it via binding:profile will introduce less changes all over (CLI, API). But I am not sure this reason is strong enough to choose this direction We also need one or two BPs to cover the change in the neutron port-create/port-show CLI/API. [IrenaB] binding:profile is already supported, so it probably depends on direction with vnic_type Another thing is that we need to define the binding:profile dictionary. [IrenaB] With regards to PCI SRIOV related attributes, right? Thanks, Robert On 1/29/14 4:02 AM, Irena Berezovsky ire...@mellanox.commailto:ire...@mellanox.com wrote: Will attend From: Robert Li (baoli) [mailto:ba...@cisco.com] Sent: Wednesday, January 29, 2014 12:55 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th Hi Folks, Can we have one more meeting tomorrow? I'd like to discuss the blueprints we are going to have and what each BP will be covering. thanks, Robert ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th
Hi Irena, I'm now even more confused. I must have missed something. See inline…. Thanks, Robert On 1/29/14 10:19 AM, Irena Berezovsky ire...@mellanox.commailto:ire...@mellanox.com wrote: Hi Robert, I think that I can go with Bob’s suggestion, but think it makes sense to cover the vnic_type and PCI-passthru via two separate patches. Adding vnic_type will probably impose changes to existing Mech. Drivers while PCI-passthru is about introducing some pieces for new SRIOV supporting Mech. Drivers. More comments inline BR, IRena From: Robert Li (baoli) [mailto:ba...@cisco.com] Sent: Wednesday, January 29, 2014 4:47 PM To: Irena Berezovsky; rkuk...@redhat.commailto:rkuk...@redhat.com; Sandhya Dasu (sadasu); OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th Hi folks, I'd like to do a recap on today's meeting, and if possible we should continue the discussion in this thread so that we can be more productive in tomorrow's meeting. Bob suggests that we have these BPs: One generic covering implementing binding:profile in ML2, and one specific to PCI-passthru, defining the vnic-type (wherever it goes) and any keys for binding:profile. Irena suggests that we have three BPs: 1. generic ML2 support for binding:profile (corresponding to Bob's covering implementing binding:profile in ML2 ?) 2. add vnic_type support for binding Mech Drivers in ML2 plugin 3. support PCI slot via profile (corresponding to Bob's any keys for binding:profile ?) Both proposals sound similar, so it's great that we are converging. I think that it's important that we put more details in each BP on what's exactly covered by it. One question I have is about where binding:profile will be implemented. I see that portbinding is defined/implemented under its extension and neutron.db. So when both of you guys are saying that implementing binding:profile in ML2, I'm kind of confused. Please let me know what I'm missing here. My understanding is that non-ML2 plugin can use it as well. [IrenaB] Basically you are right. Currently ML2 does not inherit the DB Mixin for port binding. So it supports the port binding extension, but uses its own DB table to store relevant attributes. Making it work for ML2 means not adding this support to PortBindingMixin. [ROBERT] does that mean binding:profile for PCI can't be used by non-ml2 plugin? 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. [IrenaB] As long as existing binding capable Mech Drivers will take vnic_type into its consideration, I guess doing it via binding:profile will introduce less changes all over (CLI, API). But I am not sure this reason is strong enough to choose this direction We also need one or two BPs to cover the change in the neutron port-create/port-show CLI/API. [IrenaB] binding:profile is already supported, so it probably depends on direction with vnic_type [ROBERT] Can you let me know where in the code binding:profile is supported? in portbindings_db.py, the PortBindingPort model doesn't have a column for binding:profile. So I guess that I must have missed it. Regarding BPs for the CLI/API, we are planning to add vnic-type and profileid in the CLI, also the new keys in binding:profile. Are you saying no changes are needed (say display them, interpret the added cli arguments, etc), therefore no new BPs are needed for them? Another thing is that we need to define the binding:profile dictionary. [IrenaB] With regards to PCI SRIOV related attributes, right? [ROBERT] yes. Thanks, Robert On 1/29/14 4:02 AM, Irena Berezovsky ire...@mellanox.commailto:ire...@mellanox.com wrote: Will attend From: Robert Li (baoli) [mailto:ba...@cisco.com] Sent: Wednesday, January 29, 2014 12:55 AM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th Hi Folks, Can we have one more meeting tomorrow? I'd like to discuss the blueprints we are going to have and what each BP will be covering. thanks, Robert ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th
Hi Robert, Please see inline, I'll try to post my understanding. From: Robert Li (baoli) [mailto:ba...@cisco.com] Sent: Wednesday, January 29, 2014 6:03 PM To: Irena Berezovsky; rkuk...@redhat.com; Sandhya Dasu (sadasu); OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th Hi Irena, I'm now even more confused. I must have missed something. See inline Thanks, Robert On 1/29/14 10:19 AM, Irena Berezovsky ire...@mellanox.commailto:ire...@mellanox.com wrote: Hi Robert, I think that I can go with Bob's suggestion, but think it makes sense to cover the vnic_type and PCI-passthru via two separate patches. Adding vnic_type will probably impose changes to existing Mech. Drivers while PCI-passthru is about introducing some pieces for new SRIOV supporting Mech. Drivers. More comments inline BR, IRena From: Robert Li (baoli) [mailto:ba...@cisco.com] Sent: Wednesday, January 29, 2014 4:47 PM To: Irena Berezovsky; rkuk...@redhat.commailto:rkuk...@redhat.com; Sandhya Dasu (sadasu); OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th Hi folks, I'd like to do a recap on today's meeting, and if possible we should continue the discussion in this thread so that we can be more productive in tomorrow's meeting. Bob suggests that we have these BPs: One generic covering implementing binding:profile in ML2, and one specific to PCI-passthru, defining the vnic-type (wherever it goes) and any keys for binding:profile. Irena suggests that we have three BPs: 1. generic ML2 support for binding:profile (corresponding to Bob's covering implementing binding:profile in ML2 ?) 2. add vnic_type support for binding Mech Drivers in ML2 plugin 3. support PCI slot via profile (corresponding to Bob's any keys for binding:profile ?) Both proposals sound similar, so it's great that we are converging. I think that it's important that we put more details in each BP on what's exactly covered by it. One question I have is about where binding:profile will be implemented. I see that portbinding is defined/implemented under its extension and neutron.db. So when both of you guys are saying that implementing binding:profile in ML2, I'm kind of confused. Please let me know what I'm missing here. My understanding is that non-ML2 plugin can use it as well. [IrenaB] Basically you are right. Currently ML2 does not inherit the DB Mixin for port binding. So it supports the port binding extension, but uses its own DB table to store relevant attributes. Making it work for ML2 means not adding this support to PortBindingMixin. [ROBERT] does that mean binding:profile for PCI can't be used by non-ml2 plugin? [IrenaB] binding:profile is can be used by any plugin that supports binding extension. To persist the binding:profile (in the DB), plugin should add DB table for this . The PortBindingMixin does not persist the binding:profile for now. 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. [IrenaB] As long as existing binding capable Mech Drivers will take vnic_type into its consideration, I guess doing it via binding:profile will introduce less changes all over (CLI, API). But I am not sure this reason is strong enough to choose this direction We also need one or two BPs to cover the change in the neutron port-create/port-show CLI/API. [IrenaB] binding:profile is already supported, so it probably depends on direction with vnic_type [ROBERT] Can you let me know where in the code binding:profile is supported? in portbindings_db.py, the PortBindingPort model doesn't have a column for binding:profile. So I guess that I must have missed it. [IrenaB] For existing examples for supporting binding:profile by existing plugins you can look at two examples: https://github.com/openstack/neutron/blob/master/neutron/plugins/mlnx/mlnx_plugin.py - line 266https://github.com/openstack/neutron/blob/master/neutron/plugins/mlnx/mlnx_plugin.py%20-%20line%20266 https://github.com/openstack/neutron/blob/master/neutron/plugins/nec/nec_plugin.py - line 424https://github.com/openstack/neutron/blob/master/neutron/plugins/nec/nec_plugin.py%20-%20line%20424 Regarding BPs for the CLI/API, we are planning to add vnic-type and profileid in the CLI, also the new keys in binding:profile. Are you saying no changes are needed (say display them, interpret the added cli arguments, etc), therefore no new BPs are needed for them? [IrenaB] I think so. It should work bysetting on neutron port-create -binding:profile type=dict vnic_type=direct Another thing is that we need to define the binding:profile dictionary. [IrenaB] With regards to PCI SRIOV related attributes, right? [ROBERT
Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th
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
Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th
Hi Irena, With your reply, and after taking a close look at the code, I think that I understand it now. Regarding the cli change: neutron port-create –binding:profile type=dict vnic_type=direct following the neutron net-create —provider:physical_network as an example, --binding:* can be treated as unknown arguments. And they are opaquely transmitted to the neutron plugin for processing. I have always wondered why net-create help doesn't display the —provider:* arguments, and sometimes have to google the syntax. After taking look at the code, I think I kind of know what's going on out of there. I'd like to know why it's done that way. But I think that it will work for —binding:* in the neutron port-create commands. now regarding binding:profile for SR-IOV, from your google doc, it will have the following properties: pci_slot in the format of vendor_id:product_id:domain:bus:slot.fn. pci_flavor: will be a PCI flavor name when the API is available and it's desirable for neutron to use it. For now, it will be a physical network name. profileid: for 802.1qbh/802.1br vnic-type: it's still debatable whether or not this property belongs here. I kind of second you on making it binding:vnic-type. They all seem to be non plugin or MD specific. Of course, a MD that supports 802.1br would enforce profileid. But in terms of persisting them, I don't feel like they should be done in the plugin. On the other hand, the examples you gave me do show that these plugins are responsible for storing plugin-specific binding:profile in the DB. And in the case of —provider:* for neutron network, it's the individual plugins that persist it, and duplicate the code. Therefore, we may not have options other than following the existing examples. thanks, Robert On 1/29/14 12:17 PM, Irena Berezovsky ire...@mellanox.commailto:ire...@mellanox.com wrote: Hi Robert, Please see inline, I’ll try to post my understanding. From: Robert Li (baoli) [mailto:ba...@cisco.com] Sent: Wednesday, January 29, 2014 6:03 PM To: Irena Berezovsky; rkuk...@redhat.commailto:rkuk...@redhat.com; Sandhya Dasu (sadasu); OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th Hi Irena, I'm now even more confused. I must have missed something. See inline…. Thanks, Robert On 1/29/14 10:19 AM, Irena Berezovsky ire...@mellanox.commailto:ire...@mellanox.com wrote: Hi Robert, I think that I can go with Bob’s suggestion, but think it makes sense to cover the vnic_type and PCI-passthru via two separate patches. Adding vnic_type will probably impose changes to existing Mech. Drivers while PCI-passthru is about introducing some pieces for new SRIOV supporting Mech. Drivers. More comments inline BR, IRena From: Robert Li (baoli) [mailto:ba...@cisco.com] Sent: Wednesday, January 29, 2014 4:47 PM To: Irena Berezovsky; rkuk...@redhat.commailto:rkuk...@redhat.com; Sandhya Dasu (sadasu); OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th Hi folks, I'd like to do a recap on today's meeting, and if possible we should continue the discussion in this thread so that we can be more productive in tomorrow's meeting. Bob suggests that we have these BPs: One generic covering implementing binding:profile in ML2, and one specific to PCI-passthru, defining the vnic-type (wherever it goes) and any keys for binding:profile. Irena suggests that we have three BPs: 1. generic ML2 support for binding:profile (corresponding to Bob's covering implementing binding:profile in ML2 ?) 2. add vnic_type support for binding Mech Drivers in ML2 plugin 3. support PCI slot via profile (corresponding to Bob's any keys for binding:profile ?) Both proposals sound similar, so it's great that we are converging. I think that it's important that we put more details in each BP on what's exactly covered by it. One question I have is about where binding:profile will be implemented. I see that portbinding is defined/implemented under its extension and neutron.db. So when both of you guys are saying that implementing binding:profile in ML2, I'm kind of confused. Please let me know what I'm missing here. My understanding is that non-ML2 plugin can use it as well. [IrenaB] Basically you are right. Currently ML2 does not inherit the DB Mixin for port binding. So it supports the port binding extension, but uses its own DB table to store relevant attributes. Making it work for ML2 means not adding this support to PortBindingMixin. [ROBERT] does that mean binding:profile for PCI can't be used by non-ml2 plugin? [IrenaB] binding:profile is can be used by any plugin that supports binding extension. To persist the binding:profile (in the DB), plugin should add DB table for this . The PortBindingMixin does not persist the binding:profile
Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th
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
Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th
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 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
Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th
On 29 January 2014 23:50, Robert Kukura 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). 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
Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th
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 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. 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 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
Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 29th
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.commailto: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. 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] [nova][neutron] PCI pass-through SRIOV on Jan. 29th
Hi Folks, Can we have one more meeting tomorrow? I'd like to discuss the blueprints we are going to have and what each BP will be covering. thanks, Robert ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
