Re: [openstack-dev] [kuryr][kuryr-kubernetes] Propose to support Kubernetes Network Custom Resource Definition De-facto Standard Version 1

[Irena Berezovsky]

Sounds like a great initiative.

Lets follow up on the proposal by the kuryr-kubernetes blueprint.

BR,
Irena

On Wed, Jun 6, 2018 at 6:47 AM, Peng Liu  wrote:

> Hi Kuryr-kubernetes team,
>
> I'm thinking to propose a new BP to support  Kubernetes Network Custom
> Resource Definition De-facto Standard Version 1 [1], which was drafted by
> network plumbing working group of kubernetes-sig-network. I'll call it NPWG
> spec below.
>
> The purpose of NPWG spec is trying to standardize the multi-network effort
> around K8S by defining a CRD object 'network' which can be consumed by
> various CNI plugins. I know there has already been a BP VIF-Handler And Vif
> Drivers Design, which has designed a set of mechanism to implement the
> multi-network functionality. However I think it is still worthwhile to
> support this widely accepted NPWG spec.
>
> My proposal is to implement a new vif_driver, which can interpret the PoD
> annotation and CRD defined by NPWG spec, and attach pod to additional
> neutron subnet and port accordingly. This new driver should be mutually
> exclusive with the sriov and additional_subnets drivers.So the endusers can
> choose either way of using mult-network with kuryr-kubernetes.
>
> Please let me know your thought, any comments are welcome.
>
>
>
> [1] https://docs.google.com/document/d/1Ny03h6IDVy_e_vmElOqR
> 7UdTPAG_RNydhVE1Kx54kFQ/edit#heading=h.hylsbqoj5fxd
>
>
> Regards,
>
> --
> Peng Liu
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kuryr][libnetwork] Release kuryr-libnetwork 1.x for Queens

[Irena Berezovsky]

+1

On Fri, Jan 19, 2018 at 9:42 PM, Hongbin Lu  wrote:

> Hi Kuryr team,
>
> I think Kuryr-libnetwork is ready to move out of beta status. I propose to
> make the first 1.x release of Kuryr-libnetwork for Queens and cut a stable
> branch on it. What do you think about this proposal?
>
> Best regards,
> Hongbin
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kuryr] Nominate Kirill Zaitsev as kuryr-tempest-core reviewer

[Irena Berezovsky]

+1

On Wed, Jul 5, 2017 at 4:23 AM, Vikas Choudhary 
wrote:

> +1
>
> On Tue, Jul 4, 2017 at 7:59 PM, Antoni Segura Puimedon  > wrote:
>
>> On Tue, Jul 4, 2017 at 12:23 PM, Gal Sagie  wrote:
>> > +1
>> +1
>> >
>> > On Tue, Jul 4, 2017 at 12:28 PM, Daniel Mellado <
>> daniel.mellado...@ieee.org>
>> > wrote:
>> >>
>> >> Hi Team,
>> >>
>> >> I wanted to nominate Kirill for kuryr-tempest-core reviewer. He's been
>> a
>> >> great help from start both contributing and reviewing.
>> >>
>> >> Please voice your support or concerns if any
>> >>
>> >> Best!
>> >>
>> >> Daniel
>> >>
>> >> 
>> __
>> >> OpenStack Development Mailing List (not for usage questions)
>> >> Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> >
>> > --
>> > Best Regards ,
>> >
>> > The G.
>> >
>> > 
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe: openstack-dev-requ...@lists.op
>> enstack.org?subject:unsubscribe
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kuryr] Ocata cycle ending and proposing new people as Kuryr cores

[Irena Berezovsky]

On Fri, Jan 13, 2017 at 6:49 PM, Antoni Segura Puimedon 
wrote:

> Hi fellow kuryrs!
>
> We are getting close to the end of the Ocata and it is time to look back
> and appreciate the good work all the contributors did. I would like to
> thank you all for the continued dedication and participation in gerrit, the
> weekly meetings, answering queries on IRC, etc.
>
> I also want to propose two people that I think will help us a lot as core
> contributors in the next cycles.
>
> For Kuryr-lib and kuryr-libnetwork I want to propose Liping Mao. Liping
> has been contributing a lot of since Mitaka, not just in code but in
> reviews catching important details and fixing bugs. It is overdue that he
> gets to help us even more!
>
> +1

> For Kuryr-kubernetes I want to propose Ilya Chukhnakov. Ilya got into
> Kuryr at the end of the Newton cycle and has done a wonderful job in the
> Kubernetes integration contributing heaps of code and being an important
> part of the design discussions and patches. It is also time for him to
> start approving patches :-)
>
> +1

>
> Let's have the votes until next Friday (unless enough votes are cast
> earlier).
>
> Regards,
>
> Toni
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][dvr][fip] router support two external network

[Irena Berezovsky]

Hi,
The case you are describing may be related to the previously discussed RFE
[1].
Having additional networks with FIP range attached via router interface
should be allowed from the API point of view, but may need some adaptations
to make it work properly. Please see the details in the discussion log [1].

[1]  https://bugs.launchpad.net/neutron/+bug/1566191

BR,
Irena



On Sun, Nov 13, 2016 at 12:35 PM, Gary Kotton  wrote:

> Hi,
>
> Today the mapping is 1:1. So if you want additional mappinsg to internal
> networks then you can define more than one interface on your instance. Then
> map each interface to the relevant network.
>
> Thanks
>
> Gary
>
>
>
> *From: *huangdenghui 
> *Reply-To: *OpenStack List 
> *Date: *Saturday, November 12, 2016 at 10:26 AM
> *To: *OpenStack List 
> *Subject: *[openstack-dev] [neutron][dvr][fip] router support two
> external network
>
>
>
> Hi all
> Currently, neutron model supports one router with one external
> network, which is used to connect router to outside world. FIP can be
> allocated from external network which is gateway of a router. One private
> fixed ip of one port(usually it is a vm port ) can only associate one
> floating ip.  In some deployment scenario, all ports served by one router,
> all ports need ip address which can be accessed by intranet, and some ports
> need ip address which can be accessed by internet. I was wondering how
> neutron to resolve this kind of use cases? One idea is one router support
> two external network(one for intranet, the other one for internet, but only
> have gateway), the other idea is one router still have only one external
> network, but this external have two different type of subnet (one for
> internet, the other one for intranet). any comment is welcome. thanks.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kuryr] Spec and devref placement

[Irena Berezovsky]

I am fine with option (b) as well.
We can add option (d):
Specs in openstack/*kuryr-specs* but devrefs in each specific project,
i.e., the one that will end up with the implementation code.


On Mon, Sep 12, 2016 at 2:38 PM, Antoni Segura Puimedon 
wrote:

> Hi Kuryrs!
>
> On September 5th's weekly IRC meeting Irena Berezovsky suggested that
> we should take a decision regarding the location of specs and devrefs.
>
> Currently we default to putting all the specs and devrefs for:
> - Kuryr
> - Kuryr-libnetwork
> - Kuryr-kubernetes
>
> to openstack/kuryr. Fuxi is still being integrated and keeps its own doc.
>
> The three proposals that came up where:
> a) All specs and devrefs to openstack/kuryr
> b) Specs in openstack/kuryr but devrefs in each specific project,
> i.e., the one that will end up with the implementation code.
> c) Both specs and devrefs in each separate Kuryr project.
>
> I would like to advocate for option (b). It makes things easy for when
> specs involve multiple kuryr pieces and, at the same time, it keeps
> development information in the place where you'd expect, close to the
> code.
>
> Please, weigh on this issue here in the ML or in the weekly IRC
> meeting today. The idea is to reach a decision by next week's weekly
> IRC meeting and then write it in each subproject's "how to contribute"
>
> See you later in the weekly IRC,
>
> Toni
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kuryr] IPVLAN data path proposal

[Irena Berezovsky]

Hi Ivan,
The approach looks very interesting and seems to be reasonable effort to
make it work with kuryr as alternative to the 'VLAN aware VM' approach.
Having container presented as neutron entity has its value, especially for
visibility/monitoring (i.e mirroring) and security  (i.e applying security
groups).
But I do think that for short term, this approach is a good way to provide
Container in VM  support.
I  think it's worth to submit devref to kuryr to move forward.
BR,
Irena

On Mon, Sep 12, 2016 at 2:29 PM, Coughlan, Ivan 
wrote:

>
>
> *Overview*
>
> Kuryr proposes to address the issues of double encapsulation and exposure
> of containers as neutron entities when containers are running within VMs.
>
> As an alternative to the vlan-aware-vms and use of ovs within the VM, we
> propose to:
>
> -  Use allowed-address-pairs configuration for the VM neutron port
>
> -  Use IPVLAN for wiring the Containers within VM
>
>
>
> In this way:
>
> -  Achieve efficient data path to container within VM
>
> -  Better leverage OpenStack EPA(Enhanced Platform Awareness)
> features to accelerate the data path (more details below)
>
> -  Mitigate the risk of vlan-aware-vms not making neutron in time
>
> -  Provide a solution that works on existing and previous
> openstack releases
>
>
>
> This work should be done in a way permitting the user to optionally select
> this feature.
>
>
>
>
> *Required Changes*
>
> The four main changes we have identified in the current kuryr codebase are
> as follows:
>
> · Introduce an option of enabling “IPVLAN in VM” use case. This
> can be achieved by using a config file option or possibly passing a command
> line argument. The IPVLAN master interface must also be identified.
>
> · If using “IPVLAN in VM” use case, Kuryr should no longer create
> a new port in Neutron or the associated VEth pairs. Instead, Kuryr will
> create a new IPVLAN slave interface on top of the VM’s master interface and
> pass this slave interface to the Container netns.
>
> · If using “IPVLAN in VM” use case, the VM’s port ID needs to be
> identified so we can associate the additional IPVLAN addresses with the
> port. This can be achieved by querying Neutron’s show-port function and
> passing the VMs IP address.
>
> · If using “IPVLAN in VM” use case, Kuryr should associate the
> additional IPVLAN addresses with the VMs port. This can be achieved using
> Neutron’s allowed-address-pairs flag in the port-update function. We
> intend to make use of Kuryr’s existing IPAM functionality to request these
> IPs from Neutron.
>
>
>
> *Asks*
>
> We wish to discuss the pros and cons.
>
> For example, containers exposure as proper neutron entities and the
> utility of neutron’s allowed-address-pairs is not yet well understood.
>
>
>
> We also wish to understand if this approach is acceptable for kuryr?
>
>
>
>
>
> *EPA*
>
> The Enhanced Platform Awareness initiative is a continuous program to
> enable fine-tuning of the platform for virtualized network functions.
>
> This is done by exposing the processor and platform capabilities through
> the management and orchestration layers.
>
> When a virtual network function is instantiated by an Enhanced Platform
> Awareness enabled orchestrator, the application requirements can be more
> efficiently matched with the platform capabilities.
>
> http://itpeernetwork.intel.com/openstack-kilo-release-is-
> shaping-up-to-be-a-milestone-for-enhanced-platform-awareness/
>
> https://networkbuilders.intel.com/docs/OpenStack_EPA.pdf
>
> https://www.brighttalk.com/webcast/12229/181563/epa-
> features-in-openstack-kilo
>
>
>
>
>
> Regards,
>
> Ivan….
>
> --
> Intel Research and Development Ireland Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
>
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). Any review or distribution by others
> is strictly prohibited. If you are not the intended recipient, please
> contact the sender and delete all copies.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][qos] Question about behavior expectations if network policy is set

[Irena Berezovsky]

Mike,
As per QoS spec  [1], the behavior is:
``QoS policies could be applied:

   - Per network: All the ports plugged on the network where the QoS policy
   is

   applied get the policy applied to them.
   - Per port: The specific port gets the policy applied, when the port had
   any

   network policy that one is overridden.``

As David mentioned, empty policy is probably the way to deal with the case
that there is qos network policy defined, but for some reason specific port
should be kept without the policy.  There is an option to have certain port
types to be left without policy and you can define such behavior in the
plugin.
But anyway, this is not something that is reflected at the DB or Plugin
layer, and should be handled by the QoS backend driver.
[1]
https://specs.openstack.org/openstack/neutron-specs/specs/liberty/qos-api-extension.html

BR,
Irena

On Fri, Sep 2, 2016 at 11:58 AM, Shaughnessy, David <
david.shaughne...@intel.com> wrote:

> Hi Michael.
> When you update a network with a qos_policy_id it updates all ports on
> that network too [1].
> If you want to have a port on that network without any QoS features on it
> you can make a policy with no rules attached.
> This empty policy would override the networks QoS policy when it's
> attached to a port.
> Hope that answers your question.
> Regards.
> David.
>
> [1] https://github.com/openstack/neutron/blob/master/neutron/
> plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py#L427-L437
>
> -Original Message-
> From: Michael Micucci [mailto:micu...@midokura.com]
> Sent: Friday, September 2, 2016 8:28 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [Neutron][qos] Question about behavior
> expectations if network policy is set
>
>
> Hey all,
>
> Quick question: If I have a network and a port, and neither has any QOS
> policy set, and then I change the network to set the qos_policy_id, should
> this new QOS policy affect traffic on the already-created port?
> In other words, is this a network default for future ports (like with
> port_security_enabled) which would only affect ports created on this
> network from here on out (but leave already-created ports untouched)?
> Or is this a network setting which takes effect for all ports, regardless
> if they were already created or not?
>
> If the latter, the question had come up, this seems to mean that if a net
> policy is set, then there is no way a port can be set to have no policy,
> because if you unset a port's specific policy, it will fallback to the
> network policy, rather than skip policy calculations altogether.
> So, what does one do if they want all ports on a net to follow Policy X,
> EXCEPT for a single port?
>
> I would say the first question is the most important for me to understand
> the behavior, with the second question as a further clarification.
>
> Thanks a bunch!
>
> Sincerely,
>
> Michael Micucci
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> --
> Intel Research and Development Ireland Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
>
>
> This e-mail and any attachments may contain confidential material for the
> sole
> use of the intended recipient(s). Any review or distribution by others is
> strictly prohibited. If you are not the intended recipient, please contact
> the
> sender and delete all copies.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kuryr] Proposing vikasc for kuryr-libnetwork core

[Irena Berezovsky]

+1

On Wed, Aug 17, 2016 at 12:54 AM, Antoni Segura Puimedon  wrote:

> Hi Kuryrs,
>
> I would like to propose Vikas Choudhary for the core team for the
> kuryr-libnetwork subproject. Vikas has kept submitting patches and reviews
> at a very good rhythm in the past cycle and I believe he will help a lot to
> move kuryr forward.
>
> I would also like to propose him for the core team for the
> kuryr-kubernetes subproject since he has experience in the day to day work
> with kubernetes and can help with the review and refactoring of the
> prototype upstreaming.
>
> Regards,
>
> Antoni Segura Puimedon
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Kuryr] Docker failed to add an existed network with GW interface already created

[Irena Berezovsky]

Hi Liping Mao,


On Thu, May 26, 2016 at 12:31 PM, Liping Mao (limao) 
wrote:

> Hi Vikas, Antoni and Kuryr team,
>
> When I use kuryr, I notice kuryr will failed to add an existed
> network with gateway interface already created by neutron[1][2].
>
> The bug is because kuryr will create a neutron port for gw
> port in ipam_request_address.
>
> I think kuryr should not do actual create neutron gw port at all.
> Because CNM module do not have concept map with Neutron vRouter.
> Till now, user have to use neutron api to attach GW port in
> private network with vRouter. So I think the Kuryr should not
> actually create GW port.
>
> I think it possible to define via kuryr configuration file if kuryr should
create or not gw port. Kuryr already does it for DHCP port.

> What do you think? Thanks for any comments.
>
>
> [1] https://bugs.launchpad.net/kuryr/+bug/1584286
> [2] https://review.openstack.org/#/c/319524/4
>
>
>
> Regards，
> Liping Mao
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [nova] scheduling bandwidth resources / NIC_BW_KB resource class

[Irena Berezovsky]

On Wed, Apr 20, 2016 at 4:25 PM, Miguel Angel Ajo Pelayo <
majop...@redhat.com> wrote:

> Inline update.
>
> On Mon, Apr 11, 2016 at 4:22 PM, Miguel Angel Ajo Pelayo
>  wrote:
> > On Mon, Apr 11, 2016 at 1:46 PM, Jay Pipes  wrote:
> >> On 04/08/2016 09:17 AM, Miguel Angel Ajo Pelayo wrote:
> [...]
> >> Yes, Nova's conductor gathers information about the requested networks
> >> *before* asking the scheduler where to place hosts:
> >>
> >>
> https://github.com/openstack/nova/blob/stable/mitaka/nova/conductor/manager.py#L362
> >>
> >>>  That would require identifying that the port has a "qos_policy_id"
> >>> attached to it, and then, asking neutron for the specific QoS policy
> >>>   [3], then look out for a minimum bandwidth rule (still to be
> defined),
> >>> and extract the required bandwidth from it.
> >>
> >>
> >> Yep, exactly correct.
> >>
> >>> That moves, again some of the responsibility to examine and
> >>> understand external resources to nova.
> >>
> >>
> >> Yep, it does. The alternative is more retries for placement decisions
> >> because accurate decisions cannot be made until the compute node is
> already
> >> selected and the claim happens on the compute node.
> >>
> >>>  Could it make sense to make that part pluggable via stevedore?, so
> >>> we would provide something that takes the "resource id" (for a port in
> >>> this case) and returns the requirements translated to resource classes
> >>> (NIC_BW_KB in this case).
> >>
> >>
> >> Not sure Stevedore makes sense in this context. Really, we want *less*
> >> extensibility and *more* consistency. So, I would envision rather a
> system
> >> where Nova would call to Neutron before scheduling when it has received
> a
> >> port or network ID in the boot request and ask Neutron whether the port
> or
> >> network has any resource constraints on it. Neutron would return a
> >> standardized response containing each resource class and the amount
> >> requested in a dictionary (or better yet, an os_vif.objects.* object,
> >> serialized). Something like:
> >>
> >> {
> >>   'resources': {
> >> '': {
> >>   'NIC_BW_KB': 2048,
> >>   'IPV4_ADDRESS': 1
> >> }
> >>   }
> >> }
> >>
> >
> > Oh, true, that's a great idea, having some API that translates a
> > neutron resource, to scheduling constraints. The external call will be
> > still required, but the coupling issue is removed.
> >
> >
>
>
> I had a talk yesterday with @iharchys, @dansmith, and @sbauzas about
> this, and we believe the synthesis of resource usage / scheduling
> constraints from neutron makes sense.
>
> We should probably look into providing those details in a read only
> dictionary during port creation/update/show in general, in that way,
> we would not be adding an extra API call to neutron from the nova
> scheduler to figure out any of those details. That extra optimization
> is something we may need to discuss with the neutron community.
>
What about the caller context?
I believe these details should be  visible for admin user only.

>
>

> >> In the case of the NIC_BW_KB resource class, Nova's scheduler would
> look for
> >> compute nodes that had a NIC with that amount of bandwidth still
> available.
> >> In the case of the IPV4_ADDRESS resource class, Nova's scheduler would
> use
> >> the generic-resource-pools interface to find a resource pool of
> IPV4_ADDRESS
> >> resources (i.e. a Neutron routed network or subnet allocation pool)
> that has
> >> available IP space for the request.
> >>
> >
> > Not sure about the IPV4_ADDRESS part because I still didn't look on
> > how they resolve routed networks with this new framework, but for
> > other constraints makes perfect sense to me.
> >
> >> Best,
> >> -jay
> >>
> >>
> >>> Best regards,
> >>> Miguel Ángel Ajo
> >>>
> >>>
> >>> [1]
> >>>
> >>>
> http://lists.openstack.org/pipermail/openstack-dev/2016-February/086371.html
> >>> [2] https://bugs.launchpad.net/neutron/+bug/1560963
> >>> [3]
> >>>
> http://developer.openstack.org/api-ref-networking-v2-ext.html#showPolicy
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] BGP support

[Irena Berezovsky]

Hi Gary,
The new L2GW spec is [1] comes to enable inter-cloud connection to stretch
the network between the local and the remote clouds using tunnels between
border VTEP devices.
VTEP can be populated manually with remote MAC (optionally) IP entries.
BGP support is a bit orthogonal or may I say complementary.

[1] https://review.openstack.org/#/c/270786/

On Mon, Mar 28, 2016 at 9:36 AM, Gary Kotton  wrote:

> Hi,
> In the M cycle BGP support was added in tree. I have seen specs in the L2
> GW project for this support too. Are we planning to consolidate the
> efforts? Will the BGP code be moved from the Neutron git to the L2-GW
> project? Will a new project be created?
> Sorry, a little in the dark here and it would be nice if someone could
> please provide some clarity here. It would be a pity that there were
> competing efforts and my take would be that the Neutron code would be the
> single source of truth (until we decide otherwise).
> I think that the L2-GW project would be a very good place for that service
> code to reside. It can also have MPLS etc. support. So it may be a natural
> fit.
> Thanks
> Gary
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] rate-limit

[Irena Berezovsky]

Hi Andy,
(Adding neutron tag)
Please open an RFE bug under neutron and add qos tag. This will facilitate
the discussion of the use case feasibility.
Please join the QoS IRC meetings
https://wiki.openstack.org/wiki/Meetings/QoS.

BR,
Irena

On Mon, Mar 14, 2016 at 2:05 PM, Andy Wang  wrote:

> Hi All,
>
> I want to develop  feature rate-limit based on contrail-openstack context.
> My target is control rate of the sum of all the VMs int the one project or
> one tenant.
> I want to do it using linux TC. Is it feasible ?
> Is there one better idea for this ? Any suggestion is very appreciated.
>
> Thanks
> Andy Wang
>
>
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][TaaS] Possible points to be considered for TaaS Spec

[Irena Berezovsky]

Hi Reedip,
Please see my comments inline

On Tue, Mar 8, 2016 at 9:19 AM, reedip banerjee  wrote:

> While reading up the specs in [1] and [2], there are certain things which
> we may need to discuss before proceeding forward
>
> a) Reference point for Ingress/Egress traffic:
> There may be some confusion related to how we are labelling
> Ingress and Egress ( is it with respect to a VM, with a switch ,
> or any other entity).
> As we are looking from "Inside the VM" and not from "Inside the Network",
> that needs to be made clear.
>
I think it worth to be consistent with other neutron features, for example
with Security Groups

>
> b) How to perceive TaaS:
> In the section "Proposed Changes" Taas has been compared with a Core
> Neutron
> Plugin ( L3-Router) and a plugin which has emerged out of Neutron (
> Neutron LBaaS).
> This might cause confusion to the reviewers. It would be better that we
> decide
> how we would like to demonstrate TaaS:
> - Is it a plugin which can be integrated with the Neutron Core
> - Or is it an extension of the Core Neutron Services which can be used by
> selected users
>
> Based on the decision, we can modify the explanation to make the spec a
> bit more streamed.
>
I think it's advanced service adding value to the core neutron.

>
> c) Device Owner for TaaS:
> - If Tap Service creates a "destination" port, the port would have a
> device owner
> of the format of "network:tap"
> - If the "destination" port is now connected to a VM and the VM is booted
> up, nova
> changes the owner to "compute:nova"
>
Probably the difference will be if TaaS is allowed to remove this port or
not.

>
> # Is there any impact of the change of the device_owner
> # If there is an impact, should there be a change in nova so that the
> device_owner is not modified
> # When in the future, TaaS supports user providing an "already created
> port" should the device owner
> be checked and modified?
>
> d) Outcome of Deleting the VM where TaaS operates
> Following might be added to the Spec:
>
> 1. Deletion of the VM (and port attched to it) from which we were
> mirroring (source of the mirror):
> In this case we would do a cascade delete of the 'Tap_Flow' instances that
> were associated with the port that was deleted.
>
Are you sure you want to delete the Flow? Maybe it should reflect the
status of being not operational any more. I personally  do not think user
created resource should be deleted without explicit user operation.

>
> 2. Deletion of the VM (and port attched to it) to which we were mirroring
> (Destination of the mirror):
> In this case we would do a cascade delete of the 'Tap_Service' instance
> that was associated with the port that was deleted.
>
Same as previous comment.

>
> e) Making the API independent of OpenVSwitch
> As per our last discussion [3], it is better that w esplit our
> implementation for TaaS,
> so that
>  # the focus is not limited to OpenVSwitch, which may be a point of
> concern during review
>  # allow other vendors to create thier own pluggable implementation
>
+1

>
> f) Choice of Tapping before/after Sec Groups
>
> Security Groups can filter a lot , and implementing TaaS before or after
> the SG
> can impact the overall monitoring.
> As referenced in [1], we can provide this option as a future course of
> work, and
> in the meanwhile specify the option which we are working upon  ( Before or
> After)
> in the spec, to make it clear.
>
> I think it can be the TapFlow attribute, lets say 'position' that can be
either 'port' or 'vNIC'.
 *'vnic' *to capture ingress traffic after it passed inbound SG filters and
egress traffic before it passes outbound SG filters

'port' to capture ingress traffic before it passed inbound SG filters and
egress traffic after it passes outbound SG filters


>
> [1]:
> https://review.openstack.org/#/c/96149/8/specs/juno/tap-as-a-service.rst
> [2]:
> https://review.openstack.org/#/c/256210/5/specs/mitaka/tap-as-a-service.rst
> [3]:
> http://eavesdrop.openstack.org/meetings/taas/2016/taas.2016-03-02-06.33.log.txt
>
> --
> Thanks and Regards,
> Reedip Banerjee
> IRC: reedip
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [L2-Gateway] Install and Configuration issue

[Irena Berezovsky]

Hi Jason,
According to the L2GW config, it should be set as in this line:
https://github.com/openstack/networking-l2gw/blob/master/etc/l2gw_plugin.ini#L25

I think it should be working as default setting, but maybe you can try to
set this explicitly.

Hope it helps,
Irena

On Tue, Mar 8, 2016 at 12:33 PM, Jason Guy  wrote:

> Hi, I am trying to get the L2GW plugin working with my openstack setup. I
> did the installation from the git repo using setup.py install.
>
> I am having trouble getting the Neutron-server to take the plugin though.
> Here is the config line from the neutron.conf:
> # Plugins
> core_plugin = neutron.plugins.ml2.plugin.Ml2Plugin
> service_plugins =
> neutron.services.l3_router.l3_router_plugin.L3RouterPlugin,neutron.services.metering.metering_plugin.MeteringPlugin,networking_l2gw.services.l2gateway.plugin.L2GatewayPlugin
>
> After restarting neutron-server, I am getting this error in the
> neutron-server.log:
>
> INFO neutron.manager [req-b537d3d8-5ad5-419c-a7a0-133991af38fc - - - - -]
> Loading Plugin: networking_l2gw.services.l2gateway.plugin.L2GatewayPlugin
> ERROR neutron.services.service_base
> [req-b537d3d8-5ad5-419c-a7a0-133991af38fc - - - - -] No providers specified
> for 'L2GW' service, exiting
>
> I do not see anything in the install instructions regarding the
> neutron.conf configuration, so I am guessing at this point, hence the
> email. :) I have searched and tried to figure this out by looking at the
> code. What should the service_provider be set to?
>
> Thanks,
> Jason
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][tap-as-a-service] weekly meeting

[Irena Berezovsky]

On Wed, Nov 18, 2015 at 8:31 AM, Takashi Yamamoto 
wrote:

> hi,
>
> On Thu, Nov 12, 2015 at 2:11 AM, Vikram Hosakote (vhosakot)
>  wrote:
> > Hi,
> >
> > TAAS looks great for traffic monitoring.
> >
> > Some questions about TAAS.
> >
> > 1) Can TAAS be used for provider networks as well, or just for tenant
> > networks ?
>
> currently only for VM ports on tenant networks.
>
> >
> > 2) Will there be any performance impact is every neutron port and every
> > packet is mirrored/duplicated ?
>
> i guess per-port impact is negligible.
> there's definitely per-packet impacts.
> i don't have any numbers though.
>
> >
> > 3) How is TAAS better than a non-mirroring approaches like
> packet-sniffing
> > (wireshark/tcpdump) and tracking interface counters/metrics ?
>
> i think taas is richer but probably slower than them.
>
> >
> > 4) Is TAAS a legal/lawful way to intercept/duplicate customer traffic in
> a
> > production cloud ? Or, TAAS is used just for debugging/troubleshooting ?
>
> although i'm not sure about legal/lawful requirements,
> i guess taas can be used for such purposes.
>

You check this presentation for potential usage scenarios:


https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/tap-as-a-service-taas-port-monitoring-for-neutron-networks

>
> > I was not able to find answers for these questions in
> > https://etherpad.openstack.org/p/mitaka-neutron-unplugged-track.
> >
> > Thanks!
> >
> >
> > Regards,
> > Vikram Hosakote
> > vhosa...@cisco.com
> > Software Engineer
> > Cloud and Virtualization Group (CVG)
> > Cisco Systems
> > Boxborough MA USA
> >
> > From: Takashi Yamamoto 
> > Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> > 
> > Date: Tuesday, November 10, 2015 at 10:08 PM
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > 
> > Subject: [openstack-dev] [neutron][tap-as-a-service] weekly meeting
> >
> > hi,
> >
> > tap-as-a-service meeting will be held weekly, starting today.
> > http://eavesdrop.openstack.org/#Tap_as_a_Service_Meeting
> > anyone interested in the project is welcome.
> > sorry for immediate notice.
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [kuryr] Proposing Taku Fukushima as Kuryr core

[Irena Berezovsky]

+1


On Tue, Oct 13, 2015 at 5:07 PM, Gal Sagie  wrote:

> +1
>
> Taku is a great addition to the team and hoping to see him continue
> deliver high quality
> contribution in all aspects of the project.
>
> On Tue, Oct 13, 2015 at 4:52 PM, Antoni Segura Puimedon <
> toni+openstac...@midokura.com> wrote:
>
>> Hi fellow Kurýrs,
>>
>> I would like to propose Taku Fukushima for the core Kuryr team due to his
>> unparalleled dedication to the project. He has written most of the code
>> and
>> battled through the continuous libnetwork API changes. He will be a great
>> addition to the reviewing tasks.
>>
>> Current core members, please, cast your vote by tomorrow night.
>>
>> Regards,
>>
>> Toni
>>
>>
>
>
> --
> Best Regards ,
>
> The G.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] How could an L2 agent extension access agent methods ?

[Irena Berezovsky]

I would like to second  Kevin. This can be done in a similar way as ML2
Plugin passed plugin_context to ML2 Extension Drivers:
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/driver_api.py#L910
.

BR,
Irena

On Fri, Sep 25, 2015 at 11:57 AM, Kevin Benton  wrote:

> I think the 4th of the options you proposed would be the best. We don't
> want to give agents direct access to the agent object or else we will run
> the risk of breaking extensions all of the time during any kind of
> reorganization or refactoring. Having a well defined API in between will
> give us flexibility to move things around.
>
> On Fri, Sep 25, 2015 at 1:32 AM,  wrote:
>
>> Hi everyone,
>>
>> (TL;DR: we would like an L2 agent extension to be able to call methods on
>> the agent class, e.g. OVSAgent)
>>
>> In the networking-bgpvpn project, we need the reference driver to
>> interact with the ML2 openvswitch agent with new RPCs to allow exchanging
>> information with the BGP VPN implementation running on the compute nodes.
>> We also need the OVS agent to setup specific things on the OVS bridges for
>> MPLS traffic.
>>
>> To extend the agent behavior, we currently create a new agent by
>> mimicking the main() in ovs_neutron_agent.py but instead of instantiating
>> instantiate OVSAgent, with instantiate a class that overloads the OVSAgent
>> class with the additional behavior we need [1] .
>>
>> This is really not the ideal way of extending the agent, and we would
>> prefer using the L2 agent extension framework [2].
>>
>> Using the L2 agent extension framework would work, but only partially: it
>> would easily allos us to register our RPC consumers, but not to let us
>> access to some datastructures/methods of the agent that we need to use:
>> setup_entry_for_arp_reply and local_vlan_map, access to the OVSBridge
>> objects to manipulate OVS ports.
>>
>> I've filled-in an RFE bug to track this issue [5].
>>
>> We would like something like one of the following:
>> 1) augment the L2 agent extension interface (AgentCoreResourceExtension)
>> to give access to the agent object (and thus let the extension call methods
>> of the agent) by giving the agent as a parameter of the initialize method
>> [4]
>> 2) augment the L2 agent extension interface (AgentCoreResourceExtension)
>> to give access to the agent object (and thus let the extension call methods
>> of the agent) by giving the agent as a parameter of a new setAgent method
>> 3) augment the L2 agent extension interface (AgentCoreResourceExtension)
>> to give access only to specific/chosen methods on the agent object, for
>> instance by giving a dict as a parameter of the initialize method [4],
>> whose keys would be method names, and values would be pointer to these
>> methods on the agent object
>> 4) define a new interface with methods to access things inside the agent,
>> this interface would be implemented by an object instantiated by the agent,
>> and that the agent would pass to the extension manager, thus allowing the
>> extension manager to passe the object to an extension through the
>> initialize method of AgentCoreResourceExtension [4]
>>
>> Any feedback on these ideas...?
>> Of course any other idea is welcome...
>>
>> For the sake of triggering reaction, the question could be rephrased as:
>> if we submit a change doing (1) above, would it have a reasonable chance of
>> merging ?
>>
>> -Thomas
>>
>> [1]
>> https://github.com/openstack/networking-bgpvpn/blob/master/networking_bgpvpn/neutron/services/service_drivers/bagpipe/ovs_agent/ovs_bagpipe_neutron_agent.py
>> [2] https://review.openstack.org/#/c/195439/
>> [3]
>> https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/openvswitch/agent/extension_drivers/qos_driver.py#L30
>> [4]
>> https://github.com/openstack/neutron/blob/master/neutron/agent/l2/agent_extension.py#L28
>> [5] https://bugs.launchpad.net/neutron/+bug/1499637
>>
>> _
>>
>> Ce message et ses pieces jointes peuvent contenir des informations 
>> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu 
>> ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
>> electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou 
>> falsifie. Merci.
>>
>> This message and its attachments may contain confidential or privileged 
>> information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and 
>> delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been 
>> modified, changed or falsified.
>> Thank you.
>>
>>
>> __

[openstack-dev] [neutron][nova][qos] network QoS support driven by VM flavor/image requirements

[Irena Berezovsky]

I would like to start discussion regarding user experience when certain
level of network QoS is expected to be applied on VM ports. As you may know
basic networking QoS support was introduced during Liberty Release
following spec, Ref [1]
As it was discussed during last networking-QoS meeting, Ref [2], nova team
drives to the approach where neutron port is created with all required
settings and then VM is created with pre-created port  and not with
requested network. While this approach serves decoupling and separation of
compute and networking concerns, it will require smarter Client
orchestration and  we may loose some functionality we have today. One of
the usage scenarios that currently supported, is that Cloud Provider may
associate certain requirements with nova flavors. Once Tenant requests VM
for this flavor, nova (nova-scheduler) will make sure to fulfill the
requirements. Possible way to make this work for networking -qos is to set :
 nova-manage flavor set_key --name m1.small --key quota:vif_qos_policy
--value 

With current VM creation workflow  this will require nova to request
neutron to create port and apply qos policy with specified policy_id. This
will require changes on nova side.
I am not sure how to support the above user scenario with pre-created port
approach.

I would like to ask your opinion regarding the direction  for QoS in
particular, but the question is general for nova-neutron integration.
Should explicitly  decoupled networking/compute approach replace the
current way that nova delegates networking requirements to neutron.

BR,
Irena


[1]
http://specs.openstack.org/openstack/neutron-specs/specs/liberty/qos-api-extension.html
[2]
http://eavesdrop.openstack.org/meetings/neutron_qos/2015/neutron_qos.2015-09-16-14.02.log.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] PTL Non-Candidacy

[Irena Berezovsky]

Kyle,
Thank you for the hard work you did making neuron project and neutron
community  better!
You have been open and very supportive as a neutron community lead.
Hope you will stay involved.


On Fri, Sep 11, 2015 at 11:12 PM, Kyle Mestery  wrote:

> I'm writing to let everyone know that I do not plan to run for Neutron PTL
> for a fourth cycle. Being a PTL is a rewarding but difficult job, as Morgan
> recently put it in his non-candidacy email [1]. But it goes further than
> that for me. As Flavio put it in his post about "Being a PTL" [2], it's a
> full time job. In the case of Neutron, it's more than a full time job, it's
> literally an always on job.
>
> I've tried really hard over my three cycles as PTL to build a stronger web
> of trust so the project can grow, and I feel that's been accomplished. We
> have a strong bench of future PTLs and leaders ready to go, I'm excited to
> watch them lead and help them in anyway I can.
>
> As was said by Zane in a recent email [3], while Heat may have pioneered
> the concept of rotating PTL duties with each cycle, I'd like to highly
> encourage Neutron and other projects to do the same. Having a deep bench of
> leaders supporting each other is important for the future of all projects.
>
> See you all in Tokyo!
> Kyle
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074157.html
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/073986.html
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074242.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Kuryr - virtual sprint

[Irena Berezovsky]

Second or last week of September work for me

On Thu, Aug 20, 2015 at 3:22 PM, Antoni Segura Puimedon <
toni+openstac...@midokura.com> wrote:

>
>
> On Wed, Aug 19, 2015 at 11:50 PM, Salvatore Orlando <
> salv.orla...@gmail.com> wrote:
>
>> Hi Gal,
>>
>> even if I've been a lurker so far, I'm interested in attending for
>> learning and contributing to it with my massive bug-injecting skills!
>>
>> You said "virtual sprint" and "somewhere in september" - I think
>> "somewhere" refers to dates?
>> Anyway I am pretty much open to any date from September 7th onwards.
>>
>> Salvatore
>>
>>
>> On 19 August 2015 at 19:57, Gal Sagie  wrote:
>>
>>> Hello everyone,
>>>
>>> During our last meeting an idea was brought up that we try to do a
>>> virtual sprint
>>> for Kuryr somewhere in September.
>>>
>>> Basically the plan is very similar to the mid cycle sprints or feature
>>> sprints where
>>> we iterate on couple of tasks online and finish gaps we might have in
>>> Kuryr.
>>> (I think we are talking about 2-3 days)
>>>
>>
> Great Idea. I propose September 14th, 15th and 16th.
>
>
>>
>>> The agenda for the sprint is dependent on the amount of work we finish
>>> by then,
>>> but it will probably consist of containerising some of the common
>>> plugins and connecting
>>> things end to end. (for host networking)
>>>
>>> I started this email in order to find the best dates for it, so if you
>>> plan on participating
>>> please share your preferred dates (anyone that has a Neutron plugin
>>> might want to offer a containerised version of it with Kuryr to integrate
>>> with Docker and lib network and the sprint
>>> is probably a good place to start doing it)
>>>
>>> Thanks
>>> Gal.
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][bgpvpn] Service Plugin vs Service driver

[Irena Berezovsky]

Current VPNaaS Service Plugin inherits from VpnPluginRpcDbMixin, which is
not required for some vendor solutions, since L3 is implemented without
leveraging L3 Agents to manage router namespaces (ODL, MidoNet, etc).
I guess if Mixin usage will be changed to conditional RPC support based on
drivers requirements, follow what Salvatore suggested makes perfect sense.

On Wed, Aug 19, 2015 at 11:06 AM, Salvatore Orlando 
wrote:

> my 0.02€ on the matter inline.
>
> Regards,
> Salvatore
>
> On 18 August 2015 at 23:45, Mathieu Rohon  wrote:
>
>> hi brandon,
>>
>> thanks for your answer.
>>
>> my answers inline,
>>
>>
>>
>> On Tue, Aug 18, 2015 at 8:53 PM, Brandon Logan <
>> brandon.lo...@rackspace.com> wrote:
>>
>>> ​So let me make sure I understand this. You want to do a separate
>>> service plugin for what would normally be separate drivers under one
>>> service plugin.  The reasons for this are:
>>>
>>>
>>> 1. You dont want users the ability to choose the type, you want it
>>> always to be the same one
>>>
>> While in theory it is be possible to have multiple BGPVPN providers in
> the same deployment, there are control and data plane aspects that the
> service type framework at the moment cannot deal with it. Mathieu brought
> some examples in the bug report. The bottom line appears to be that the
> choice of the l3 service plugin (or whatever serves l3 in your deployment)
> also dictates the choiche of the BGPVPN service provider to employ.
>
>> 2. Some types do want to be the source of truth of the data stored,
>>> instead of it being the service plugin database.
>>>
>> This point has little to do with service types. It's about the fact that
> plugins are not required to implemented the various db mixins in neutron.db
> and therefore not required to use the neutron DB.
>
>>
>>> First, let me address the possibility of a solution using one service
>>> plugin and multiple drivers per type:
>>>
>>>
>>> I think that you can overcome #1 in the instantiation of the service
>>> plugin to check if there are more than 1 provider active, if so you can
>>> just throw an exception saying you can only have 1.  I'd have to look at it
>>> more to see if there are any caveats to this, but I think that would work.
>>>
>>>
>>> For #2, assuming #1 works, then the drivers that are defined can have
>>> some boolean that they set that will tell the plugin whether they are the
>>> source of truth or not, and depending on that you can store the data in the
>>> service plugin's db or just pass the data along, also pass GET requests to
>>> the drivers as well.
>>>
>>>
>> I agree that those workarounds will surely works but I wonder what is the
>> meaning of a service plugin/type that can only support one service
>> provider? can't the service plugin be the service provider directly?
>>
>
> I believe there is some value, but I am not able to quantify it at the
> moment.
> - A single service plugin also implies (more or less) a common user-facing
> APIs. I really don't want to end up in a conditons where the user API looks
> different (or the workflow is different) according to what's backing the
> neutron BGPVPN implementation
> - A single service plugin provides a commonplace for all the boilerplate
> management logic. This works for most drivers, but not for those who don't
> rely on neutron DB as a data source (unless you manage to build a
> sqlalchemy dialect for things such as opencontrail APIs, but I seriously
> doubt that it would be feasible)
> - Distinct service plugins might lead to different workflows. This is not
> necessarily a bad thing, because integration for some backends might need
> it. However this means that during review phase particular attention should
> be paid to ensure the behaviour of each service plugin respects the API
> specification.
>
>
>>
>> The reasons why I'm considering this change are :
>>
>> 1. I'm not sure we would have some use cases where we would be able to
>> choose one bgpvpn backend independently from the provider of the core
>> plugin (or a mech driver in the ML2 case) and/or the router plugin.
>> If one use ODL to manage its core resources, he won't be able to use
>> nuage or contrail to manage its bgpvpn connection.
>> The bgpvpn project is more about having a common API than having the
>> capacity to mix backends. At least for the moment.
>>
>
> I agree with this; but this problem exists regardless of whether you have
> a single service plugin with drivers or multiple service plugins. You are
> unlikely to be able to use the contrail BGPVPN service plugin is core and
> l3 are managed by ODL, I think.
>
>
>>
>> 2. I'm also considering that each plugin, which would be backend
>> dependent, could declare what features it supports through the use of
>> extensions.
>>
>
> Unfortunately extensions are the only way to declare supported
> capabilities at the moment. But please - don't end up allowing each service
> plugin exposing a different API.
>
>
>> Each plugin would be a "bgpvpn" service

Re: [openstack-dev] [neutron] Adding results to extension callbacks (ml2 port_update ext handling).

[Irena Berezovsky]

Hi Bob, Miguel

On Tue, Jul 14, 2015 at 5:19 PM, Robert Kukura 
wrote:

> I haven't had a chance to review this patch in detail yet, but am
> wondering if this is being integrated with ML2 as an extension driver? If
> so, that should clearly address how dictionaries are extended and input
> values are validated. If not, why?
>
This was my initial idea as well. But with this approach we had to split
QoS extension into two parts, once for QoS policies and rules managements
and other for QoS policy association with network/port.
The first one is realized by oS service plugin and the latter could be
realized as ML2 extension.
With current approach, QoS Plugin takes care of both parts. As Miguel
mentioned, the port/network QoS policy association information can be added
by enhancing current callback mechanism. It works fine when need to
propagate details from ML2 to the QoS Plugin for configuration, but lacks
support to add QoS policy details to port attributed when get_port is
invoked.
With approach we took, all QoS functionality managed by single plugin and
required less integration pieces in several places.

>
> -Bob
>
>
> On 7/13/15 10:50 PM, Miguel Angel Ajo wrote:
>
>> Inline reply (I've added to CC relevant people for ml2/plugin.py
>> port_update extension
>> handing -via git blame-) as they probably have an opinion here
>> (specially the last
>> two options).
>>
>> Kevin Benton wrote:
>>
>>> This sounds like a lot of overlap with the dict extend functions. Why
>>> weren't they adequate for the QoS use case?
>>>
>>
>> Let me explain, I believe Mike exceeded the proposal with AFTER_READ,
>> that's not the plan,
>> even if we could do as he proposed,
>>
>> AFTER_READ dict extension is just a temporary workaround until we have
>> a separate explicit
>> api @armax is working on. Making explicit that your service is going
>> to extend resources,
>> and handled that in an ordered way is a good thing.
>>
>> Afterwards, the source of this review has came from ML2 implementation of
>> AFTER_CREATE/AFTER_UPDATE notification for ports/nets.
>>
>> Let me explain:
>>
>>  As a decoupled, "mixinless" service extending core resources, we
>> need to do two things:
>>
>> 1) Extending the core resources as other extensions would do, adding
>> stuff to the port/network
>> dicts, here's where it comes the current AFTER_READ dict extension,
>> and future API making
>> that more explicit and more controlled.
>>
>> 2) Verifying the extended values we receive on core resources, by
>> registering to BEFORE_*
>> callbacks. For example, if a tenant is trying to use a qos_profile_id
>> he doesn't have access to,
>> or that doesn't exist, we can cancel the operation by throwing an
>> exception.
>>
>>   We need to extend the notifications for ports and networks, as
>> that's not notified currently.
>> Mike will work on that too in a separate patch.
>>
>>
>> 3) Taking the finally extended values and store associations in database
>>  (AFTER_UPDATE/AFTER_CREATE) so any later reads of the
>> port/network will get the right
>>  qos_profile_later in "after read".
>>
>>
>> We have found that AFTER_CREATE/AFTER_UPDATE happens at plugin level
>> (neutron/plugins/ml2/plugin.py / update_port) and that information
>> passed down is
>> very brief to our case (basically a "None" port if no ml2-know
>> attribute is changed), and
>> ml2 has to be aware of every single extension.
>>
>> Here there are two options:
>>a) we make ml2 also aware of qos_profile_id changes, complicating
>> the business logic down
>> there, or...
>>
>>b) we send the AFTER_CREATE/UPDATE events, and we listen to the
>> callback
>> listeners to such notification, and they will tell us if there's any
>> relevant field which must
>> be propagated down to agents. Then it's up to the agents to use such
>> field or not.
>>
>>
>>Mike's patch proposal is in the direction of (b), he's a long term
>> thinker, I was proposing him
>> to just go (a) for now, but let's discuss and find what's more right.
>>
>>
>>  On Mon, Jul 13, 2015 at 7:58 AM, Mike Kolesnik
>>> wrote:
>>>
>>>  Hi,

 I sent a simple patch to check the possibility to add results to
 callbacks:
 https://review.openstack.org/#/c/201127/

 This will allow us to decouple the callback logic from the ML2
 plugin in
 the QoS scenario where we need to update the agents in case the
 profile_id
 on a port/network changes.
 It will also allow for a cleaner way to extend resource attributes as
 AFTER_READ callbacks can return a dict of fields to add to the original
 resource instead of mutating it directly.

 Please let me know what you think of this idea.

 Regards,
 Mike



 __

 OpenStack Development Mailing List (not for usage questions)
 Unsubscribe:
 openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
 http://lists

Re: [openstack-dev] [Tricircle]Tricircle Weekly Team Meeting 2015.07.08 Roundup

[Irena Berezovsky]

Hi,
Thank you very much for posting the log. I had to leave this meeting
earlier.
I would love to participate and collaborate on any related item use
cases/requirements/design.

BR,
Irena

On Wed, Jul 8, 2015 at 5:49 PM, Zhipeng Huang  wrote:

> Hi Team,
>
> Thanks a lot for attending today's meeting. The meeting minutes could be
> found at
>
>
> http://eavesdrop.openstack.org/meetings/tricircle/2015/tricircle.2015-07-08-13.05.html
>
> And please find in the attachment for chatlog that had not been logged by
> meetbot.
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: huangzhip...@huawei.com
> Office: Huawei Industrial Base, Longgang, Shenzhen
>
> (Previous)
> Research Assistant
> Mobile Ad-Hoc Network Lab, Calit2
> University of California, Irvine
> Email: zhipe...@uci.edu
> Office: Calit2 Building Room 2402
>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] enriching port binding extension API dictionaries with key-values

[Irena Berezovsky]

Hi Andreas,

On Fri, Jun 26, 2015 at 4:04 PM, Andreas Scheuring <
scheu...@linux.vnet.ibm.com> wrote:

> Hi together,
> for a new ml2 plugin I would like to pass over some data from neutron to
> nova on port creation and update (exploiting port binding extension
> [1]). For my prototype I thought of using one of the following response
> dictionaries to add my information:
>
> - binding:vif_details
> - binding:profile
>
> The API ref describes these attributes (port create / port update - both
> response) as dictionaries, but without restricting the key-value pairs
> or naming a defined number [1].
>
binding:profile is an input dictionary, that should tell neutron how to
bind the port.
binding:vif_details is an output dictionary that should provide nova  (or
other) with enough details to plug the port properly.

>
> I've also seen some other ml2 plugins enriching those fields with unique
> data. So I assuming this is not considered as an API change, isn't it?
>
> Important: It's only about the response. The input comes from a
> configuration file.
>
>
> Thanks
>
>
> [1] http://developer.openstack.org/api-ref-networking-v2-ext.html
>
>
> --
> Andreas
> (IRC: scheuran)
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Modular L2 Agent

[Irena Berezovsky]

On Mon, Jun 22, 2015 at 7:48 PM, Sean M. Collins  wrote:

> On Mon, Jun 22, 2015 at 10:47:39AM EDT, Salvatore Orlando wrote:
> > I would probably start with something for enabling the L2 agent to
> process
> > "features" such as QoS and security groups, working on the OVS agent, and
> > then in a second step abstract a driver interface for communicating with
> > the data plane. But I honestly do not know if this will keep the work too
> > "OVS-centric" and therefore won't play well with the current efforts to
> put
> > linux bridge on par with OVS in Neutron. For those question we should
> seek
> > an answer from our glorious reference control plane lieutenant, and
> perhaps
> > also from Sean Collins, who's coordinating efforts around linux bridge
> > parity.
>
> I think that what Salvatore has suggested is good. If we start creating
> good API contracts, and well defined interfaces in the reference control
> plane agents - this is a good first step. Even if we start off by doing
> this just for the OVS agent, that'll be a good template for what we
> would need to do for any agent-driven L2 implementation - and it could
> easily be re-used by others.
>
> To be honest, if you squint hard enough there really are very few
> differences between the OVS agent and the Linux Bridge agent does -
> the parts that handle control plane communication, processing
> data updates, and so forth should all be very similar.
>
> They only become different at the lower
> levels where it's brctl/ip2 vs. ovs-vsctl/of-ofctl CLI calls - so why
> maintain two separate agent implementations when quite a bit of what
> they do is functionally identical?
>

As Miguel mentioned, the patch [1] adds support for QoS driver in L2
Agents. Since QoS support is planned to be leveraged by OVS and SR-IOV and
maybe later by Linux Bridge, the idea is to make common L2Agent layer to
enable generic support for features (extensions) and QoS as the first
feature to support. This is not the Modular L2 Agent, but definitely the
step into the right direction.
This work should have minimal impact on Server side, and mostly about code
reuse by L2 Agents.

[1] https://review.openstack.org/#/c/189723/

BR,
Irena

> --
> Sean M. Collins
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Regarding Flow Classifier proposals for Liberty!

[Irena Berezovsky]

Hi Vikram,
Agree with what you stated. Additional use case can be Tap as a Service to
allow filtering of the mirrored packets.

BR,
Irena

On Fri, Jun 5, 2015 at 11:47 AM, Vikram Choudhary <
vikram.choudh...@huawei.com> wrote:

>  Dear All,
>
>
>
> There are multiple proposal floating around flow classifier rules for
> Liberty [1], [2] and [3].
>
> I feel we all should work together and try to address all our use case
> having a unified framework rather than working separately achieving the
> same  goal.
>
>
>
> Moreover, I can find the proposal for flow classifier as defined by the
> existing SFC [2] proposal is too generic and could address all the use
> cases by minor extension’s.
>
>
>
> In this regard, I would like all to come forward, exchange their thoughts,
> work together and make it happen good the first go rather doing the same
> effort separately and end up in duplicating code & effort L.
>
> I always feel less code will make our life happy in the long run ;)
>
>
>
> Please let me know about your views.
>
>
>
> [1] Add Neutron API extensions for packet forwarding
>
>   https://review.openstack.org/#/c/186663/
>
>
>
> [2] Neutron API for Service Chaining [Flow Filter resource]
>
>
> https://review.openstack.org/#/c/177946/6/specs/liberty/neutron-api-for-service-chaining.rst
>
>
>
> [3] QoS API Extension [Defines classifier rule in QoSRule. Classifier
> rule can really grow big in the long run]:
>
>
> https://review.openstack.org/#/c/88599/10/specs/liberty/qos-api-extension.rst
>
>
>
> Thanks
>
> Vikram
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Progressing/tracking work on libvirt / vif drivers

[Irena Berezovsky]

Hi Ian,
I like your proposal. It sounds very reasonable and makes separation of
concerns between neutron and nova very clear. I think with vif plug script
support [1]. it will help to decouple neutron from nova dependency.
Thank you for sharing this,
Irena
[1] https://review.openstack.org/#/c/162468/

On Tue, Jun 2, 2015 at 10:45 AM, Ian Wells  wrote:

> VIF plugging, but not precisely libvirt VIF plugging, so I'll tout this to
> a hopefully interested audience.
>
> At the summit, we wrote up a spec we were thinking of doing at [1].  It
> actually proposes two things, which is a little naughty really, but hey.
>
> Firstly we propose that we turn binding into a negotiation, so that Nova
> can offer binding options it supports to Neutron and Neutron can pick the
> one it likes most.  This is necessary if you happen to use vhostuser with
> qemu, as it doesn't work for some circumstances, and desirable all around,
> since it means you no longer have to configure Neutron to choose a binding
> type that Nova likes and Neutron can choose different binding types
> depending on circumstances.  As a bonus, it should make inter-version
> compatibility work better.
>
> Secondly we suggest that some of the information that Nova and Neutron
> currently calculate independently should instead be passed from Neutron to
> Nova, simplifying the Nova code since it no longer has to take an educated
> guess at things like TAP device names.  That one is more contentious, since
> in theory Neutron could pass an evil value, but if we can find some pattern
> that works (and 'pattern' might be literally true, in that you could get
> Nova to confirm that the TAP name begins with a magic string and is not
> going to be a physical device or other interface on the box) I think that
> would simplify the code there.
>
> Read, digest, see what you think.  I haven't put it forward yet (actually
> I've lost track of which projects take specs at this point) but I would
> very much like to get it implemented and it's not a drastic change (in
> fact, it's a no-op until we change Neutron to respect what Nova passes).
>
> [1] https://etherpad.openstack.org/p/YVR-nova-neutron-binding-spec
>
> On 1 June 2015 at 10:37, Neil Jerram  wrote:
>
>> On 01/06/15 17:45, Neil Jerram wrote:
>>
>>  Many thanks, John & Dan.  I'll start by drafting a summary of the work
>>> that I'm aware of in this area, at
>>> https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work.
>>>
>>
>> OK, my first draft of this is now there at [1].  Please could folk with
>> VIF-related work pending check that I haven't missed or misrepresented
>> them?  Especially, please could owners of the 'Infiniband SR-IOV' and
>> 'mlnx_direct removal' changes confirm that those are really ready for core
>> review?  It would be bad to ask for core review that wasn't in fact wanted.
>>
>> Thanks,
>> Neil
>>
>>
>> [1] https://etherpad.openstack.org/p/liberty-nova-libvirt-vif-work
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] [QoS] weekly meeting - update

[Irena Berezovsky]

Hi,

This week neutron QoS meeting will take place on Tuesday, April 21 at 14:00
UTC on #openstack-meeting-3.

Next week, the meeting is back to its original slot: Wed at 14:00 UTC on
#openstack-meeting-3.

Please join if you are interested.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [QoS] QoS weekly meeting

[Irena Berezovsky]

Hi Miguel,
Thank you for leading this.


On Tue, Apr 7, 2015 at 8:45 AM, Miguel Ángel Ajo 
wrote:

> On Tuesday, 7 de April de 2015 at 3:14, Kyle Mestery wrote:
>
> On Mon, Apr 6, 2015 at 6:04 PM, Salvatore Orlando 
> wrote:
>
>
>
> On 7 April 2015 at 00:33, Armando M.  wrote:
>
>
> On 6 April 2015 at 08:56, Miguel Ángel Ajo  wrote:
>
>  I’d like to co-organized a QoS weekly meeting with Sean M. Collins,
>
> In the last few years, the interest for QoS support has increased,
> Sean has been leading
> this effort [1] and we believe we should get into a consensus about how to
> model an extension
> to let vendor plugins implement QoS capabilities on network ports and
> tenant networks, and
> how to extend agents, and the reference implementation & others [2]
>
>
> As you surely know, so far every attempt to achieve a consensus has failed
> in a pretty miserable way.
> This mostly because "QoS" can be interpreted in a lot of different ways,
> both from the conceptual and practical perspective.
>
> Yes, I’m fully aware of it, it was also a new feature, so it was out of
> scope for Kilo.
>
> It is important in my opinion to clearly define the goals first. For
> instance a simple extensions for bandwidth limiting could be a reasonable
> target for the Liberty release.
>
> I quite agree here, but IMHO, as you said it’s a quite open field
> (limiting, guaranteeing,
> marking, traffic shaping..), we should do our best in trying to define a
> model allowing us
> to build that up in the future without huge changes, on the API side I
> guess micro versioning
> is going to help in the API evolution.
>
> Also, at some point, we should/could need to involve the nova folks, for
> example, to define
> port flavors that can be associated to nova
> instance flavors, providing them
> 1) different types of network port speeds/guarantees/priorities,
> 2) being able to schedule instance/ports in coordination to be able to met
> specified guarantees.
>
> yes, complexity can sky rocket fast,
>
> Moving things such as ECN into "future works" is the right thing to do in
> my opinion. Attempting to define a flexible framework that can deal with
> advanced QoS policies specification is a laudable effort, but I am a bit
> skeptical about its feasibility.
>
> ++, I think focusing on perhaps bandwidth limiting may make a lot of sense
>
> Yes, I believe we should look into the future , but at the same pick our
> very first feature (or a
> very simple set of them) for L, stick to it, and try to make a design
> that can be extended.
>
+1

>
>
>
>
>
> As per discussion we’ve had during the last few months [3], I believe
> we should start simple, but
> prepare a model allowing future extendibility, to allow for example
> specific traffic rules (per port,
> per IP, etc..), congestion notification support [4], …
>
>
> "Simple" in my mind is even more extreme then what you're proposing
> here... I'd start with bare APIs for specifying bandwidth limiting, and
> then phase them out once this "framework" is in place.
> Also note that this kind of design bears some overlap with the flavor
> framework which is probably going to be another goal for Liberty.
>
> Indeed, and the flavor framework is something I'm hoping we can land by
> Liberty-1 (yes, I just said Liberty-1).
>
> Yes it’s something I looked at, I must admit I wasn’t able to see it work
> together (It doesn’t
> mean it doesn’t play well, but most probably I was silly enough not to
> see it :) ),
>
> I didn’t want to distract attention from the Kilo cycle focus making
> questions, so it should
> be a good thing to talk about during the first meetings.
>
> Who are the flavor fathers/mothers? ;)
>
>
>
>
> Morever, consider using "common" tools such as the specs repo to share and
> discuss design documents.
>
>
> Also a good idea.
>
> Yes, that was the plan now, we didn’t use it before to avoid creating
> unnecessary noise during this cycle.
>
>
>
>
> It’s the first time I’m trying to organize an openstack/neutron
> meeting, so, I don’t know what’s the
> best way to do it, or find the best timeslot. I guess interested people
> may have a saying, so I’ve
> looped anybody I know is interested in the CC of this mail.
>
>
> I think that's a good idea. Incidentally I was speaking with Sean
> regarding Summit session [1], and we were hoping we could get some folks
> together either prior or during the summit, to try and get some momentum
> going behind this initiative, once again.
>
> Very interesting [1]!, nice to see we start to have a bunch of people with
> an interest in QoS.
>
>
> I think is a good idea as well.  I was thinking that perhaps it might be a
> good idea to grab a design summit session as well (surely not a fishbowl
> one as they're totally unfit for this purpose).
> However, it might be good to achieve some sort of consensus before the
> summit, as as we know fairly well now the summit is probably the worst
> place where consensus can be achieved!
>
>
> And finally, agr

Re: [openstack-dev] [nova][neutron] Passthrough of PF's from SR-IOV capable devices.

[Irena Berezovsky]

Please see inline

On Thu, Feb 19, 2015 at 4:43 PM, Steve Gordon  wrote:

> - Original Message -
> > From: "Irena Berezovsky" 
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>,
> >
> > On Thu, Feb 5, 2015 at 9:01 PM, Steve Gordon  wrote:
> >
> > > - Original Message -
> > > > From: "Przemyslaw Czesnowicz" 
> > > > To: "OpenStack Development Mailing List (not for usage questions)" <
> > > openstack-dev@lists.openstack.org>
> > > >
> > > > Hi
> > > >
> > > > > 1) If the device is a "normal" PCI device, but is a network card,
> am I
> > > > > still able to
> > > > > take advantage of the advanced syntax added circa Juno to define
> the
> > > > > relationship between that card and a given physical network so
> that the
> > > > > scheduler can place accordingly (and does this still use the ML2
> mech
> > > > > drvier for
> > > > > SR-IOV even though it's a "normal" device.
> > > >
> > > > Actually libvirt won't allow using "normal" PCI devices for network
> > > > interfaces into VM.
> > > > Following error is thrown by libvirt 1.2.9.1:
> > > > libvirtError: unsupported configuration: Interface type hostdev is
> > > currently
> > > > supported on SR-IOV Virtual Functions only
> > > >
> > > > I don't know why libvirt prohibits that. But we should prohibit that
> on
> > > > Openstack side as well.
> > >
> > > This is true for hostdev"> style configuration, "normal" PCI devices
> are
> > > still valid in Libvirt for passthrough using  though. The
> former
> > > having been specifically created for handling passthrough of VFs, the
> > > latter being the more generic passthrough functionality and what was
> used
> > > with the original PCI passthrough functionality introduced circa
> Havana.
> > >
> > > I guess what I'm really asking in this particular question is what is
> the
> > > intersection of these two implementations - if any, as on face value it
> > > seems that to passthrough a physical PCI device I must use the older
> syntax
> > > and thus can't have the scheduler be aware of its external network
> > > connectivity.
> > >
> > Support for "normal" PCI device passthrough for networking in SR-IOV like
> > way will require new VIF Driver support for hostdev style device guest
> XML
> > being created and some call invocation to set MAC address and VLAN tag.
> >
> > >
> > > > > 2) There is no functional reason from a Libvirt/Qemu perspective
> that I
> > > > > couldn't
> > > > > pass through a PF to a guest, and some users have expressed
> surprise
> > > to me
> > > > > when they have run into this check in the Nova driver. I assume in
> the
> > > > > initial
> > > > > implementation this was prevented to avoid a whole heap of fun
> > > additional
> > > > > logic
> > > > > that is required if this is allowed (e.g. check that no VFs from
> the PF
> > > > > being
> > > > > requested are already in use, remove all the associated VFs from
> the
> > > pool
> > > > > when
> > > > > assigning the PF, who gets allowed to use PFs versus VFs etc.). Am
> I
> > > > > correct here
> > > > > or is there another reason that this would be undesirable to allow
> in
> > > > > future -
> > > > > assuming such checks can also be designed - that I am missing?
> > > > >
> > > > I think that is correct. But even if the additional logic was
> > > implemented  it
> > > > wouldn't work because of how libvirt behaves currently.
> > >
> > > Again though, in the code we have a distinction between a physical
> device
> > > (as I was asking about in Q1) and a physical function (as I am asking
> about
> > > in Q2) and similarly whether libvirt allows or not depends on how you
> > > configure in the guest XML. Though I wouldn't be surprised on the PF
> case
> > > if it is in fact not allowed in Libvirt (even with ) it is
> again
> > > important to consider this distinctly separate from passing through th

Re: [openstack-dev] [nova][neutron] Passthrough of PF's from SR-IOV capable devices.

[Irena Berezovsky]

On Thu, Feb 5, 2015 at 9:01 PM, Steve Gordon  wrote:

> - Original Message -
> > From: "Przemyslaw Czesnowicz" 
> > To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> >
> > Hi
> >
> > > 1) If the device is a "normal" PCI device, but is a network card, am I
> > > still able to
> > > take advantage of the advanced syntax added circa Juno to define the
> > > relationship between that card and a given physical network so that the
> > > scheduler can place accordingly (and does this still use the ML2 mech
> > > drvier for
> > > SR-IOV even though it's a "normal" device.
> >
> > Actually libvirt won't allow using "normal" PCI devices for network
> > interfaces into VM.
> > Following error is thrown by libvirt 1.2.9.1:
> > libvirtError: unsupported configuration: Interface type hostdev is
> currently
> > supported on SR-IOV Virtual Functions only
> >
> > I don't know why libvirt prohibits that. But we should prohibit that on
> > Openstack side as well.
>
> This is true for hostdev"> style configuration, "normal" PCI devices are
> still valid in Libvirt for passthrough using  though. The former
> having been specifically created for handling passthrough of VFs, the
> latter being the more generic passthrough functionality and what was used
> with the original PCI passthrough functionality introduced circa Havana.
>
> I guess what I'm really asking in this particular question is what is the
> intersection of these two implementations - if any, as on face value it
> seems that to passthrough a physical PCI device I must use the older syntax
> and thus can't have the scheduler be aware of its external network
> connectivity.
>
Support for "normal" PCI device passthrough for networking in SR-IOV like
way will require new VIF Driver support for hostdev style device guest XML
being created and some call invocation to set MAC address and VLAN tag.

>
> > > 2) There is no functional reason from a Libvirt/Qemu perspective that I
> > > couldn't
> > > pass through a PF to a guest, and some users have expressed surprise
> to me
> > > when they have run into this check in the Nova driver. I assume in the
> > > initial
> > > implementation this was prevented to avoid a whole heap of fun
> additional
> > > logic
> > > that is required if this is allowed (e.g. check that no VFs from the PF
> > > being
> > > requested are already in use, remove all the associated VFs from the
> pool
> > > when
> > > assigning the PF, who gets allowed to use PFs versus VFs etc.). Am I
> > > correct here
> > > or is there another reason that this would be undesirable to allow in
> > > future -
> > > assuming such checks can also be designed - that I am missing?
> > >
> > I think that is correct. But even if the additional logic was
> implemented  it
> > wouldn't work because of how libvirt behaves currently.
>
> Again though, in the code we have a distinction between a physical device
> (as I was asking about in Q1) and a physical function (as I am asking about
> in Q2) and similarly whether libvirt allows or not depends on how you
> configure in the guest XML. Though I wouldn't be surprised on the PF case
> if it is in fact not allowed in Libvirt (even with ) it is again
> important to consider this distinctly separate from passing through the
> physical device case which we DO allow currently in the code I'm asking
> about.
>
I think what you suggest is not difficult to support, but current (since
Juno) PCI device passthrough  for networking is all about SR-IOV PCI device
passthrough. As I mentioned, to support  "normal" PCI device will require
libvirt VIF Driver adjustment. I think its possible to make this work with
existing neutron ML2 SRIOV Mechanism Driver.

>
> -Steve
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] SRIOV-error

[Irena Berezovsky]

Hi David,
As I mentioned before, you do not need to run sriov agent in your setup, just 
set agent_required=False in your neutron-server configuration. I think that 
initially this may be easier to make things work this way.
I also cannot understand why you have two neutron config files that contain 
same sections with different settings.

You can find me on #openstack-neuron IRC channel, I can try to help.

BR,
Irena


From: david jhon [mailto:djhon9...@gmail.com]
Sent: Tuesday, December 16, 2014 9:44 AM
To: Irena Berezovsky
Cc: OpenStack Development Mailing List (not for usage questions); Murali B
Subject: Re: [openstack-dev] SRIOV-error

Hi Irena and Murali,

Thanks a lot for your reply!
Here is the output from pci_devices table of nova db:

select * from pci_devices;
+-+++-++-+--++---+--+--+-+---+---+---++
| created_at  | updated_at | deleted_at | deleted | id | 
compute_node_id | address  | product_id | vendor_id | dev_type | dev_id 
  | label   | status| extra_info| 
instance_uuid | request_id |
+-+++-++-+--++---+--+--+-+---+---+---++
| 2014-12-15 12:10:52 | NULL   | NULL   |   0 |  1 |   
1 | :03:10.0 | 10ed   | 8086  | type-VF  | pci__03_10_0 | 
label_8086_10ed | available | {"phys_function": ":03:00.0"} | NULL  
| NULL   |
| 2014-12-15 12:10:52 | NULL   | NULL   |   0 |  2 |   
1 | :03:10.2 | 10ed   | 8086  | type-VF  | pci__03_10_2 | 
label_8086_10ed | available | {"phys_function": ":03:00.0"} | NULL  
| NULL   |
| 2014-12-15 12:10:52 | NULL   | NULL   |   0 |  3 |   
1 | :03:10.4 | 10ed   | 8086  | type-VF  | pci__03_10_4 | 
label_8086_10ed | available | {"phys_function": ":03:00.0"} | NULL  
| NULL   |
| 2014-12-15 12:10:52 | NULL   | NULL   |   0 |  4 |   
1 | :03:10.6 | 10ed   | 8086  | type-VF  | pci__03_10_6 | 
label_8086_10ed | available | {"phys_function": ":03:00.0"} | NULL  
| NULL   |
| 2014-12-15 12:10:53 | NULL   | NULL   |   0 |  5 |   
1 | :03:10.1 | 10ed   | 8086  | type-VF  | pci__03_10_1 | 
label_8086_10ed | available | {"phys_function": ":03:00.1"} | NULL  
| NULL   |
| 2014-12-15 12:10:53 | NULL   | NULL   |   0 |  6 |   
1 | :03:10.3 | 10ed   | 8086  | type-VF  | pci__03_10_3 | 
label_8086_10ed | available | {"phys_function": ":03:00.1"} | NULL  
| NULL   |
| 2014-12-15 12:10:53 | NULL   | NULL   |   0 |  7 |   
1 | :03:10.5 | 10ed   | 8086  | type-VF  | pci__03_10_5 | 
label_8086_10ed | available | {"phys_function": ":03:00.1"} | NULL  
| NULL   |
| 2014-12-15 12:10:53 | NULL   | NULL   |   0 |  8 |   
1 | :03:10.7 | 10ed   | 8086  | type-VF  | pci__03_10_7 | 
label_8086_10ed | available | {"phys_function": ":03:00.1"} | NULL  
| NULL   |
+-+++-++-+--++---+--+--+-+---+---+---++
output from select hypervisor_hostname,pci_stats from compute_nodes; is:
+-+---+
| hypervisor_hostname | pci_stats   
  |
+-+---+
| blade08 | [{"count": 8, "vendor_id": "8086", "physical_network": 
"ext-net", "product_id": "10ed"}] |
+-+---+
Moreover, I have set agent_required = True in 
/etc/neutron/plugins/ml2/ml2_conf_sriov.ini. but still found no sriov agent 
running.
# Defines configuration options for SRIOV NIC Switch MechanismDriver
# and Agent

[ml2_sriov]
# (ListOpt) Comma-separated list of
# supported Vendor PCI Devices, in format vendor_id:product_i

Re: [openstack-dev] Minimal ML2 mechanism driver after Neutron decomposition change

[Irena Berezovsky]

-Original Message-
From: henry hly [mailto:] 
Sent: Tuesday, December 16, 2014 3:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Minimal ML2 mechanism driver after Neutron 
decomposition change

On Tue, Dec 16, 2014 at 1:53 AM, Neil Jerram  wrote:
> Hi all,
>
> Following the approval for Neutron vendor code decomposition 
> (https://review.openstack.org/#/c/134680/), I just wanted to comment 
> that it appears to work fine to have an ML2 mechanism driver 
> _entirely_ out of tree, so long as the vendor repository that provides 
> the ML2 mechanism driver does something like this to register their 
> driver as a neutron.ml2.mechanism_drivers entry point:
>
>   setuptools.setup(
>   ...,
>   entry_points = {
>   ...,
>   'neutron.ml2.mechanism_drivers': [
>   'calico = xyz.openstack.mech_xyz:XyzMechanismDriver',
>   ],
>   },
>   )
>
> (Please see
> https://github.com/Metaswitch/calico/commit/488dcd8a51d7c6a1a2f0378900
> 1c2139b16de85c for the complete change and detail, for the example 
> that works for me.)
>
> Then Neutron and the vendor package can be separately installed, and 
> the vendor's driver name configured in ml2_conf.ini, and everything works.
>
> Given that, I wonder:
>
> - is that what the architects of the decomposition are expecting?
>
> - other than for the reference OVS driver, are there any reasons in
>   principle for keeping _any_ ML2 mechanism driver code in tree?
>

Good questions. I'm also looking for the linux bridge MD, SRIOV MD...
Who will be responsible for these drivers?

Excellent question. In my opinion, 'technology' specific but not vendor 
specific MD (like SRIOV) should not be maintained by specific vendor. It should 
be accessible for all interested parties for contribution.

The OVS driver is maintained by Neutron community, vendor specific hardware 
driver by vendor, SDN controllers driver by their own community or vendor. But 
there are also other drivers like SRIOV, which are general for a lot of vendor 
agonitsc backends, and can't be maintained by a certain vendor/community.

So, it would be better to keep some "general backend" MD in tree besides SRIOV. 
There are also vif-type-tap, vif-type-vhostuser, 
hierarchy-binding-external-VTEP ... We can implement a very thin in-tree base 
MD that only handle "vif bind" which is backend agonitsc, then backend provider 
is free to implement their own service logic, either by an backend agent, or by 
a driver derived from the base MD for agentless scenery.

Keeping general backend MDs in tree sounds reasonable. 
Regards

> Many thanks,
>  Neil
>
> ___
> 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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] SRIOV-error

[Irena Berezovsky]

Hi David,
You error is not related to agent.
I would suggest to check:

1.nova.conf at your compute node for pci whitelist configuration

2.   Neutron server configuration for correct physical_network label 
matching the label in pci whitelist

3.   Nova DB tables containing PCI devices entries:

"#echo 'use nova;select hypervisor_hostname,pci_stats from compute_nodes;' | 
mysql -u root"
You should not run SR-IOV agent in you setup. SR-IOV agent is an optional and 
currently does not add value if you use Intel NIC.


Regards,
Irena
From: david jhon [mailto:djhon9...@gmail.com]
Sent: Tuesday, December 16, 2014 5:54 AM
To: Murali B
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] SRIOV-error

Just to be more clear, command $lspci | grep -i Ethernet gives following output:

01:00.0 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual Port 
Backplane Connection (rev 01)
01:00.1 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual Port 
Backplane Connection (rev 01)
03:00.0 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual Port 
Backplane Connection (rev 01)
03:00.1 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual Port 
Backplane Connection (rev 01)
03:10.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller 
Virtual Function (rev 01)
03:10.1 Ethernet controller: Intel Corporation 82599 Ethernet Controller 
Virtual Function (rev 01)
03:10.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller 
Virtual Function (rev 01)
03:10.3 Ethernet controller: Intel Corporation 82599 Ethernet Controller 
Virtual Function (rev 01)
03:10.4 Ethernet controller: Intel Corporation 82599 Ethernet Controller 
Virtual Function (rev 01)
03:10.5 Ethernet controller: Intel Corporation 82599 Ethernet Controller 
Virtual Function (rev 01)
03:10.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller 
Virtual Function (rev 01)
03:10.7 Ethernet controller: Intel Corporation 82599 Ethernet Controller 
Virtual Function (rev 01)
04:00.0 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual Port 
Backplane Connection (rev 01)
04:00.1 Ethernet controller: Intel Corporation 82599 10 Gigabit Dual Port 
Backplane Connection (rev 01)
04:10.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller 
Virtual Function (rev 01)
04:10.1 Ethernet controller: Intel Corporation 82599 Ethernet Controller 
Virtual Function (rev 01)
04:10.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller 
Virtual Function (rev 01)
04:10.3 Ethernet controller: Intel Corporation 82599 Ethernet Controller 
Virtual Function (rev 01)
04:10.4 Ethernet controller: Intel Corporation 82599 Ethernet Controller 
Virtual Function (rev 01)
04:10.5 Ethernet controller: Intel Corporation 82599 Ethernet Controller 
Virtual Function (rev 01)
04:10.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller 
Virtual Function (rev 01)
04:10.7 Ethernet controller: Intel Corporation 82599 Ethernet Controller 
Virtual Function (rev 01)
How can I make SR-IOV agent run and fix this bug?


On Tue, Dec 16, 2014 at 8:36 AM, david jhon 
mailto:djhon9...@gmail.com>> wrote:
Hi Murali,
Thanks for your response, I did the same, it has resolved errors apparently but 
1) neutron agent-list shows no agent for sriov, 2) neutron port is created 
successfully but creating vm is erred in scheduling as follows:

result from neutron agent-list:
+--++-+---++---+
| id   | agent_type | host| alive | 
admin_state_up | binary|
+--++-+---++---+
| 2acc7044-e552-4601-b00b-00ba591b453f | Open vSwitch agent | blade08 | xxx   | 
True   | neutron-openvswitch-agent |
| 595d07c6-120e-42ea-a950-6c77a6455f10 | Metadata agent | blade08 | :-)   | 
True   | neutron-metadata-agent|
| a1f253a8-e02e-4498-8609-4e265285534b | DHCP agent | blade08 | :-)   | 
True   | neutron-dhcp-agent|
| d46b29d8-4b5f-4838-bf25-b7925cb3e3a7 | L3 agent   | blade08 | :-)   | 
True   | neutron-l3-agent  |
+--++-+---++---+

2014-12-15 19:30:44.546 40249 ERROR oslo.messaging.rpc.dispatcher 
[req-c7741cff-a7d8-422f-b605-6a1d976aeb09 ] Exception during message handling: 
PCI $
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher Traceback 
(most recent call last):
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py", line 13$
2014-12-15 19:30:44.546 40249 TRACE oslo.messaging.rpc.dispatcher 
incoming.message))
2014-12-15 19:30:44.546 4

Re: [openstack-dev] SRIOV failures error-

[Irena Berezovsky]

Hi David,
One configuration option is missing that you should be aware of:
In /etc/neutron/plugins/ml2/ml2_conf_sriov.ini:
In [ml2_sriov] section set PCI Device vendor and product IDs you use, in format 
vendor_id:product_id

supported_pci_vendor_devs =

Example:
supported_pci_vendor_devs = 8086:10ca

Then restart neutron-server.

May ask you to post this question at ask.openstack.org?

BR,
Irena

From: david jhon [mailto:djhon9...@gmail.com]
Sent: Monday, December 15, 2014 9:21 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] SRIOV failures error-

Hi, I am doing the same i.e., configuring SR-IOV with Openstack juno, I have 
manually done this but now I am doing it for openstack. Can you please list 
down steps you used for configuring SR-IOV. I am currently following this link 
but getting many errors: 
https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking

Please share some tutorial you found for this configuration. I'll be real 
grateful for your help.  Thanking you in anticipation
Looking forward seeing your response
Thanks and Regards,

On Tue, Dec 2, 2014 at 12:18 PM, Itzik Brown 
mailto:itz...@redhat.com>> wrote:
Hi,
Seems like you don't have available devices for allocation.

What's the output of:
#echo 'use nova;select hypervisor_hostname,pci_stats from compute_nodes;' | 
mysql -u root

Itzik

On 12/02/2014 08:21 AM, Murali B wrote:
Hi

we are trying to bring-up the SRIOV on set-up.

facing the below error when we tried create the vm.

Still during creating instance ERROR appears .
PciDeviceRequestFailed: PCI device request ({'requests': 
[InstancePCIRequest(alias_name=None,count=1,is_new=False,request_id=58584ee1-8a41-4979-9905-4d18a3df3425,spec=[{physical_network='physnet1'}])],
 'code': 500}equests)s failed

followed the steps from the 
https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking

Please help us to get rid this error. let us know if any configuration is 
required at hardware in order to work properly.

Thanks
-Murali


___

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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech driver/L2 and vif_driver

[Irena Berezovsky]

Hi Daniel,
Please see inline

-Original Message-
From: Daniel P. Berrange [mailto:berra...@redhat.com] 
Sent: Tuesday, December 09, 2014 4:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova][Neutron] out-of-tree plugin for Mech 
driver/L2 and vif_driver

On Tue, Dec 09, 2014 at 10:53:19AM +0100, Maxime Leroy wrote:
> I have also proposed a blueprint to have a new plugin mechanism in 
> nova to load external vif driver. (nova-specs:
> https://review.openstack.org/#/c/136827/ and nova (rfc patch):
> https://review.openstack.org/#/c/136857/)
> 
> From my point-of-view of a developer having a plugin framework for 
> internal/external vif driver seems to be a good thing.
> It makes the code more modular and introduce a clear api for vif driver 
> classes.
> 
> So far, it raises legitimate questions concerning API stability and 
> public API that request a wider discussion on the ML (as asking by 
> John Garbut).
> 
> I think having a plugin mechanism and a clear api for vif driver is 
> not going against this policy:
> http://docs.openstack.org/developer/nova/devref/policies.html#out-of-tree-support.
> 
> There is no needs to have a stable API. It is up to the owner of the 
> external VIF driver to ensure that its driver is supported by the 
> latest API. And not the nova community to manage a stable API for this 
> external VIF driver. Does it make senses ?

Experiance has shown that even if it is documented as unsupported, once the 
extension point exists, vendors & users will ignore the small print about 
support status. There will be complaints raised every time it gets broken until 
we end up being forced to maintain it as stable API whether we want to or not. 
That's not a route we want to go down.

[IB] It should be up to the vendor to maintain it and make sure it's not 
broken. Having proper 3rd party CI in place should catch API contract changes.

> Considering the network V2 API, L2/ML2 mechanism driver and VIF driver 
> need to exchange information such as: binding:vif_type and 
> binding:vif_details.
> 
> From my understanding, 'binding:vif_type' and 'binding:vif_details' as 
> a field part of the public network api. There is no validation 
> constraints for these fields (see 
> http://docs.openstack.org/api/openstack-network/2.0/content/binding_ex
> t_ports.html), it means that any value is accepted by the API. So, the 
> values set in 'binding:vif_type' and 'binding:vif_details' are not 
> part of the public API. Is my understanding correct ?

The VIF parameters are mapped into the nova.network.model.VIF class which is 
doing some crude validation. I would anticipate that this validation will be 
increasing over time, because any functional data flowing over the API and so 
needs to be carefully managed for upgrade reasons.

Even if the Neutron impl is out of tree, I would still expect both Nova and 
Neutron core to sign off on any new VIF type name and its associated details 
(if any).

[IB] This maybe the reasonable integration point. But it requires nova team 
review and approval. From my experience nova team is extremely overloaded, 
therefor getting this code reviewed become very difficult mission.
 
> What other reasons am I missing to not have VIF driver classes as a 
> public extension point ?

Having to find & install VIF driver classes from countless different vendors, 
each hiding their code away in their own obsecure website, will lead to awful 
end user experiance when deploying Nova. Users are better served by having it 
all provided when they deploy Nova IMHO

If every vendor goes off & works in their own isolated world we also loose the 
scope to align the implementations, so that common concepts work the same way 
in all cases and allow us to minimize the number of new VIF types required. The 
proposed vhostuser VIF type is a good example of this - it allows a single Nova 
VIF driver to be capable of potentially supporting multiple different impls on 
the Neutron side.
If every vendor worked in their own world, we would have ended up with multiple 
VIF drivers doing the same thing in Nova, each with their own set of bugs & 
quirks.

[IB] I think that most of the vendors that maintain vif_driver out of nova, do 
not do it on purpose and would prefer to see it upstream. Sometimes host side 
binding is not fully integrated with libvirt and requires some temporary 
additional code, till libvirt provides complete support. Sometimes, it is just 
lack of nova team attention to the proposed spec/code  to be reviewed and 
accepted on time, which ends up with fully supported neutron part and missing 
small but critical vif_driver piece.
 
I expect the quality of the code the operator receives will be lower if it is 
never reviewed by anyone except the vendor who writes it in the first place.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o-  

Re: [openstack-dev] SRIOV failures error-

[Irena Berezovsky]

Hi Murali,
Seems there is a mismatch between pci_whitelist configuration and requested 
network.
In the table below:
"physical_network": "physnet2"

In the error you sent, there is:
[InstancePCIRequest(alias_name=None,count=1,is_new=False,request_id=58584ee1-8a41-4979-9905-4d18a3df3425,spec=[{physical_network='physnet1'}])],

Please check the neutron and nova configuration for physical_network.

Cheers,
Irena

From: Murali B [mailto:mbi...@gmail.com]
Sent: Wednesday, December 03, 2014 5:19 AM
To: openstack-dev@lists.openstack.org; itz...@redhat.com
Subject: [openstack-dev] SRIOV failures error-

Hi Itzik,

Thank you for your reply

Please find the below output for "#echo 'use nova;select 
hypervisor_hostname,pci_stats from
compute_nodes;' | mysql -u root"

MariaDB [nova]> select hypervisor_hostname,pci_stats from compute_nodes;
+-+---+
| hypervisor_hostname | pci_stats   
  |
+-+---+
| compute2| []  
  |
| xilinx-r720 | [{"count": 1, "vendor_id": "8086", "physical_network": 
"physnet2", "product_id": "10ed"}] |
| compute1| []  
  |
| compute4| []  
  |
+-+---+

we have enabled SRIOV agent on compute node 4 as well as  xilinx-r720

Thanks
-Murali
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

[Irena Berezovsky]

Same question regarding QoS as a Service, once it will be approved.
Should it belong to Advanced Services as well?

-Original Message-
From: Sumit Naiksatam [mailto:sumitnaiksa...@gmail.com] 
Sent: Wednesday, November 19, 2014 9:15 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into 
separate repositories

On Tue, Nov 18, 2014 at 11:04 PM, henry hly  wrote:
> Is FWaas L2/3 or L4/7?
>

Thats a good question, and what has been asked here in the context of VPNaaS as 
well. Hence the proposed definition below avoids characterizing the advanced 
services project purely as L4-7 because that would not be accurate (in the 
context of any of existing three services, or proposed new services).

> On Wed, Nov 19, 2014 at 11:10 AM, Sumit Naiksatam 
>  wrote:
>> On Tue, Nov 18, 2014 at 4:44 PM, Mohammad Hanif  wrote:
>>> I agree with Paul as advanced services go beyond just L4-L7.  Today, 
>>> VPNaaS deals with L3 connectivity but belongs in advanced services.  
>>> Where does Edge-VPN work belong?  We need a broader definition for 
>>> advanced services area.
>>>
>>
>> So the following definition is being proposed to capture the broader 
>> context and complement Neutron's current mission statement:
>>
>> To implement services and associated libraries that provide 
>> abstractions for advanced network functions beyond basic L2/L3 
>> connectivity and forwarding.
>>
>> What do people think?
>>
>>> Thanks,
>>> —Hanif.
>>>
>>> From: "Paul Michali (pcm)" 
>>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>>> 
>>> Date: Tuesday, November 18, 2014 at 4:08 PM
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> 
>>> Subject: Re: [openstack-dev] [tc][neutron] Proposal to split Neutron 
>>> into separate repositories
>>>
>>> On Nov 18, 2014, at 6:36 PM, Armando M.  wrote:
>>>
>>> Mark, Kyle,
>>>
>>> What is the strategy for tracking the progress and all the details 
>>> about this initiative? Blueprint spec, wiki page, or something else?
>>>
>>> One thing I personally found useful about the spec approach adopted 
>>> in [1], was that we could quickly and effectively incorporate 
>>> community feedback; having said that I am not sure that the same 
>>> approach makes sense here, hence the question.
>>>
>>> Also, what happens for experimental efforts that are neither L2-3 
>>> nor L4-7 (e.g. TaaS or NFV related ones?), but they may still 
>>> benefit from this decomposition (as it promotes better separation of 
>>> responsibilities)? Where would they live? I am not sure we made any 
>>> particular progress of the incubator project idea that was floated a while 
>>> back.
>>>
>>>
>>> Would it make sense to define the advanced services repo as being 
>>> for services that are beyond basic connectivity and routing? For 
>>> example, VPN can be L2 and L3. Seems like restricting to L4-L7 may 
>>> cause some confusion as to what’s in and what’s out.
>>>
>>>
>>> Regards,
>>>
>>> PCM (Paul Michali)
>>>
>>> MAIL …..…. p...@cisco.com
>>> IRC ……..… pc_m (irc.freenode.com)
>>> TW ………... @pmichali
>>> GPG Key … 4525ECC253E31A83
>>> Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83
>>>
>>>
>>>
>>> Cheers,
>>> Armando
>>>
>>> [1] https://review.openstack.org/#/c/134680/
>>>
>>> On 18 November 2014 15:32, Doug Wiegley  wrote:

 Hi,

 > so the specs repository would continue to be shared during the 
 > Kilo cycle.

 One of the reasons to split is that these two teams have different 
 priorities and velocities.  Wouldn’t that be easier to track/manage 
 as separate launchpad projects and specs repos, irrespective of who 
 is approving them?

 Thanks,
 doug



 On Nov 18, 2014, at 10:31 PM, Mark McClain  wrote:

 All-

 Over the last several months, the members of the Networking Program 
 have been discussing ways to improve the management of our program.  
 When the Quantum project was initially launched, we envisioned a 
 combined service that included all things network related.  This 
 vision served us well in the early days as the team mostly focused 
 on building out layers 2 and 3; however, we’ve run into growth 
 challenges as the project started building out layers 4 through 7.  
 Initially, we thought that development would float across all 
 layers of the networking stack, but the reality is that the development 
 concentrates around either layer 2 and 3 or layers 4 through 7.
 In the last few cycles, we’ve also discovered that these 
 concentrations have different velocities and a single core team 
 forces one to match the other to the detriment of the one forced to slow 
 down.

 Going forward we want to divide the Neutron repository into two 
 separate repositories lead by a common Networking PTL.  The current 
 mission of th

Re: [openstack-dev] CI for NUMA, SR-IOV, and other features that can't be tested on current infra.

[Irena Berezovsky]

From: Joe Gordon [mailto:joe.gord...@gmail.com]
Sent: Wednesday, November 19, 2014 12:54 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] CI for NUMA, SR-IOV, and other features that can't 
be tested on current infra.



On Sun, Nov 16, 2014 at 5:31 AM, Irena Berezovsky 
mailto:ire...@mellanox.com>> wrote:
Hi Steve,
Regarding SR-IOV testing, at Mellanox we have CI job running on bare metal node 
with Mellanox SR-IOV NIC.  This job is reporting on neutron patches. Currently 
API tests are executed.
The contact person for SRIOV CI job is listed at driverlog:
https://github.com/stackforge/driverlog/blob/master/etc/default_data.json#L1439


The following items are in progress:
 - SR-IOV functional testing

Where do you envision these tests living?
[IrenaB] Initially in our local tempest repository

 - Reporting CI job on nova patches

Looking forward to it. I assume you will be working with the other people 
trying to set up assorted CI systems in this space.
[IrenaB] We already have basic setup in place, but CI job is still not 
reporting. It will start reporting once we have reasonable test coverage. We 
definitely look into collaboration with other people with regards to SR-IOV 
testing.

 - Multi-node setup
It worth to mention that we   want to start the collaboration on SR-IOV testing 
effort as part of the pci pass-through subteam activity.
Please join the weekly meeting if you want to collaborate or have some inputs: 
https://wiki.openstack.org/wiki/Meetings/Passthrough

BR,
Irena

-Original Message-
From: Steve Gordon [mailto:sgor...@redhat.com<mailto:sgor...@redhat.com>]
Sent: Wednesday, November 12, 2014 9:11 PM
To: itai mendelsohn; Adrian Hoban; Russell Bryant; Ian Wells (iawells); Irena 
Berezovsky; ba...@cisco.com<mailto:ba...@cisco.com>
Cc: Nikola Đipanov; Russell Bryant; OpenStack Development Mailing List (not for 
usage questions)
Subject: [Nova][Neutron][NFV][Third-party] CI for NUMA, SR-IOV, and other 
features that can't be tested on current infra.

Hi all,

We had some discussions last week - particularly in the Nova NFV design session 
[1] - on the subject of ensuring that telecommunications and NFV-related 
functionality has adequate continuous integration testing. In particular the 
focus here is on functionality that can't easily be tested on the public clouds 
that back the gate, including:

- NUMA (vCPU pinning, vCPU layout, vRAM layout, huge pages, I/O device locality)
- SR-IOV with Intel, Cisco, and Mellanox devices (possibly others)

In each case we need to confirm where we are at, and the plan going forward, 
with regards to having:

1) Hardware to run the CI on.
2) Tests that actively exercise the functionality (if not already in existence).
3) Point person for each setup to maintain it and report into the third-party 
meeting [2].
4) Getting the jobs operational and reporting [3][4][5][6].

In the Nova session we discussed a goal of having the hardware by K-1 (Dec 18) 
and having it reporting at least periodically by K-2 (Feb 5). I'm not sure if 
similar discussions occurred on the Neutron side of the design summit.

SR-IOV
==

Adrian and Irena mentioned they were already in the process of getting up to 
speed with third party CI for their respective SR-IOV configurations. Robert 
are you attempting similar with regards to Cisco devices? What is the status of 
each of these efforts versus the four items I lifted above and what do you need 
assistance with?

NUMA


We still need to identify some hardware to run third party CI for the 
NUMA-related work, and no doubt other things that will come up. It's expected 
that this will be an interim solution until OPNFV resources can be used (note 
cdub jokingly replied 1-2 years when asked for a "rough" estimate - I mention 
this because based on a later discussion some people took this as a serious 
estimate).

Ian did you have any luck kicking this off? Russell and I are also endeavouring 
to see what we can do on our side w.r.t. this short term approach - in 
particular if you find hardware we still need to find an owner to actually 
setup and manage it as discussed.

In theory to get started we need a physical multi-socket box and a virtual 
machine somewhere on the same network to handle job control etc. I believe the 
tests themselves can be run in VMs (just not those exposed by existing public 
clouds) assuming a recent Libvirt and an appropriately crafted Libvirt XML that 
ensures the VM gets a multi-socket topology etc. (we can assist with this).

Thanks,

Steve

[1] https://etherpad.openstack.org/p/kilo-nova-nfv
[2] https://wiki.openstack.org/wiki/Meetings/ThirdParty
[3] http://ci.openstack.org/third_party.html
[4] http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/
[5] 
http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/
[6] 
http://www.joinfu.com/2014/02/s

Re: [openstack-dev] CI for NUMA, SR-IOV, and other features that can't be tested on current infra.

[Irena Berezovsky]

Hi Steve,
Regarding SR-IOV testing, at Mellanox we have CI job running on bare metal node 
with Mellanox SR-IOV NIC.  This job is reporting on neutron patches. Currently 
API tests are executed. 
The contact person for SRIOV CI job is listed at driverlog:
https://github.com/stackforge/driverlog/blob/master/etc/default_data.json#L1439

The following items are in progress:
 - SR-IOV functional testing 
 - Reporting CI job on nova patches
 - Multi-node setup
It worth to mention that we   want to start the collaboration on SR-IOV testing 
effort as part of the pci pass-through subteam activity.
Please join the weekly meeting if you want to collaborate or have some inputs: 
https://wiki.openstack.org/wiki/Meetings/Passthrough

BR,
Irena

-Original Message-
From: Steve Gordon [mailto:sgor...@redhat.com] 
Sent: Wednesday, November 12, 2014 9:11 PM
To: itai mendelsohn; Adrian Hoban; Russell Bryant; Ian Wells (iawells); Irena 
Berezovsky; ba...@cisco.com
Cc: Nikola Đipanov; Russell Bryant; OpenStack Development Mailing List (not for 
usage questions)
Subject: [Nova][Neutron][NFV][Third-party] CI for NUMA, SR-IOV, and other 
features that can't be tested on current infra.

Hi all,

We had some discussions last week - particularly in the Nova NFV design session 
[1] - on the subject of ensuring that telecommunications and NFV-related 
functionality has adequate continuous integration testing. In particular the 
focus here is on functionality that can't easily be tested on the public clouds 
that back the gate, including:

- NUMA (vCPU pinning, vCPU layout, vRAM layout, huge pages, I/O device locality)
- SR-IOV with Intel, Cisco, and Mellanox devices (possibly others)
  
In each case we need to confirm where we are at, and the plan going forward, 
with regards to having:

1) Hardware to run the CI on.
2) Tests that actively exercise the functionality (if not already in existence).
3) Point person for each setup to maintain it and report into the third-party 
meeting [2].
4) Getting the jobs operational and reporting [3][4][5][6].

In the Nova session we discussed a goal of having the hardware by K-1 (Dec 18) 
and having it reporting at least periodically by K-2 (Feb 5). I'm not sure if 
similar discussions occurred on the Neutron side of the design summit.

SR-IOV
==

Adrian and Irena mentioned they were already in the process of getting up to 
speed with third party CI for their respective SR-IOV configurations. Robert 
are you attempting similar with regards to Cisco devices? What is the status of 
each of these efforts versus the four items I lifted above and what do you need 
assistance with?

NUMA


We still need to identify some hardware to run third party CI for the 
NUMA-related work, and no doubt other things that will come up. It's expected 
that this will be an interim solution until OPNFV resources can be used (note 
cdub jokingly replied 1-2 years when asked for a "rough" estimate - I mention 
this because based on a later discussion some people took this as a serious 
estimate).

Ian did you have any luck kicking this off? Russell and I are also endeavouring 
to see what we can do on our side w.r.t. this short term approach - in 
particular if you find hardware we still need to find an owner to actually 
setup and manage it as discussed.

In theory to get started we need a physical multi-socket box and a virtual 
machine somewhere on the same network to handle job control etc. I believe the 
tests themselves can be run in VMs (just not those exposed by existing public 
clouds) assuming a recent Libvirt and an appropriately crafted Libvirt XML that 
ensures the VM gets a multi-socket topology etc. (we can assist with this).

Thanks,

Steve

[1] https://etherpad.openstack.org/p/kilo-nova-nfv
[2] https://wiki.openstack.org/wiki/Meetings/ThirdParty
[3] http://ci.openstack.org/third_party.html
[4] http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/
[5] 
http://www.joinfu.com/2014/02/setting-up-an-external-openstack-testing-system/
[6] 
http://www.joinfu.com/2014/02/setting-up-an-openstack-external-testing-system-part-2/
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Translation technical debt

[Irena Berezovsky]

Count me in

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Tuesday, November 11, 2014 3:47 PM
To: OpenStack List
Subject: [openstack-dev] [Neutron] Translation technical debt

Hi,
In order to enforce our translation policies - 
http://docs.openstack.org/developer/oslo.i18n/guidelines.html - we have added a 
hacking rule in Neutron. If you wish to jump aboard this effort then please let 
me know. There are patches for all directories except the plugins and services.
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] PCI/SR-IOV meet-up at the summit

[Irena Berezovsky]

Hi,
We thought it would be a good idea to have some chat regarding further SR-IOV 
enchantment that we want to achieve during Kilo.
If you are interested to discuss it, please join us Wednesday 5, at 13:15 at 
the developers lounge.
The list of topics raised till now can be found here:
https://etherpad.openstack.org/p/kilo_sriov_pci_passthrough

See you there,
Irena
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][QoS] Pod time at Paris Summit

[Irena Berezovsky]

Hi Sean,
Is there any chance to change this time slot?
Unfortunately, I won't be there on Friday.


BR,
Irena

-Original Message-
From: Collins, Sean [mailto:sean_colli...@cable.comcast.com] 
Sent: Thursday, October 30, 2014 5:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][QoS] Pod time at Paris Summit

I have reserved the 2:35 slot for Friday. 

https://etherpad.openstack.org/p/neutron-kilo-meetup-slots

-- 
Sean M. Collins
___
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] [Neutron][QoS] Pod time at Paris Summit

[Irena Berezovsky]

Hi Sean,
Will be great to meet in person and discuss QoS adoption path.
Count me in,
Irena

-Original Message-
From: Collins, Sean [mailto:sean_colli...@cable.comcast.com] 
Sent: Tuesday, October 28, 2014 8:17 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][QoS] Pod time at Paris Summit

Hi,

Like Atlanta, I will be at the summit. If there is interest, I can schedule a 
time to talk about the QoS API extension.

--
Sean M. Collins
___
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] [Neutron][Architecture]Suggestions for the third vendors' plugin and driver

[Irena Berezovsky]

Hi,
While keeping focused on defining proper approach to deal with Neutron third 
vendors’ plugin and driver, we also need to provide solution for complimentary 
critical piece of code maintained in the Nova code base.
Introducing new vif_type by neutron L2 Plugin/Driver, requires adding vif 
plugging support at Nova side.
I think it is very important to enable  virt driver  extensibility to support 
out of the tree/future vif_types.
If the direction is to keep vendor plugins/drivers external to Neutron core, it 
seems reasonable to impose same policy on the Nova side.

BR,
Irena

From: Kevin Benton [mailto:blak...@gmail.com]
Sent: Friday, September 12, 2014 12:19 PM
To: OpenStack Development Mailing List (not for usage questions)
Cc: tanny...@huawei.com
Subject: Re: [openstack-dev] [Neutron][Architecture]Suggestions for the third 
vendors' plugin and driver

> So my suggestion is remove all vendors' plugins and drivers except opensource 
> as built-in.

Yes, I think this is currently the view held by the PTL (Kyle) and some of the 
other cores so what you're suggesting will definitely come up at the summit.


> Why do we need a different repo to store vendors' codes? That's not the 
> community business.
> I think only a proper architecture and normal NB&SB API can bring "a clear 
> separation between plugins(or drivers) and core code", not a different repo.

The problem is that that architecture won't stay stable if there is no shared 
community plugin depending on its stability. Let me ask you the inverse 
question. Why do you think the reference driver should stay in the core repo?

A separate repo won't have an impact on what is packaged and released so it 
should have no impact on "user experience", "complete versions", "providing 
code examples",  or "developing new features". In fact, it will likely help 
with the last two because it will provide a clear delineation between what a 
plugin is responsible for vs. what the core API is responsible for. And, 
because new cores can be added faster to the open source plugins repo due to a 
smaller code base to learn, it will help with developing new features by 
reducing reviewer load.

On Fri, Sep 12, 2014 at 1:50 AM, Germy Lure 
mailto:germy.l...@gmail.com>> wrote:


On Fri, Sep 12, 2014 at 11:11 AM, Kevin Benton 
mailto:blak...@gmail.com>> wrote:

> Maybe I missed something, but what's the solution?

There isn't one yet. That's why it's going to be discussed at the summit.
So my suggestion is remove all vendors' plugins and drivers except opensource 
as built-in.
By leaving open source plugins and drivers in the tree , we can resolve such 
problems:
  1)release a workable and COMPLETE version
  2)user experience(especially for beginners)
  3)provide code example to learn for new contributors and vendors
  4)develop and verify new features


> I think we should release a workable version.

Definitely. But that doesn't have anything to do with it living in the same 
repository. By putting it in a different repo, it provides smaller code bases 
to learn for new contributors wanting to become a core developer in addition to 
a clear separation between plugins and core code.
Why do we need a different repo to store vendors' codes? That's not the 
community business.
I think only a proper architecture and normal NB&SB API can bring "a clear 
separation between plugins(or drivers) and core code", not a different repo.
Of course, if the community provides a wiki page for vendors to add hyperlink 
of their codes, I think it's perfect.

> Besides of user experience, the open source drivers are also used for 
> developing and verifying new features, even small-scale case.

Sure, but this also isn't affected by the code being in a separate repo.
See comments above.

> The community should and just need focus on the Neutron core and provide 
> framework for vendors' devices.

I agree, but without the open source drivers being separated as well, it's very 
difficult for the framework for external drivers to be stable enough to be 
useful.
Architecture and API. The community should ensure core and API stable enough 
and high quality. Vendors for external drivers.
Who provides, who maintains(including development, storage, distribution, 
quality, etc).

On Thu, Sep 11, 2014 at 7:24 PM, Germy Lure 
mailto:germy.l...@gmail.com>> wrote:
Some comments inline.

BR,
Germy

On Thu, Sep 11, 2014 at 5:47 PM, Kevin Benton 
mailto:blak...@gmail.com>> wrote:
This has been brought up several times already and I believe is going to be 
discussed at the Kilo summit.
Maybe I missed something, but what's the solution?

I agree that reviewing third party patches eats community time. However, 
claiming that the community pays 46% of it's energy to maintain vendor-specific 
code doesn't make any sense. LOC in the repo has very little to do with ongoing 
required maintenance. Assuming the APIs for the plugins stay consistent, there 
should be few 'maintenance' changes required to a plugin

[openstack-dev] [neutron][nova] PCI pass-through feature/topic proposals for Kilo Release

[Irena Berezovsky]

Following the last PCI pass-through meeting , we want to start thinking about 
features/add-ons that need to be addressed in the Kilo Release.

I created an etherpad (reused Doug's template) for topics related to PCI 
pass-through, mostly focused on SR-IOV networking:
https://etherpad.openstack.org/p/kilo_sriov_pci_passthrough

Please see some instructions at the top of the page.
Based on the topics interest, we may need to work out the overall details and 
propose summit session to present and get community feedback.

BR,
Irena
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters

[Irena Berezovsky]

Hi Mathieu,
We had a short discussion with Andreas about the use case stated below and also 
considered the SR-IOV related use case.
It seems that all required changes can be encapsulated in the L2 OVS agent, 
since it requires to add fdb mac registration on adapted interface. 
What was your idea related to extension manager in ML2?

Thanks,
Irena

-Original Message-
From: Mathieu Rohon [mailto:] 
Sent: Wednesday, August 27, 2014 3:11 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non 
promic mode adapters

you probably should consider using the future extension manager in ML2 :

https://review.openstack.org/#/c/89211/

On Mon, Aug 25, 2014 at 12:54 PM, Irena Berezovsky  wrote:
> Hi Andreas,
> We can definitely set some time to discuss this.
> I am usually available from 5 to 14:00 UTC.
> Let's follow up on IRC (irenab).
>
> BR,
> Irena
>
> -Original Message-
> From: Andreas Scheuring [mailto:scheu...@linux.vnet.ibm.com]
> Sent: Monday, August 25, 2014 11:00 AM
> To: Irena Berezovsky
> Cc: OpenStack Development Mailing List (not for usage questions)
> Subject: RE: [openstack-dev] [neutron][ml2] Openvswitch agent support 
> for non promic mode adapters
>
> Hi Irena,
> thanks for your reply. Yes sure, collaboration would be great.
> Do you already have a blueprint out there? Maybe wen can synchup this week to 
> discuss more details? Cause I would like to understand what exactly you're 
> looking for. Normally I'm available form 7 UTC to 16 utc (today only until 13 
> utc). My irc name is scheuran. Maybe we can get in contact this week!
>
> You also where talking about sriov. I saw some blueprint mentioning sriov & 
> macvtap. Do you have any insights into this one, too? What we also would like 
> to do is to introduce macvtap as network virtualization option. Macvtap also 
> registers mac addresses to network adapters...
>
>
> Thanks,
> Andreas
>
>
> On Sun, 2014-08-24 at 08:51 +, Irena Berezovsky wrote:
>> Hi Andreas,
>> Thank you for this initiative.
>> We were looking on similar problem for mixing OVS and SR-IOV on same network 
>> adapter, which also requires mac addresses registration of OVS ports.
>> Please let me know if you would like to collaborate on this effort.
>>
>> BR,
>> Irena
>>
>> -Original Message-
>> From: Andreas Scheuring [mailto:scheu...@linux.vnet.ibm.com]
>> Sent: Friday, August 22, 2014 11:16 AM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support 
>> for non promic mode adapters
>>
>> Thanks for your feedback.
>>
>> No, I do not yet have code for it. Just wanted to get a feeling if such a 
>> feature would get acceptance in the community.
>> But if that helps I can sit down and start some prototyping while I'm 
>> preparing a blueprint spec in parallel.
>>
>> The main part of the implementation I wanted to do on my own to get more 
>> familiar with the code base and to get more in touch with the community.
>> But of course advice and feedback of experienced neutron developers is 
>> essential!
>>
>> So I will proceed like this
>> - Create a blueprint
>> - Commit first pieces of code to get early feedback (e.g. ask via the 
>> mailing list or irc)
>> - Upload a spec (as soon as the repo is available for K)
>>
>> Does that make sense for you?
>>
>> Thanks,
>> Andreas
>>
>>
>>
>> On Thu, 2014-08-21 at 13:44 -0700, Kevin Benton wrote:
>> > I think this sounds reasonable. Do you have code for this already, 
>> > or are you looking for a developer to help implement it?
>> >
>> >
>> > On Thu, Aug 21, 2014 at 8:45 AM, Andreas Scheuring 
>> >  wrote:
>> > Hi,
>> > last week I started discussing an extension to the existing
>> > neutron
>> > openvswitch agent to support network adapters that are not in
>> > promiscuous mode. Now I would like to enhance the round to get
>> > feedback
>> > from a broader audience via the mailing list.
>> >
>> >
>> > The Problem
>> > When driving vlan or flat networking, openvswitch requires an
>> > network
>> > adapter in promiscuous mode.
>> >
>> >
>> > Why not having promiscuous mode in your adapter?
>> > - Admins like to have full control over their environment and
>> > which
>&

Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters

[Irena Berezovsky]

Hi Andreas,
We can definitely set some time to discuss this. 
I am usually available from 5 to 14:00 UTC.  
Let's follow up on IRC (irenab).

BR,
Irena

-Original Message-
From: Andreas Scheuring [mailto:scheu...@linux.vnet.ibm.com] 
Sent: Monday, August 25, 2014 11:00 AM
To: Irena Berezovsky
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: RE: [openstack-dev] [neutron][ml2] Openvswitch agent support for non 
promic mode adapters

Hi Irena,
thanks for your reply. Yes sure, collaboration would be great. 
Do you already have a blueprint out there? Maybe wen can synchup this week to 
discuss more details? Cause I would like to understand what exactly you're 
looking for. Normally I'm available form 7 UTC to 16 utc (today only until 13 
utc). My irc name is scheuran. Maybe we can get in contact this week!

You also where talking about sriov. I saw some blueprint mentioning sriov & 
macvtap. Do you have any insights into this one, too? What we also would like 
to do is to introduce macvtap as network virtualization option. Macvtap also 
registers mac addresses to network adapters...


Thanks,
Andreas


On Sun, 2014-08-24 at 08:51 +0000, Irena Berezovsky wrote:
> Hi Andreas,
> Thank you for this initiative.
> We were looking on similar problem for mixing OVS and SR-IOV on same network 
> adapter, which also requires mac addresses registration of OVS ports. 
> Please let me know if you would like to collaborate on this effort.
> 
> BR,
> Irena
> 
> -Original Message-
> From: Andreas Scheuring [mailto:scheu...@linux.vnet.ibm.com]
> Sent: Friday, August 22, 2014 11:16 AM
> To: openstack-dev@lists.openstack.org
> Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support 
> for non promic mode adapters
> 
> Thanks for your feedback. 
> 
> No, I do not yet have code for it. Just wanted to get a feeling if such a 
> feature would get acceptance in the community. 
> But if that helps I can sit down and start some prototyping while I'm 
> preparing a blueprint spec in parallel. 
> 
> The main part of the implementation I wanted to do on my own to get more 
> familiar with the code base and to get more in touch with the community.
> But of course advice and feedback of experienced neutron developers is 
> essential!
> 
> So I will proceed like this
> - Create a blueprint
> - Commit first pieces of code to get early feedback (e.g. ask via the 
> mailing list or irc)
> - Upload a spec (as soon as the repo is available for K)
> 
> Does that make sense for you?
> 
> Thanks,
> Andreas
> 
> 
> 
> On Thu, 2014-08-21 at 13:44 -0700, Kevin Benton wrote:
> > I think this sounds reasonable. Do you have code for this already, 
> > or are you looking for a developer to help implement it?
> > 
> > 
> > On Thu, Aug 21, 2014 at 8:45 AM, Andreas Scheuring 
> >  wrote:
> > Hi,
> > last week I started discussing an extension to the existing
> > neutron
> > openvswitch agent to support network adapters that are not in
> > promiscuous mode. Now I would like to enhance the round to get
> > feedback
> > from a broader audience via the mailing list.
> > 
> > 
> > The Problem
> > When driving vlan or flat networking, openvswitch requires an
> > network
> > adapter in promiscuous mode.
> > 
> > 
> > Why not having promiscuous mode in your adapter?
> > - Admins like to have full control over their environment and
> > which
> > network packets enter the system.
> > - The network adapter just does not have support for it.
> > 
> > 
> > What to do?
> > Linux net-dev driver offer an interface to manually register
> > additional
> > mac addresses (also called secondary unicast addresses).
> > Exploiting this
> > one can register additional mac addresses to the network
> > adapter. This
> > also works via a well known ip user space tool.
> > 
> > `bridge fdb add aa:aa:aa:aa:aa:aa dev eth0`
> > 
> > 
> > What to do in openstack?
> > As neutron is aware of all the mac addresses that are in use
> > it's the
> > perfect candidate for doing the mac registrations. The idea is
> > to modify
> > the neutron openvswitch agent that it does the registration on
> > "port
> > add" and "port remove" via the bridge command.
> &g

Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non promic mode adapters

[Irena Berezovsky]

Hi Andreas,
Thank you for this initiative.
We were looking on similar problem for mixing OVS and SR-IOV on same network 
adapter, which also requires mac addresses registration of OVS ports. 
Please let me know if you would like to collaborate on this effort.

BR,
Irena

-Original Message-
From: Andreas Scheuring [mailto:scheu...@linux.vnet.ibm.com] 
Sent: Friday, August 22, 2014 11:16 AM
To: openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support for non 
promic mode adapters

Thanks for your feedback. 

No, I do not yet have code for it. Just wanted to get a feeling if such a 
feature would get acceptance in the community. 
But if that helps I can sit down and start some prototyping while I'm preparing 
a blueprint spec in parallel. 

The main part of the implementation I wanted to do on my own to get more 
familiar with the code base and to get more in touch with the community.
But of course advice and feedback of experienced neutron developers is 
essential!

So I will proceed like this
- Create a blueprint
- Commit first pieces of code to get early feedback (e.g. ask via the mailing 
list or irc)
- Upload a spec (as soon as the repo is available for K)

Does that make sense for you?

Thanks,
Andreas



On Thu, 2014-08-21 at 13:44 -0700, Kevin Benton wrote:
> I think this sounds reasonable. Do you have code for this already, or 
> are you looking for a developer to help implement it?
> 
> 
> On Thu, Aug 21, 2014 at 8:45 AM, Andreas Scheuring 
>  wrote:
> Hi,
> last week I started discussing an extension to the existing
> neutron
> openvswitch agent to support network adapters that are not in
> promiscuous mode. Now I would like to enhance the round to get
> feedback
> from a broader audience via the mailing list.
> 
> 
> The Problem
> When driving vlan or flat networking, openvswitch requires an
> network
> adapter in promiscuous mode.
> 
> 
> Why not having promiscuous mode in your adapter?
> - Admins like to have full control over their environment and
> which
> network packets enter the system.
> - The network adapter just does not have support for it.
> 
> 
> What to do?
> Linux net-dev driver offer an interface to manually register
> additional
> mac addresses (also called secondary unicast addresses).
> Exploiting this
> one can register additional mac addresses to the network
> adapter. This
> also works via a well known ip user space tool.
> 
> `bridge fdb add aa:aa:aa:aa:aa:aa dev eth0`
> 
> 
> What to do in openstack?
> As neutron is aware of all the mac addresses that are in use
> it's the
> perfect candidate for doing the mac registrations. The idea is
> to modify
> the neutron openvswitch agent that it does the registration on
> "port
> add" and "port remove" via the bridge command.
> There would be a new optional configuration parameter,
> something like
> 'non-promisc-mode' that is by default set to false. Only when
> set to
> true, macs get manually registered. Otherwise the agent
> behaves like it
> does today. So I guess only very little changes to the agent
> code are
> required. From my current point of view we do not need any
> changes to
> the ml2 plug-in.
> 
> 
> Blueprint or a bug?
> I guess it's a blueprint.
> 
> What's the timeframe?
> K would be great.
> 
> 
> 
> I would be thankful for any feedback on this! Feel free to
> contact me
> anytime. Thanks in advance!
> 
> Regards,
> Andreas
> 
> (irc: scheuran)
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> 
> --
> Kevin Benton
> ___
> 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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Mellanox plugin deprecation

[Irena Berezovsky]

Hi,

As announced in the last neutron meeting [1], the Mellanox plugin is being 
deprecated.  Juno is the last release to support Mellanox  plugin.

The Mellanox ML2 Mechanism Driver is replacing the plugin and introduced since 
Icehouse release.

[1] 
http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-08-18-21.02.log.html

BR,
Irena

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Rotating the weekly Neutron meeting

[Irena Berezovsky]

+1

-Original Message-
From: Kyle Mestery [mailto:mest...@mestery.com] 
Sent: Wednesday, August 13, 2014 5:05 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron] Rotating the weekly Neutron meeting

Per this week's Neutron meeting [1], it was decided that offering a rotating 
meeting slot for the weekly Neutron meeting would be a good thing. This will 
allow for a much easier time for people in Asia/Pacific timezones, as well as 
for people in Europe.

So, I'd like to propose we rotate the weekly as follows:

Monday 2100UTC
Tuesday 1400UTC

If people are ok with these time slots, I'll set this up and we'll likely start 
with this new schedule in September, after the FPF.

Thanks!
Kyle

[1] 
http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-08-11-21.00.html

___
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] PCI support

[Irena Berezovsky]

Generally, I agree with you. But it's a little tricky.
There are different types of SR-IOV NICs and what will work for some vendor may 
be broken for another.
I think that both current SR-IOV networking flavors: Embedded switching (Intel, 
Mellanox) and Cisco VM-FEX should be verified for relevant nova patches.
What tests do you think it should run for nova side?

Thanks,
Irena

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Wednesday, August 13, 2014 10:10 AM
To: Irena Berezovsky; OpenStack Development Mailing List (not for usage 
questions)
Subject: Re: [openstack-dev] [Nova] PCI support

Hi,
If I understand correctly the only way that this work is with nova and neutron 
running. My understanding would be to have the CI running with this as the 
configuration. I just think that this should be a prerequisite similar to 
having validations of virtualization drivers.
Does that make sense?
Thanks
Gary

From: Irena Berezovsky mailto:ire...@mellanox.com>>
Date: Wednesday, August 13, 2014 at 9:01 AM
To: Gary Kotton mailto:gkot...@vmware.com>>, OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: RE: [openstack-dev] [Nova] PCI support

Hi Gary,
I understand your concern. I think CI is mandatory to ensure that code is not 
broken. While unit tests provide great value, it may end up with the code that 
does not work...
I am not sure how this code can be checked for validity without running the 
neutron part.
Probably our CI job should be triggered by nova changes in the PCI area.
What do you suggest?

Irena

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Tuesday, August 12, 2014 4:29 PM
To: Irena Berezovsky; OpenStack Development Mailing List (not for usage 
questions)
Subject: Re: [openstack-dev] [Nova] PCI support

Thanks, the concern is for the code in Nova and not in Neutron. That is, there 
is quite a lot of PCI code being added and no way of knowing that it actually 
works (unless we trust the developers working on it :)).
Thanks
Gary

From: Irena Berezovsky mailto:ire...@mellanox.com>>
Date: Tuesday, August 12, 2014 at 10:25 AM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Cc: Gary Kotton mailto:gkot...@vmware.com>>
Subject: RE: [openstack-dev] [Nova] PCI support

Hi Gary,
Mellanox already established CI support on Mellanox SR-IOV NICs, as one of the 
jobs of Mellanox External Testing CI 
(Check-MLNX-Neutron-ML2-Sriov-driver<https://urldefense.proofpoint.com/v1/url?u=http://144.76.193.39/ci-artifacts/94888/13/Check-MLNX-Neutron-ML2-Sriov-driver&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=OFhjKT9ipKmAmkiQpq6hlqZIHthaGP7q1PTygNW2RXs%3D%0A&s=13fdee114a421eeed33edf26a639f8450df6efa361ba912c41694ff75292e789>).
Meanwhile not voting, but will be soon.

BR,
Irena

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Monday, August 11, 2014 5:17 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] PCI support

Thanks for the update.

From: "Robert Li (baoli)" mailto:ba...@cisco.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, August 11, 2014 at 5:08 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Nova] PCI support

Gary,

Cisco is adding it in our CI testbed. I guess that mlnx is doing the same for 
their MD as well.

-Robert

On 8/11/14, 9:05 AM, "Gary Kotton" 
mailto:gkot...@vmware.com>> wrote:

Hi,
At the moment all of the drivers are required CI support. Are there any plans 
regarding the PIC support. I understand that this is something that requires 
specific hardware. Are there any plans to add this?
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [third-party] Update on third party CI in Neutron

[Irena Berezovsky]

Hi,
Mellanox CI was also failing due to the same issue, 
https://bugs.launchpad.net/neutron/+bug/1355780 (apparently duplicated bug for 
https://bugs.launchpad.net/neutron/+bug/1353309)
We currently fixed the issue locally, by patching the server side RPC version 
support to 1.3.

BR,
Irena


From: Hemanth Ravi [mailto:hemanthrav...@gmail.com]
Sent: Wednesday, August 13, 2014 12:24 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] [third-party] Update on third party CI 
in Neutron

Kyle,

One Convergence third-party CI is failing due to 
https://bugs.launchpad.net/neutron/+bug/1353309.

Let me know if we should turn off the CI logs until this is fixed or if we need 
to fix anything on the CI end. I think one other third-party CI (Mellanox) is 
failing due to the same issue.

Regards,
-hemanth

On Tue, Jul 29, 2014 at 6:02 AM, Kyle Mestery 
mailto:mest...@mestery.com>> wrote:
On Mon, Jul 28, 2014 at 1:42 PM, Hemanth Ravi 
mailto:hemanthrav...@gmail.com>> wrote:
> Kyle,
>
> One Convergence CI has been fixed (setup issue) and is running without the
> failures for ~10 days now. Updated the etherpad.
>
Thanks for the update Hemanth, much appreciated!

Kyle

> Thanks,
> -hemanth
>
>
> On Fri, Jul 11, 2014 at 4:50 PM, Fawad Khaliq 
> mailto:fa...@plumgrid.com>> wrote:
>>
>>
>> On Fri, Jul 11, 2014 at 8:56 AM, Kyle Mestery 
>> mailto:mest...@noironetworks.com>>
>> wrote:
>>>
>>> PLUMgrid
>>>
>>> Not saving enough logs
>>
>> All Jenkins slaves were just updated to upload all required logs. PLUMgrid
>> CI should be good now.
>>
>>
>> Thanks,
>> Fawad Khaliq
>>
>>
>> ___
>> 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
>

___
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] PCI support

[Irena Berezovsky]

Hi Gary,
I understand your concern. I think CI is mandatory to ensure that code is not 
broken. While unit tests provide great value, it may end up with the code that 
does not work...
I am not sure how this code can be checked for validity without running the 
neutron part.
Probably our CI job should be triggered by nova changes in the PCI area.
What do you suggest?

Irena

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Tuesday, August 12, 2014 4:29 PM
To: Irena Berezovsky; OpenStack Development Mailing List (not for usage 
questions)
Subject: Re: [openstack-dev] [Nova] PCI support

Thanks, the concern is for the code in Nova and not in Neutron. That is, there 
is quite a lot of PCI code being added and no way of knowing that it actually 
works (unless we trust the developers working on it :)).
Thanks
Gary

From: Irena Berezovsky mailto:ire...@mellanox.com>>
Date: Tuesday, August 12, 2014 at 10:25 AM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Cc: Gary Kotton mailto:gkot...@vmware.com>>
Subject: RE: [openstack-dev] [Nova] PCI support

Hi Gary,
Mellanox already established CI support on Mellanox SR-IOV NICs, as one of the 
jobs of Mellanox External Testing CI 
(Check-MLNX-Neutron-ML2-Sriov-driver<https://urldefense.proofpoint.com/v1/url?u=http://144.76.193.39/ci-artifacts/94888/13/Check-MLNX-Neutron-ML2-Sriov-driver&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=OFhjKT9ipKmAmkiQpq6hlqZIHthaGP7q1PTygNW2RXs%3D%0A&s=13fdee114a421eeed33edf26a639f8450df6efa361ba912c41694ff75292e789>).
Meanwhile not voting, but will be soon.

BR,
Irena

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Monday, August 11, 2014 5:17 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] PCI support

Thanks for the update.

From: "Robert Li (baoli)" mailto:ba...@cisco.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, August 11, 2014 at 5:08 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Nova] PCI support

Gary,

Cisco is adding it in our CI testbed. I guess that mlnx is doing the same for 
their MD as well.

-Robert

On 8/11/14, 9:05 AM, "Gary Kotton" 
mailto:gkot...@vmware.com>> wrote:

Hi,
At the moment all of the drivers are required CI support. Are there any plans 
regarding the PIC support. I understand that this is something that requires 
specific hardware. Are there any plans to add this?
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] make mac address updatable: which plugins?

[Irena Berezovsky]

Hi Chuck,
I'll comment regarding Mellanox Plug-in and Ml2 Mech driver  in the review.
BR,
Irena 

-Original Message-
From: Carlino, Chuck (OpenStack TripleO, Neutron) [mailto:chuck.carl...@hp.com] 
Sent: Wednesday, August 06, 2014 10:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] make mac address updatable: which 
plugins?

Yamamoto has reviewed the changes for this, and has raised the following issue 
(among others).


  *   iirc mellanox uses mac address as port identifier. what happens on 
address change?

Can someone who knows mellanox please comment, either here or in the review?

Thanks,
Chuck


On Aug 5, 2014, at 1:22 PM, "Carlino, Chuck (OpenStack TripleO, Neutron)" 
mailto:chuck.carl...@hp.com>> wrote:

Thanks for the quick responses.

Here's the WIP review:

https://review.openstack.org/112129.

The base plugin doesn't contribute to the notification decision right now, so 
I've modified the actual plugin code.

Chuck


On Aug 5, 2014, at 12:51 PM, Amir Sadoughi 
mailto:amir.sadou...@rackspace.com>>
wrote:

I agree with Kevin here. Just a note, don't bother with openvswitch and 
linuxbridge plugins as they are marked for deletion this cycle, imminently 
(already deprecated)[0].

Amir

[0] 
http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-08-04-21.02.html
 Announcements 2e.

From: Kevin Benton 
[blak...@gmail.com]
Sent: Tuesday, August 05, 2014 2:40 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] make mac address updatable: which 
plugins?

How are you implementing the change? It would be good to get to see some code 
in a review to get an idea of what needs to be updated.

If it's just a change in the DB base plugin, just let those changes propagate 
to the plugins that haven't overridden the inherited behavior.


On Tue, Aug 5, 2014 at 1:28 PM, Charles Carlino 
mailto:chuckjcarl...@gmail.com>>
 wrote:
Hi all,

I need some help regarding a bug [1] I'm working on.

The bug is basically a request to make the mac address of a port updatable.  
The use case is a baremetal (Ironic) node that has a bad NIC which must be 
replaced, resulting in a new mac address.  The bad NIC has an associated 
neutron port which of course holds the NIC's IP address.  The reason to make 
mac_address updatable (as opposed to having the user create a new port and 
delete the old one) is that during the recovery process the IP address must be 
retained and assigned to the new NIC/port, which is not guaranteed in the above 
work-around.

I'm coding the changes to do this in the ml2, openvswitch, and linuxbridge 
plugins but I'm not sure how to handle the the other plugins since I don't know 
if the associated backends are prepared to handle such updates.  My first 
thought is to disallow the update in the other plugins, but I would really 
appreciate your advice.

Kind regards,
Chuck Carlino

[1] https://bugs.launchpad.net/neutron/+bug/1341268

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Kevin Benton
___
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


___
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] PCI support

[Irena Berezovsky]

Hi Gary,
Mellanox already established CI support on Mellanox SR-IOV NICs, as one of the 
jobs of Mellanox External Testing CI 
(Check-MLNX-Neutron-ML2-Sriov-driver).
Meanwhile not voting, but will be soon.

BR,
Irena

From: Gary Kotton [mailto:gkot...@vmware.com]
Sent: Monday, August 11, 2014 5:17 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova] PCI support

Thanks for the update.

From: "Robert Li (baoli)" mailto:ba...@cisco.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, August 11, 2014 at 5:08 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Nova] PCI support

Gary,

Cisco is adding it in our CI testbed. I guess that mlnx is doing the same for 
their MD as well.

-Robert

On 8/11/14, 9:05 AM, "Gary Kotton" 
mailto:gkot...@vmware.com>> wrote:

Hi,
At the moment all of the drivers are required CI support. Are there any plans 
regarding the PIC support. I understand that this is something that requires 
specific hardware. Are there any plans to add this?
Thanks
Gary
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][SR-IOV]: RE: ML2 mechanism driver for SR-IOV capable NIC based switching, ...

[Irena Berezovsky]

Hi Robert,
Please see inline

-Original Message-
From: Robert Li (baoli) [mailto:ba...@cisco.com] 
Sent: Friday, July 25, 2014 12:44 AM
To: mest...@mestery.com; Irena Berezovsky
Cc: Akihiro Motoki; Sandhya Dasu (sadasu); OpenStack Development Mailing List 
(not for usage questions)
Subject: [openstack-dev][neutron][SR-IOV]: RE: ML2 mechanism driver for SR-IOV 
capable NIC based switching,...

Hi Kyle, 

Sorry I missed your queries on the IRC channel today. I was thinking about this 
whole BP. After chatting with Irena this morning, I think that I understand 
what this BP is trying to achieve overall. I also had a chat with Sandhya 
afterwards. I¹d like to discuss a few things in here:
  
  < Sandhya¹s MD is going to support cisco¹s VMFEX. Overall her code¹s 
structure would look like very much similar to Irena¹s patch in part 1.
However, she cannot simply inherit from SriovNicSwitchMechanismDriver. The 
differences for her code are: 1) get_vif_details() would populate profileid 
(rather than vlanid), 2) she¹d need to do vmfex specific processing in 
try_to_bind(). We¹re thinking that with a little of generalization, 
SriovNicSwitchMechanismDriver() (with a changed name such as 
SriovMechanismDriver()) can be used both for nic switch and vmfex. It would 
look like in terms of class hierarchy:
 SriovMechanismDriver
SriovNicSwitchMechanismDriver
SriovQBRMechanismDriver
 SriovCiscoVmfexMechanismDriver
[IrenaB] Seems correct hierarchy in we want to have separate MDs for NIC 
embedded switch and Cisco VMFEX cases.  But what if same deployment should 
support both cases? Two MDs should be chosen? 

Code duplication would be reduced significantly. The change would be:
   < make get_vif_details an abstract method in SriovMechanismDriver
   < make an abstract method to perform specific bind action required by a 
particular adaptor indicated in the PCI vendor info
   < vif type and agent type should be set based on the PCI vendor info 

A little change of patch part 1 would achieve the above
[IrenaB] Do you propose vif_type and agent type be determined during MD 
initialization time or during port binding attempt? 

  < Originally I thought that SR-IOV port¹s status would be depending on the 
Sriov Agent (patch part 2). After chatting with Irena, this is not the case. So 
all the SR-IOV ports will be active once created or bound according to the 
try_to_bind() method. In addition, the current Sriov Agent (patch part 2) only 
supports port admin status change for mlnx adaptor. I think these caveats need 
to be spelled out explicitly to avoid any confusion or misunderstanding, at 
least in the documentation.

[IrenaB] Agree, this  should be documented as well as whole SRIOV vNIC creation 
workflow. 
If agent is required , port won't be bound if Agent is not running on the 
required Host.
It may be the case that dynamic changes for admin state for SR-IOV VF are 
supported by other vendors as well. Existing agent also allows to expand the 
dynamic changes support for future functionality, such as QoS, ACLs, .. 

  < Sandhya has planned to support both intel and vmfex in her MD. This 
requires a hybrid sriov mech driver that populates vif details based on the PCI 
vendor info in the port. Another way to do this is to run two MDs in the same 
time, one supporting intel, the other vmfex. This would work well with the 
above classes. But it requires change of the two config options (in Irena¹s 
patch part one) so that per MD config options can be specified. I¹m not sure if 
this is practical in real deployment (meaning use of SR-IOV adaptors from 
different vendors in the same deployment), but I think it¹s doable within the 
existing ml2 framework.
[IrenaB] I think we should see how to make the deployment of the SR-IOV 
required pieces as simple and intuitive as possible.

we¹ll go over the above in the next sr-iov IRC meeting as well.
[IrenaB]  Looking forward for this discussion

Thanks,
Robert









On 7/24/14, 1:55 PM, "Kyle Mestery (Code Review)" 
wrote:

>Kyle Mestery has posted comments on this change.
>
>Change subject: ML2 mechanism driver for SR-IOV capable NIC based 
>switching, Part 2 
>..
>
>
>Patch Set 3: Code-Review+2 Workflow+1
>
>I believe Irena has answered all of Robert's questions. Any subsequent 
>issues can be handled as a followup.
>
>--
>To view, visit https://review.openstack.org/107651
>To unsubscribe, visit https://review.openstack.org/settings
>
>Gerrit-MessageType: comment
>Gerrit-Change-Id: I533ccee067935326d5837f90ba321a962e8dc2a6
>Gerrit-PatchSet: 3
>Gerrit-Project: openstack/neutron
>Gerrit-Branch: master
>Gerrit-Owner: Berezovsky Irena 
>Gerrit-Reviewer: Akihiro Motoki 
>Gerrit-Reviewer: Arista Testing 
>
&g

Re: [openstack-dev] [Neutron][ML2] Support dpdk ovs with ml2 plugin

[Irena Berezovsky]

Hi,
For agent way to notify server regarding node specific info, you can leverage 
the  periodic state report that neutron agent sends to the neutron Server.
As an option, the ML2 Mechanism Driver can check that agent report and 
depending on the
datapath_type, update vif_details.
This can be done similar to bridge_mappings:
https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/drivers/mech_openvswitch.py#43
BR,
Irena


From: Czesnowicz, Przemyslaw [mailto:przemyslaw.czesnow...@intel.com]
Sent: Thursday, July 10, 2014 6:20 PM
To: Irena Berezovsky; OpenStack Development Mailing List (not for usage 
questions)
Cc: Mooney, Sean K
Subject: RE: [openstack-dev] [Neutron][ML2] Support dpdk ovs with ml2 plugin

Hi,

Thanks for Your answers.

Yep using binding:vif_details makes more sense. We would like to reuse 
VIF_TYPE_OVS and modify the nova to use the userspace vhost when ‘use_dpdk’ 
flag is present.
What we are missing is how to inform the ml2 plugin/mechanism drivers when to 
put that ‘use_dpdk’ flag into vif_details.

On the node ovs_neutron_agent could look up datapath_type in ovsdb, but how can 
we provide that info to the plugin?
Currently there is no mechanism to get node specific info into the ml2 plugin 
(or at least we don’t see any).

Any ideas on how this could be implemented?

Regards
Przemek
From: Irena Berezovsky [mailto:ire...@mellanox.com]
Sent: Thursday, July 10, 2014 8:08 AM
To: OpenStack Development Mailing List (not for usage questions); Czesnowicz, 
Przemyslaw
Cc: Mooney, Sean K
Subject: RE: [openstack-dev] [Neutron][ML2] Support dpdk ovs with ml2 plugin

Hi,
For passing  information from neutron to nova VIF Driver, you should use 
binding:vif_details dictionary.  You may not require new VIF_TYPE, but can 
leverage the existing VIF_TYPE_OVS, and add ‘use_dpdk’   in vif_details 
dictionary. This will require some rework of the existing libvirt vif_driver 
VIF_TYPE_OVS.

Binding:profile is considered as input dictionary that is used to pass 
information required for port binding on Server side. You  may use 
binding:profile to pass in  a dpdk ovs request, so it will be taken into port 
binding consideration by ML2 plugin.

I am not sure regarding new vnic_type, since it will require  port owner to 
pass in the requested type. Is it your intention? Should the port owner be 
aware of dpdk ovs usage?
There is also VM scheduling consideration that if certain vnic_type is 
requested, VM should be scheduled on the node that can satisfy the request.

Regards,
Irena


From: loy wolfe [mailto:loywo...@gmail.com]
Sent: Thursday, July 10, 2014 6:00 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Mooney, Sean K
Subject: Re: [openstack-dev] [Neutron][ML2] Support dpdk ovs with ml2 plugin

i think both a new vnic_type and a new vif_type should be added. now vnic has 
three types: normal, direct, macvtap, then we need a new type of "uservhost".

as for vif_type, now we have VIF_TYPE_OVS, VIF_TYPE_QBH/QBG, VIF_HW_VEB, so we 
need a new VIF_TYPE_USEROVS

I don't think it's a good idea to directly reuse ovs agent, for we have to 
consider use cases that ovs and userovs co-exists. Now it's a little painful to 
fork and write a new agent, but it will be easier when ML2 agent BP is merged 
in the future. (https://etherpad.openstack.org/p/modular-l2-agent-outline)

On Wed, Jul 9, 2014 at 11:08 PM, Czesnowicz, Przemyslaw 
mailto:przemyslaw.czesnow...@intel.com>> wrote:
Hi

We (Intel Openstack team) would like to add support for dpdk based userspace 
openvswitch using mech_openvswitch and mech_odl from ML2 plugin.
The dpdk enabled ovs comes in two flavours one is netdev incorporated into 
vanilla ovs the other is a fork of ovs with a dpdk datapath 
(https://github.com/01org/dpdk-ovs ).
Both flavours use userspace vhost mechanism to connect the VMs to the switch.

Our initial approach was to extend ovs vif bindings in nova and add a config 
parameter to specify when userspace vhost should be used.
Spec : https://review.openstack.org/95805
Code: https://review.openstack.org/100256

Nova devs rejected this approach saying that Neutron should pass all necessary 
information to nova to select vif bindings.

Currently we are looking for a way to pass information from Neutron to Nova 
that dpdk enabled ovs is being used while still being able to use 
mech_openvswitch and ovs_neutron_agent or mech_odl.

We thought of two possible solutions:

1.  Use binding_profile to provide node specific info to nova.

Agent rpc api would be extended to allow agents to send node profile to neutron 
plugin.

That info would be stored in db and passed to nova when binding on this 
specific host is requested.

This could be used to support our use case or pass other info to nova (i.e name 
of integration bridge)



2.  Let mech_openvswitch and mech_odl detect what binding type to use.

When asked for port binding mech_openvswitch and mech_odl would call t

Re: [openstack-dev] [Neutron][ML2] Support dpdk ovs with ml2 plugin

[Irena Berezovsky]

Hi,
For passing  information from neutron to nova VIF Driver, you should use 
binding:vif_details dictionary.  You may not require new VIF_TYPE, but can 
leverage the existing VIF_TYPE_OVS, and add ‘use_dpdk’   in vif_details 
dictionary. This will require some rework of the existing libvirt vif_driver 
VIF_TYPE_OVS.

Binding:profile is considered as input dictionary that is used to pass 
information required for port binding on Server side. You  may use 
binding:profile to pass in  a dpdk ovs request, so it will be taken into port 
binding consideration by ML2 plugin.

I am not sure regarding new vnic_type, since it will require  port owner to 
pass in the requested type. Is it your intention? Should the port owner be 
aware of dpdk ovs usage?
There is also VM scheduling consideration that if certain vnic_type is 
requested, VM should be scheduled on the node that can satisfy the request.

Regards,
Irena


From: loy wolfe [mailto:loywo...@gmail.com]
Sent: Thursday, July 10, 2014 6:00 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Mooney, Sean K
Subject: Re: [openstack-dev] [Neutron][ML2] Support dpdk ovs with ml2 plugin

i think both a new vnic_type and a new vif_type should be added. now vnic has 
three types: normal, direct, macvtap, then we need a new type of "uservhost".

as for vif_type, now we have VIF_TYPE_OVS, VIF_TYPE_QBH/QBG, VIF_HW_VEB, so we 
need a new VIF_TYPE_USEROVS

I don't think it's a good idea to directly reuse ovs agent, for we have to 
consider use cases that ovs and userovs co-exists. Now it's a little painful to 
fork and write a new agent, but it will be easier when ML2 agent BP is merged 
in the future. (https://etherpad.openstack.org/p/modular-l2-agent-outline)

On Wed, Jul 9, 2014 at 11:08 PM, Czesnowicz, Przemyslaw 
mailto:przemyslaw.czesnow...@intel.com>> wrote:
Hi

We (Intel Openstack team) would like to add support for dpdk based userspace 
openvswitch using mech_openvswitch and mech_odl from ML2 plugin.
The dpdk enabled ovs comes in two flavours one is netdev incorporated into 
vanilla ovs the other is a fork of ovs with a dpdk datapath 
(https://github.com/01org/dpdk-ovs ).
Both flavours use userspace vhost mechanism to connect the VMs to the switch.

Our initial approach was to extend ovs vif bindings in nova and add a config 
parameter to specify when userspace vhost should be used.
Spec : https://review.openstack.org/95805
Code: https://review.openstack.org/100256

Nova devs rejected this approach saying that Neutron should pass all necessary 
information to nova to select vif bindings.

Currently we are looking for a way to pass information from Neutron to Nova 
that dpdk enabled ovs is being used while still being able to use 
mech_openvswitch and ovs_neutron_agent or mech_odl.

We thought of two possible solutions:

1.  Use binding_profile to provide node specific info to nova.

Agent rpc api would be extended to allow agents to send node profile to neutron 
plugin.

That info would be stored in db and passed to nova when binding on this 
specific host is requested.

This could be used to support our use case or pass other info to nova (i.e name 
of integration bridge)



2.  Let mech_openvswitch and mech_odl detect what binding type to use.

When asked for port binding mech_openvswitch and mech_odl would call the agent 
or odl  to check what bindings to use (VIF_TYPE_OVS or VIF_TYPE_DPDKVHOST)


So, what would be the best way to support our usecase, is it one of the above ?

Best regards
Przemek

--
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.

___
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][sriov] weekly meeting for july 1st and july 8th

[Irena Berezovsky]

I'll chair this week PCI SR-IOV pass-through meeting for those who would like 
to attend.

BR,
Irena

From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Tuesday, July 01, 2014 5:00 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova][sriov] weekly meeting for july 1st and july 8th

Hi,

I will be on PTO from Tuesday, and come back to office on July 9th Wednesday. 
Therefore, I won't be present in the next two SR-IOV weekly meetings. Regarding 
the sr-iov development status, I finally fixed all the failures in the existing 
unit tests. Rob and I are still working on adding new unit test cases in the 
PCI and libvirt driver area. Once that's done, we should be able to push 
another two patches up.

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] Mid cycle sprints

[Irena Berezovsky]

+ 1 
Would love to join the gang :)

-Original Message-
From: Assaf Muller [mailto:amul...@redhat.com] 
Sent: Friday, June 13, 2014 4:21 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova]{neutron] Mid cycle sprints



- Original Message -
> Hi,
> There is the mid cycle sprint in July for Nova and Neutron. Anyone 
> interested in maybe getting one together in Europe/Middle East around the 
> same dates?
> If people are willing to come to this part of the world I am sure that 
> we can organize a venue for a few days. Anyone interested. If we can 
> get a quorum then I will be happy to try and arrange things.

+1 on an Israel sprint :)

> Thanks
> Gary
> 
> 
> 
> ___
> 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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][ml2] Tracking the reviews for ML2 related specs

[Irena Berezovsky]

Hi Mohammad,
Thank you for sharing the links.
Can you please elaborate on columns of the table in [1]. Is [R] supposed to be 
for spec review and [C] for code review?
If this correct, would it be possible to add [C] columns for already merged 
specs that still have the code under review?

Thanks a lot,
Irena

From: Mohammad Banikazemi [mailto:m...@us.ibm.com]
Sent: Friday, June 13, 2014 8:02 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][ml2] Tracking the reviews for ML2 related 
specs


In order to make the review process a bit easier (without duplicating too much 
data and without creating too much overhead), we have created a wiki to keep 
track of the ML2 related specs for the Juno cycle [1]. The idea is to organize 
the people who participate in the ML2 subgroup activities and get the related 
specs reviewed as much as possible in the subgroup before asking the broader 
community to review. (There is of course nothing that prevents others from 
reviewing these specs as soon as they are available for review.) If you have 
any ML2 related spec under review or being planned, you may want to update the 
wiki [1] accordingly.

We will see if this will be useful or not. If you have any comments or 
suggestions please post here or bring them to the IRC weekly meetings [2].

Best,

Mohammad

[1] https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews
[2] https://wiki.openstack.org/wiki/Meetings/ML2
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][ml2] Too much "shim rest proxy" mechanism drivers in ML2

[Irena Berezovsky]

Hi Luke,
Very impressive solution!

I do not think there is a problem to keep agent out of the tree in a short 
term, but would highly recommend to put it upstream in a longer term.
You will benefit from quite valuable community review. And most important it 
will allow to keep your code as much as possible aligned with neutron code 
base. Once there are some general changes done by other people, your code will 
be taken into account and won’t be broken accidentally.
I would like to mention that there is Modular L2 Agent initiative driven by ML2 
team, you may be interested to follow: 
https://etherpad.openstack.org/p/modular-l2-agent-outline

Best Regards,
Irena

From: luk...@gmail.com [mailto:luk...@gmail.com] On Behalf Of Luke Gorrie
Sent: Tuesday, June 10, 2014 12:48 PM
To: Irena Berezovsky
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][ml2] Too much "shim rest proxy" 
mechanism drivers in ML2

Hi Irena,

Thanks for the very interesting perspective!

On 10 June 2014 10:57, Irena Berezovsky 
mailto:ire...@mellanox.com>> wrote:
[IrenaB] The DB access approach was previously used by OVS and LinuxBridge 
Agents and at some point (~Grizzly Release) was changed to use RPC 
communication.

That is very interesting. I've been involved in OpenStack since the Havana 
cycle and was not familiar with the old design.

I'm optimistic about the scalability of our implementation. We have 
sanity-tested with 300 compute nodes and a 300ms sync interval. I am sure we 
will find some parts that we need to spend optimization energy on, however.

The other scalability aspect we are being careful of is the cost of individual 
update operations. (In LinuxBridge that would be the iptables, ebtables, etc 
commands.) In our implementation the compute nodes preprocess the Neutron 
config into a small config file for the local traffic plane and then load that 
in one atomic operation ("SIGHUP" style). Again, I am sure we will find cases 
that we need to spend optimization effort on, but the design seems scalable to 
me thanks to the atomicity.

For concreteness, here is the agent we are running on the DB node to make the 
Neutron config available:
https://github.com/SnabbCo/snabbswitch/blob/master/src/designs/neutron/neutron-sync-master

and here is the agent that pulls it onto the compute node:
https://github.com/SnabbCo/snabbswitch/blob/master/src/designs/neutron/neutron-sync-agent

TL;DR we snapshot the config with mysqldump and distribute it with git.

Here's the sanity test I referred to: 
https://groups.google.com/d/msg/snabb-devel/blmDuCgoknc/PP_oMgopiB4J

I will be glad to report on our experience and what we change based on our 
deployment experience during the Juno cycle.

[IrenaB] I think that for “Non SDN Controller” Mechanism Drivers there will be 
need for some sort of agent to handle port update events even though it might 
not be required in order to bind the port.

True. Indeed, we do have an agent running on the compute host, and it we are 
synchronizing it with port updates based on the mechanism described above.

Really what I mean is: Can we keep our agent out-of-tree and apart from ML2 and 
decide for ourselves how to keep it synchronized (instead of using the MQ)? Is 
there a precedent for doing things this way in an ML2 mech driver (e.g. one of 
the SDNs)?

Cheers!
-Luke


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][ml2] Too much "shim rest proxy" mechanism drivers in ML2

[Irena Berezovsky]

Hi Luke,
Please see my comments inline.

BR,
Irena
From: Luke Gorrie [mailto:l...@tail-f.com]
Sent: Monday, June 09, 2014 12:29 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][ml2] Too much "shim rest proxy" 
mechanism drivers in ML2

On 6 June 2014 10:17, henry hly 
mailto:henry4...@gmail.com>> wrote:
ML2 mechanism drivers are becoming another kind of "plugins". Although they can 
be loaded together, but can not work with each other.
[...]
Could we remove all device related adaption(rest/ssh/netconf/of... proxy) from 
these mechanism driver to the agent side, leaving only necessary code in the 
plugin?

In the Snabb NFV mech driver [*] we are trying a design that you might find 
interesting.

We stripped the mech driver down to bare bones and declared that the agent has 
to access the Neutron configuration independently.

In practice this means that our out-of-tree agent is connecting to Neutron's 
MySQL database directly instead of being fed config changes by custom sync code 
in ML2. This means there are very little work for the mech driver to do (in our 
case check configuration and perform special port binding).
[IrenaB] The DB access approach was previously used by OVS and LinuxBridge 
Agents and at some point (~Grizzly Release) was changed to use RPC 
communication. You can see the reasons and design details covered by [1] and 
the patch itself in [2]

[1]: 
https://docs.google.com/document/d/1MbcBA2Os4b98ybdgAw2qe_68R1NG6KMh8zdZKgOlpvg/edit?pli=1
[2] https://review.openstack.org/#/c/9591/

We are also trying to avoid running an OVS/LinuxBridge-style agent on the 
compute hosts in order to keep the code footprint small. I hope we will succeed 
-- I'd love to hear if somebody else is running "agent-less"? Currently we 
depend on a really ugly workaround to make VIF binding succeed and we are 
looking for a clean alternative: 
https://github.com/lukego/neutron/commit/31d6d0657aeae9fd97a63e4d53da34fb86be92f7
[IrenaB] I think that for “Non SDN Controller” Mechanism Drivers there will be 
need for some sort of agent to handle port update events even though it might 
not be required in order to bind the port.

[*] Snabb NFV mech driver code: https://review.openstack.org/95711

Cheers,
-Luke


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][QoS] Weekly IRC Meeting?

[Irena Berezovsky]

+1 to attend,

Regards,
Irena

-Original Message-
From: Collins, Sean [mailto:sean_colli...@cable.comcast.com] 
Sent: Wednesday, May 21, 2014 5:59 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][QoS] Weekly IRC Meeting?

Hi,

The session that we had on the Quality of Service API extension was well 
attended - I would like to keep the momentum going by proposing a weekly IRC 
meeting.

How does Tuesdays at 1800 UTC in #openstack-meeting-alt sound?

--
Sean M. Collins
___
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] Informal meeting before SR-IOV summit presentation

[Irena Berezovsky]

Hi all,
Where are we going to meet for this meeting at 1:00 pm today?

-Original Message-
From: Robert Li (baoli) [mailto:ba...@cisco.com] 
Sent: Friday, May 09, 2014 10:52 PM
To: Sandhya Dasu (sadasu); Brent Eagles; Steve Gordon
Cc: Dan Smith; OpenStack Development Mailing List (not for usage questions); 
John Garbutt; Russell Bryant; yunhong-jiang; Itzik Brown; Yongli He; Jay Pipes; 
Irena Berezovsky
Subject: Re: Informal meeting before SR-IOV summit presentation

the program pods area should be open.

On 5/9/14, 3:33 PM, "Sandhya Dasu (sadasu)"  wrote:

>I have no idea, how to pick a location.
>Should we meet at the Cisco booth at 1pm and then take it from there?
>
>Any other ideas?
>
>Thanks,
>sandhya
>
>On 5/9/14 3:17 PM, "Brent Eagles"  wrote:
>
>>On 09/05/14 04:21 PM, Sandhya Dasu (sadasu) wrote:
>>> Thanks for all your replies.
>>>
>>> Thanks for the great inputs on how to frame the discussion in the 
>>>etherpad  so it becomes easier for people to get on board. We will 
>>>add author indent  to track the source of the changes. Will work on 
>>>cleaning that up.
>>>
>>> Regarding the session itself, as you probably know, there was an 
>>>attempt  in Icehouse to get the sr-iov work going. We found that the 
>>>time allotted  for the session was not sufficient to get to all the 
>>>use cases and discuss  alternate views.
>>>
>>> This time around we want to be better prepared and so would like to 
>>>keep  only a couple of open times for the actual session. Hence, the 
>>>request for  the early meeting.
>>>
>>> How does Monday 1pm sound?
>>>
>>> Thanks,
>>> Sandhya
>>
>>That time is good with me.
>>
>>Cheers,
>>
>>Brent
>>
>


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Informal meeting before SR-IOV summit presentation

[Irena Berezovsky]

Works for me as well.
What would be the meeting place? 

-Original Message-
From: Robert Li (baoli) [mailto:ba...@cisco.com] 
Sent: Friday, May 09, 2014 10:13 PM
To: Sandhya Dasu (sadasu); Steve Gordon
Cc: Dan Smith; OpenStack Development Mailing List (not for usage questions); 
John Garbutt; Russell Bryant; yunhong-jiang; Itzik Brown; Brent Eagles; Yongli 
He; Jay Pipes; Irena Berezovsky
Subject: Re: Informal meeting before SR-IOV summit presentation

It sounds good to me.

Thanks Sandhya for organizing it.

 wrote:

>Thanks for all your replies.
>
>Thanks for the great inputs on how to frame the discussion in the 
>etherpad so it becomes easier for people to get on board. We will add 
>author indent to track the source of the changes. Will work on cleaning that 
>up.
>
>Regarding the session itself, as you probably know, there was an 
>attempt in Icehouse to get the sr-iov work going. We found that the 
>time allotted for the session was not sufficient to get to all the use 
>cases and discuss alternate views.
>
>This time around we want to be better prepared and so would like to 
>keep only a couple of open times for the actual session. Hence, the 
>request for the early meeting.
>
>How does Monday 1pm sound?
>
>Thanks,
>Sandhya
>
>On 5/9/14 11:44 AM, "Steve Gordon"  wrote:
>
>>- Original Message -
>>> From: "Robert Li (baoli)" 
>>> Subject: Re: Informal meeting before SR-IOV summit presentation
>>> 
>>> This is the one that Irena created:
>>> https://etherpad.openstack.org/p/pci_passthrough_cross_project
>>
>>Thanks, I missed this as it wasn't linked from the design summit Wiki 
>>page.
>>
>>-Steve
>>
>>> On 5/8/14, 4:33 PM, "Steve Gordon"  wrote:
>>> 
>>> >- Original Message -
>>> >> > It would be nice to have an informal discussion / unconference
>>>session
>>> >> > before the actual summit session on SR-IOV. During the previous
>>>IRC
>>> >> > meeting, we were really close to identifying the different use
>>>cases.
>>> >> > There was a dangling discussion on introducing another level of 
>>> >> > indirection between the vnic_types exposed via the nova boot 
>>> >> > API
>>>and
>>> >>how
>>> >> > it would be represented internally. It would be ideal to have
>>>these 2
>>> >> > discussions converged before the summit session.
>>> >> 
>>> >> What would be the purpose of doing that before the session? IMHO, 
>>> >> a large part of being able to solve this problem is getting 
>>> >> everyone
>>>up to
>>> >> speed on what this means, what the caveats are, and what we're
>>>trying to
>>> >> solve. If we do some of that outside the scope of the larger
>>>audience, I
>>> >> expect we'll get less interaction (or end up covering it again) 
>>> >> in
>>>the
>>> >> session.
>>> >> 
>>> >> That said, if there's something I'm missing that needs to be
>>>resolved
>>> >> ahead of time, then that's fine, but I expect the best plan is to
>>>just
>>> >> keep the discussion to the session. Afterwards, additional things
>>>can be
>>> >> discussed in a one-off manner, but getting everyone on the same 
>>> >> page
>>>is
>>> >> largely the point of having a session in the first place IMHO.
>>> >
>>> >Right, in spite of my previous response...looking at the etherpad
>>>there
>>> >is nothing there to frame the discussion at the moment:
>>> >
>>> >https://etherpad.openstack.org/p/juno-nova-sriov-support
>>> >
>>> >I think populating this should be a priority rather than organizing 
>>> >another session/meeting?
>>> >
>>> >Steve
>>> 
>>> 
>>
>>--
>>Steve Gordon, RHCE
>>Product Manager, Red Hat Enterprise Linux OpenStack Platform Red Hat 
>>Canada (Toronto, Ontario)
>


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?

[Irena Berezovsky]

I would like to join this discussion.

Thanks,
Irena

-Original Message-
From: Collins, Sean [mailto:sean_colli...@cable.comcast.com] 
Sent: Tuesday, May 06, 2014 7:22 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking 
pod at the design summit?

For those attending, to discuss the QoS API current status?

-- 
Sean M. Collins
___
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

[openstack-dev] [Neutron][Nova][PCI Passthrough] Etherpad for design session discussion topics

[Irena Berezovsky]

Hi,
On the pci passthrough meeting 
(https://wiki.openstack.org/wiki/Meetings/Passthrough) we decided to create the 
etherpad page for the topics that should to be covered during cross project 
(neutron - nova) Juno design session:

Here's the link to the etherpad page:
https://etherpad.openstack.org/p/pci_passthrough_cross_project

Please fill with topics to discuss.

Thanks,
Irena
___
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] [Neutron] Problem plugging I/F into Neutron...

[Irena Berezovsky]

Hi Paul,
Please be aware that there was also change in nova to support ovs_hybrid_plug:
https://review.openstack.org/#/c/83190/
I am not sure, but maybe worth to check nova code and nova.conf  you are using 
to be aligned with neutron code.

Hope it helps,
Irena


From: Paul Michali (pcm) [mailto:p...@cisco.com]
Sent: Saturday, March 29, 2014 1:17 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Neutron] Problem plugging I/F into Neutron...

Hi,

I have a VM that I start up outside of OpenStack (as a short term solution, 
until we get it working inside a Nova VM), using KVM. It has scrips associated 
with the three interfaces that are created, to hook this VM into Neutron. One 
I/F is on br-ex (connected to the "public" network for DevStack), another to 
br-int (connected to a management network that is created), and a third is 
connected to br-int (connected to the "private" network for DevStack). It's 
understood these are hacks to get things going and can be brittle.  With 
DevStack, I have a vanilla localrc, so using ML2, without any ML2 settings 
specified.

Now, the first two scripts use internal Neutron client calls to create the 
port, and then plug the VIF. The third, uses Neutron to create the port, and 
then Nova to plug the VIF. I don't know why - I inherited the scripts.

On one system, where Nova is based on commit b3e2e05 (10 days ago), this all 
works just peachy. Interfaces are hooked in and I can ping to my hearts 
content. On another system, that I just reimaged today, using the latest and 
greatest OpenStack projects, the third script fails.

I talked to Nova folks, and the vic is now an object, instead of a plain dict, 
and therefore calls on the object fail (as the script just provides a dict). I 
started trying to convert the vif to an object, but in discussing with a 
co-worker, we thought that we could too use Neutron calls for all of the setup 
of this third interface.

Well, I tried, and the port is created, but unlike the other system, the port 
is DOWN, and I cannot ping to or from it (the other ports still work fine, with 
this newer OpenStack repo). One difference is that the port is showing  
{"port_filter": true, "ovs_hybrid_plug": true} for binding:vif_details, in the 
neutron port-show output. On the older system this is empty (so must be new 
changes in Neutron?)


Here is the Neutron based code (trimmed) to do the create and plugging:

import neutron.agent.linux.interface as vif_driver
from neutronclient.neutron import client as qclient

qc = qclient.Client('2.0', auth_url=KEYSTONE_URL, username=user, 
tenant_name=tenant, password=pw)

prefix, net_name = interface.split('__')
port_name = net_name + '_p'
try:
nw_id = qc.list_networks(name=net_name)['networks'][0]['id']
except qcexp.NeutronClientException as e:
...

p_spec = {'port': {'admin_state_up': True,
   'name': port_name,
   'network_id': nw_id,
   'mac_address': mac_addr,
   'binding:host_id': hostname,
   'device_id': vm_uuid,
   'device_owner': 'compute:None'}}

try:
port = qc.create_port(p_spec)
except qcexp.NeutronClientException as e:
...

port_id = port['port']['id']
br_name = 'br-int'

conf = cfg.CONF
config.register_root_helper(conf)
conf.register_opts(vif_driver.OPTS)

driver = vif_driver.OVSInterfaceDriver(cfg.CONF)
driver.plug(nw_id, port_id, interface, mac_addr, br_name)

Finally, here are the questions (hope you stuck with the long message)...

Any idea why the neutron version is not working? I know there were a bunch of 
recent changes.
Is there a way for me to turn off the ova_hybrid_plug and port_filter flags? 
Should I?
Should I go back to using Nova and build a VIF object?
If so, any reason why the Neutron version would not work?
Is there a way to do a similar thing, but via using Northbound APIs (so it 
isn't as brittle)?

Thanks in advance!

PCM (Paul Michali)

MAIL . p...@cisco.com
IRC ... pcm_ (irc.freenode.com)
TW  @pmichali
GPG Key ... 4525ECC253E31A83
Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] how to extend port capability using binding:profile

[Irena Berezovsky]

Hi Li Ma,
ML2 binding:profile is accessible for admin user only.
Currently it can be set via port-create/port-update CLI following this syntax:
'neutron port-create netX --binding:profile type=dict keyX=valX'

BR,
Irena

-Original Message-
From: Li Ma [mailto:m...@awcloud.com] 
Sent: Sunday, March 16, 2014 9:36 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] how to extend port capability using binding:profile

Hi all,

I'd like to extend port capability using ML2 binding:profile. I checked the 
official docs and it seems that there's no guide for it.

Is there any CLI support for port binding:profile?
Or is there any development guide on how to set up "profile"?

--
---
cheers,
Li Ma




___
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 binding of ports

[Irena Berezovsky]

Hi Robert,
I think what you mentioned can be achieved by calling into specific MD method 
from
SriovAgentMechanismDriverBase .try_to_bind_segment_for_agent mehod, maybe 
something like 'get_vif_details' before it calls to context.set_binding.
Would you mind to continue discussion over patch gerrit review 
https://review.openstack.org/#/c/74464/ ?
I think it will be easier to follow up the comments and decisions.

Thanks,
Irena

-Original Message-
From: Robert Li (baoli) [mailto:ba...@cisco.com] 
Sent: Wednesday, March 05, 2014 6:10 PM
To: Irena Berezovsky; OpenStack Development Mailing List (not for usage 
questions); Sandhya Dasu (sadasu); Robert Kukura; Brian Bowen (brbowen)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV binding of 
ports

Hi Irena,

The main reason for me to do it that way is how vif_details should be setup in 
our case. Do you need vlan in vif_details? The behavior in the existing base 
classes is that the vif_details is set during the driver init time. In our 
case, it needs to be setup during bind_port().

thanks,
Robert


On 3/5/14 7:37 AM, "Irena Berezovsky"  wrote:

>Hi Robert, Sandhya,
>I have pushed the reference implementation 
>SriovAgentMechanismDriverBase as part the following WIP:
>https://review.openstack.org/#/c/74464/
>
>The code is in mech_agent.py, and very simple code for 
>mech_sriov_nic_switch.py.
>
>Please take a look and review.
>
>BR,
>Irena
>
>-Original Message-
>From: Irena Berezovsky [mailto:ire...@mellanox.com]
>Sent: Wednesday, March 05, 2014 9:04 AM
>To: Robert Li (baoli); Sandhya Dasu (sadasu); OpenStack Development 
>Mailing List (not for usage questions); Robert Kukura; Brian Bowen
>(brbowen)
>Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV 
>binding of ports
>
>Hi Robert,
>Seems to me that many code lines are duplicated following your proposal.
>For agent based MDs, I would prefer to inherit from 
>SimpleAgentMechanismDriverBase and add there verify method for 
>supported_pci_vendor_info. Specific MD will pass the list of supported 
>pci_vendor_info list. The  'try_to_bind_segment_for_agent' method will 
>call 'supported_pci_vendor_info', and if supported continue with 
>binding flow.
>Maybe instead of a decorator method, it should be just an utility method?
>I think that the check for supported vnic_type and pci_vendor info 
>support, should be done in order to see if MD should bind the port. If 
>the answer is Yes, no more checks are required.
>
>Coming back to the question I asked earlier, for non-agent MD, how 
>would you deal with updates after port is bound, like 'admin_state_up' changes?
>I'll try to push some reference code later today.
>
>BR,
>Irena
>
>-Original Message-
>From: Robert Li (baoli) [mailto:ba...@cisco.com]
>Sent: Wednesday, March 05, 2014 4:46 AM
>To: Sandhya Dasu (sadasu); OpenStack Development Mailing List (not for 
>usage questions); Irena Berezovsky; Robert Kukura; Brian Bowen 
>(brbowen)
>Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV 
>binding of ports
>
>Hi Sandhya,
>
>I agree with you except that I think that the class should inherit from 
>MechanismDriver. I took a crack at it, and here is what I got:
>
># Copyright (c) 2014 OpenStack Foundation # All Rights Reserved.
>#
>#Licensed under the Apache License, Version 2.0 (the "License"); you
>may
>#not use this file except in compliance with the License. You may
>obtain
>#a copy of the License at
>#
># http://www.apache.org/licenses/LICENSE-2.0
>#
>#Unless required by applicable law or agreed to in writing, software
>#distributed under the License is distributed on an "AS IS" BASIS,
>WITHOUT
>#WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See
>the
>#License for the specific language governing permissions and
>limitations
>#under the License.
>
>from abc import ABCMeta, abstractmethod
>
>import functools
>import six
>
>from neutron.extensions import portbindings from 
>neutron.openstack.common import log from neutron.plugins.ml2 import 
>driver_api as api
>
>LOG = log.getLogger(__name__)
>
>
>DEFAULT_VNIC_TYPES_SUPPORTED = [portbindings.VNIC_DIRECT,
>portbindings.VNIC_MACVTAP]
>
>def check_vnic_type_and_vendor_info(f):
>@functools.wraps(f)
>def wrapper(self, context):
>vnic_type = context.current.get(portbindings.VNIC_TYPE,
>portbindings.VNIC_NORMAL)
>if vnic_type not in self.supported_vnic_types:
>LOG.debug(_("%(func_name)s: skipped due to u

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV binding of ports

[Irena Berezovsky]

Hi Robert, Sandhya,
I have pushed the reference implementation SriovAgentMechanismDriverBase as 
part the following WIP:
https://review.openstack.org/#/c/74464/

The code is in mech_agent.py, and very simple code for mech_sriov_nic_switch.py.

Please take a look and review.

BR,
Irena

-Original Message-
From: Irena Berezovsky [mailto:ire...@mellanox.com] 
Sent: Wednesday, March 05, 2014 9:04 AM
To: Robert Li (baoli); Sandhya Dasu (sadasu); OpenStack Development Mailing 
List (not for usage questions); Robert Kukura; Brian Bowen (brbowen)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV binding of 
ports

Hi Robert,
Seems to me that many code lines are duplicated following your proposal.
For agent based MDs, I would prefer to inherit from  
SimpleAgentMechanismDriverBase and add there verify method for 
supported_pci_vendor_info. Specific MD will pass the list of supported 
pci_vendor_info list. The  'try_to_bind_segment_for_agent' method will call 
'supported_pci_vendor_info', and if supported continue with binding flow. 
Maybe instead of a decorator method, it should be just an utility method?
I think that the check for supported vnic_type and pci_vendor info support, 
should be done in order to see if MD should bind the port. If the answer is 
Yes, no more checks are required.

Coming back to the question I asked earlier, for non-agent MD, how would you 
deal with updates after port is bound, like 'admin_state_up' changes?
I'll try to push some reference code later today.

BR,
Irena

-Original Message-
From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Wednesday, March 05, 2014 4:46 AM
To: Sandhya Dasu (sadasu); OpenStack Development Mailing List (not for usage 
questions); Irena Berezovsky; Robert Kukura; Brian Bowen (brbowen)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV binding of 
ports

Hi Sandhya,

I agree with you except that I think that the class should inherit from 
MechanismDriver. I took a crack at it, and here is what I got:

# Copyright (c) 2014 OpenStack Foundation # All Rights Reserved.
#
#Licensed under the Apache License, Version 2.0 (the "License"); you
may
#not use this file except in compliance with the License. You may
obtain
#a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
#Unless required by applicable law or agreed to in writing, software
#distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT
#WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See
the
#License for the specific language governing permissions and
limitations
#under the License.

from abc import ABCMeta, abstractmethod

import functools
import six

from neutron.extensions import portbindings from neutron.openstack.common 
import log from neutron.plugins.ml2 import driver_api as api

LOG = log.getLogger(__name__)


DEFAULT_VNIC_TYPES_SUPPORTED = [portbindings.VNIC_DIRECT,
portbindings.VNIC_MACVTAP]

def check_vnic_type_and_vendor_info(f):
@functools.wraps(f)
def wrapper(self, context):
vnic_type = context.current.get(portbindings.VNIC_TYPE,
portbindings.VNIC_NORMAL)
if vnic_type not in self.supported_vnic_types:
LOG.debug(_("%(func_name)s: skipped due to unsupported "
"vnic_type: %(vnic_type)s"),
  {'func_name': f.func_name, 'vnic_type': vnic_type})
return

if self.supported_pci_vendor_info:
profile = context.current.get(portbindings.PROFILE, {})
if not profile:
LOG.debug(_("%s: Missing profile in port binding"),
  f.func_name)
return
pci_vendor_info = profile.get('pci_vendor_info')
if not pci_vendor_info:
LOG.debug(_("%s: Missing pci vendor info in profile"),
  f.func_name)
return
if pci_vendor_info not in self.supported_pci_vendor_info:
LOG.debug(_("%(func_name)s: unsupported pci vendor "
"info: %(info)s"),
  {'func_name': f.func_name, 'info':
pci_vendor_info})
return
f(self, context)
return wrapper

@six.add_metaclass(ABCMeta)
class SriovMechanismDriverBase(api.MechanismDriver):
"""Base class for drivers that supports SR-IOV

The SriovMechanismDriverBase provides common code for mechanism
drivers that supports SR-IOV. Such a driver may or may not require
an agent to be running on the port's host.

MechanismDrivers that uses this base class and requires an agent must
pass the agent type to __init__(), and must implem

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV binding of ports

[Irena Berezovsky]

Hi Robert,
Seems to me that many code lines are duplicated following your proposal.
For agent based MDs, I would prefer to inherit from  
SimpleAgentMechanismDriverBase and add there verify method for 
supported_pci_vendor_info. Specific MD will pass the list of supported 
pci_vendor_info list. The  'try_to_bind_segment_for_agent' method will call 
'supported_pci_vendor_info', and if supported continue with binding flow. 
Maybe instead of a decorator method, it should be just an utility method?
I think that the check for supported vnic_type and pci_vendor info support, 
should be done in order to see if MD should bind the port. If the answer is 
Yes, no more checks are required.

Coming back to the question I asked earlier, for non-agent MD, how would you 
deal with updates after port is bound, like 'admin_state_up' changes?
I'll try to push some reference code later today.

BR,
Irena

-Original Message-
From: Robert Li (baoli) [mailto:ba...@cisco.com] 
Sent: Wednesday, March 05, 2014 4:46 AM
To: Sandhya Dasu (sadasu); OpenStack Development Mailing List (not for usage 
questions); Irena Berezovsky; Robert Kukura; Brian Bowen (brbowen)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV binding of 
ports

Hi Sandhya,

I agree with you except that I think that the class should inherit from 
MechanismDriver. I took a crack at it, and here is what I got:

# Copyright (c) 2014 OpenStack Foundation # All Rights Reserved.
#
#Licensed under the Apache License, Version 2.0 (the "License"); you
may
#not use this file except in compliance with the License. You may
obtain
#a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
#Unless required by applicable law or agreed to in writing, software
#distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT
#WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See
the
#License for the specific language governing permissions and
limitations
#under the License.

from abc import ABCMeta, abstractmethod

import functools
import six

from neutron.extensions import portbindings from neutron.openstack.common 
import log from neutron.plugins.ml2 import driver_api as api

LOG = log.getLogger(__name__)


DEFAULT_VNIC_TYPES_SUPPORTED = [portbindings.VNIC_DIRECT,
portbindings.VNIC_MACVTAP]

def check_vnic_type_and_vendor_info(f):
@functools.wraps(f)
def wrapper(self, context):
vnic_type = context.current.get(portbindings.VNIC_TYPE,
portbindings.VNIC_NORMAL)
if vnic_type not in self.supported_vnic_types:
LOG.debug(_("%(func_name)s: skipped due to unsupported "
"vnic_type: %(vnic_type)s"),
  {'func_name': f.func_name, 'vnic_type': vnic_type})
return

if self.supported_pci_vendor_info:
profile = context.current.get(portbindings.PROFILE, {})
if not profile:
LOG.debug(_("%s: Missing profile in port binding"),
  f.func_name)
return
pci_vendor_info = profile.get('pci_vendor_info')
if not pci_vendor_info:
LOG.debug(_("%s: Missing pci vendor info in profile"),
  f.func_name)
return
if pci_vendor_info not in self.supported_pci_vendor_info:
LOG.debug(_("%(func_name)s: unsupported pci vendor "
"info: %(info)s"),
  {'func_name': f.func_name, 'info':
pci_vendor_info})
return
f(self, context)
return wrapper

@six.add_metaclass(ABCMeta)
class SriovMechanismDriverBase(api.MechanismDriver):
"""Base class for drivers that supports SR-IOV

The SriovMechanismDriverBase provides common code for mechanism
drivers that supports SR-IOV. Such a driver may or may not require
an agent to be running on the port's host.

MechanismDrivers that uses this base class and requires an agent must
pass the agent type to __init__(), and must implement
try_to_bind_segment_for_agent() and check_segment_for_agent().

MechanismDrivers that uses this base class may provide supported vendor
information, and must provide the supported vnic types.
"""
def __init__(self, agent_type=None, supported_pci_vendor_info=[],
 supported_vnic_types=DEFAULT_VNIC_TYPES_SUPPORTED):
"""Initialize base class for SR-IOV capable Mechanism Drivers

:param agent_type: Constant identifying agent type in agents_db
:param supported_pci_vendor_info: a list of "vendor_id:product_id"
:param supported_

Re: [openstack-dev] Neutron: Need help with tox failure in VPN code

[Irena Berezovsky]

Hi Paul,
I think the problem for tests failure is SystemExit exception raised by 
service_base.py when fails to load drivers by plugin. It terminates the tests.

BR,
Irena
From: Paul Michali [mailto:p...@cisco.com]
Sent: Tuesday, March 04, 2014 7:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] Neutron: Need help with tox failure in VPN code

Hi,

I'm stuck and can use some guidance here...please!

I have a change set out for review that used the VPN Service Type Framework ( 
https://review.openstack.org/74144). Everything worked fine, passed Jenkins, 
etc.

Found out that the STF won't make it to I-3, so I removed the dependency from 
my change set and tried to modify the plugin.py file to use some STF logic 
(like LBaaS uses) to load the desired service driver that is specified as the 
default. Adjusted the code to no longer use provider info.

Well, in doing so, tox fails, and unfortunately there little info on the 
failure. This can be seen by running a subset of the tests, where 2 fail:

tox -e py27 -v -- neutron.tests.unit.services.vpn

only the name of a failing test case for one, and a mention of return code 10 
on another and no other info on the failure reason. I didn't see this on a full 
tox run in my repo, but Jenkins failed and Akihiro noticed it too, in running 
the above subset of the suite (thanks!).


I've narrow it down a bit, but have no idea why it fails...

One, it seems to be some interaction between test_vpnaas_driver_plugin.py and 
the two service driver tests (cisco_ipsec.py and ipsec.py). I can remove either 
one of the service driver tests cases, and it will still fail with the other 
one (so even the reference code fails).

Two, if I change plugin.py to set self.driver to the reference device driver 
(as is done in the latest patch set) it works fine with all test cases.

Three, it seems to be a test only issue, because I can run devstack with the 
login I have in plugin.py, currently commented out in __init__(), and 
successfully load either the reference or cisco service driver, by changing 
neutron.conf.

It seems like I'm doing something wrong in the loading of the service driver, 
or using this implementation, is somehow interacting with the tests.

If anyone has ideas on what is wrong, or a better way to load the service 
driver, please let me know. I was thinking I could read and parse neutron.conf 
manually and then load the service driver, but there must be a better way!

Thanks!

PCM (Paul Michali)

MAIL  p...@cisco.com
IRCpcm_  (irc.freenode.net)
TW@pmichali
GPG key4525ECC253E31A83
Fingerprint 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] PCI SRIOV meeting suspend?

[Irena Berezovsky]

Hi Yongli He,
The PCI SRIOV meeting switched back to weekly occurrences,. 
Next meeting will be today at usual time slot:
https://wiki.openstack.org/wiki/Meetings#PCI_Passthrough_Meeting

In coming meetings we would like to work on content to be proposed for Juno.
BR,
Irena

-Original Message-
From: yongli he [mailto:yongli...@intel.com] 
Sent: Tuesday, March 04, 2014 3:28 AM
To: Robert Li (baoli); Irena Berezovsky; OpenStack Development Mailing List
Subject: PCI SRIOV meeting suspend?

HI, Robert

does it stop for while?

and if you are convenient please review this patch set , check if the interface 
is ok.


https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bp/pci-extra-info,n,z

Yongli He

___
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 binding of ports

[Irena Berezovsky]

Hi Sandhya,
I mentioned the port state with regards to expected operation that can be 
applied to neutron port after neutron port is already bound to certain virtual 
interface. 
Since for my case, there will be neutron L2 agent on Host, it will manage port 
admin state locally. I am not sure how it should work for your case, and if you 
need L2 agent for this.

BR,
Irena

-Original Message-
From: Sandhya Dasu (sadasu) [mailto:sad...@cisco.com] 
Sent: Tuesday, February 25, 2014 4:19 PM
To: OpenStack Development Mailing List (not for usage questions); Irena 
Berezovsky; Robert Kukura; Robert Li (baoli); Brian Bowen (brbowen)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV binding of 
ports

Hi,
As a follow up from today's IRC, Irena, are you looking to write the below 
mentioned Base/Mixin class that inherits from AgentMechanismDriverBase class? 
When you mentioned port state, were you referring to the 
validate_port_binding() method?

Pls clarify.

Thanks,
Sandhya

On 2/6/14 7:57 AM, "Sandhya Dasu (sadasu)"  wrote:

>Hi Bob and Irena,
>   Thanks for the clarification. Irena, I am not opposed to a 
>SriovMechanismDriverBase/Mixin approach, but I want to first figure out 
>how much common functionality there is. Have you already looked at this?
>
>Thanks,
>Sandhya
>
>On 2/5/14 1:58 AM, "Irena Berezovsky"  wrote:
>
>>Please see inline my understanding
>>
>>-Original Message-
>>From: Robert Kukura [mailto:rkuk...@redhat.com]
>>Sent: Tuesday, February 04, 2014 11:57 PM
>>To: Sandhya Dasu (sadasu); OpenStack Development Mailing List (not for 
>>usage questions); Irena Berezovsky; Robert Li (baoli); Brian Bowen
>>(brbowen)
>>Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV 
>>binding of ports
>>
>>On 02/04/2014 04:35 PM, Sandhya Dasu (sadasu) wrote:
>>> Hi,
>>>  I have a couple of questions for ML2 experts regarding support 
>>> of SR-IOV ports.
>>
>>I'll try, but I think these questions might be more about how the 
>>various SR-IOV implementations will work than about ML2 itself...
>>
>>> 1. The SR-IOV ports would not be managed by ova or linuxbridge L2 
>>> agents. So, how does a MD for SR-IOV ports bind/unbind its ports to 
>>> the host? Will it just be a db update?
>>
>>I think whether or not to use an L2 agent depends on the specific 
>>SR-IOV implementation. Some (Mellanox?) might use an L2 agent, while 
>>others
>>(Cisco?) might put information in binding:vif_details that lets the 
>>nova VIF driver take care of setting up the port without an L2 agent.
>>[IrenaB] Based on VIF_Type that MD defines, and going forward with 
>>other binding:vif_details attributes, VIFDriver should do the VIF pluging 
>>part.
>>As for required networking configuration is required, it is usually 
>>done either by L2 Agent or external Controller, depends on MD.
>>
>>> 
>>> 2. Also, how do we handle the functionality in mech_agent.py, within 
>>> the SR-IOV context?
>>
>>My guess is that those SR-IOV MechanismDrivers that use an L2 agent 
>>would inherit the AgentMechanismDriverBase class if it provides useful 
>>functionality, but any MechanismDriver implementation is free to not 
>>use this base class if its not applicable. I'm not sure if an 
>>SriovMechanismDriverBase (or SriovMechanismDriverMixin) class is being 
>>planned, and how that would relate to AgentMechanismDriverBase.
>>
>>[IrenaB] Agree with Bob, and as I stated before I think there is a 
>>need for SriovMechanismDriverBase/Mixin that provides all the generic 
>>functionality and helper methods that are common to SRIOV ports.
>>-Bob
>>
>>> 
>>> Thanks,
>>> Sandhya
>>> 
>>> From: Sandhya Dasu mailto:sad...@cisco.com>>
>>> Reply-To: "OpenStack Development Mailing List (not for usage 
>>>questions)"
>>> >> <mailto:openstack-dev@lists.openstack.org>>
>>> Date: Monday, February 3, 2014 3:14 PM
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> >> <mailto:openstack-dev@lists.openstack.org>>, Irena Berezovsky  
>>>mailto:ire...@mellanox.com>>, "Robert Li (baoli)"
>>> mailto:ba...@cisco.com>>, Robert Kukura  
>>>mailto:rkuk...@redhat.com>>, "Brian Bowen  
>>>(brbowen)" mailto:brbo...@cisco.com>>
>>> Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV  
>>>extra hr of discussion today
>>> 
>>> Hi,
>&

Re: [openstack-dev] How to write a new neutron L2 plugin using ML2 framework?

[Irena Berezovsky]

Hi,
As stated below, we are already having this work both in nova and neuron.
Please take a look at the following discussions:
https://wiki.openstack.org/wiki/Meetings#PCI_Passthrough_Meeting

For neutron part there are two different flavors that are coming as part of 
this effort:
1. Cisco SRIOV supporting 802.1QBH - no L2 agent
2. Mellanox Flavor - SRIOV embedded switch ("HW_VEB") - with L2 agent.
My guess is that second flavor of SRIOV embedded switch should work for Intel 
NICs as well.

Please join the PCI pass-through meeting discussions to see that you do not do 
any redundant work or just follow-up on mailing list.

BR,
Irena


-Original Message-
From: Mathieu Rohon [mailto:mathieu.ro...@gmail.com] 
Sent: Monday, February 10, 2014 1:25 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] How to write a new neutron L2 plugin using ML2 
framework?

Hi,

SRIOV is under implementation in nova and neutron. Did you have a look to :
https://wiki.openstack.org/wiki/PCI_passthrough_SRIOV_support
https://blueprints.launchpad.net/neutron/+spec/ml2-binding-profile
https://blueprints.launchpad.net/neutron/+spec/ml2-request-vnic-type
https://blueprints.launchpad.net/nova/+spec/pci-passthrough-sriov


On Mon, Feb 10, 2014 at 7:27 AM, Isaku Yamahata  
wrote:
> On Sat, Feb 08, 2014 at 03:49:46AM +, "Yang, Yi Y" 
>  wrote:
>
>> Hi, All
>
> Hi.
>
>
>> I want to write a new neutron L2 plugin using ML2 framework, I noticed 
>> openvswitch and linxubridge have been ported into ML2 framework, but it 
>> seems many code is removed compared to standalone L2 plugin, I guess some 
>> code has been written into a common library. Now I want to write a L2 plugin 
>> to enable switch for a SR-IOV 10g NIC, I think I need to write as follows:
>

having such a feature would be awesome : did you fill a BP for that?

>
>> 1. a new mechanism driver neutron/plugins/ml2/drivers/mech_XXX.py, but from 
>> source code, it seems nothing to do.

You mean, you want to use AgentMechanismDriverBase directly? this is an 
abstract class du to check_segment_for_agent method.

>
> This requires to define how your plugin utilize network.
> If multi tenant network is wanted, what/how technology will be used.
> The common one is VLAN or tunneling(GRE, VXLAN).
> This depends on what feature your NIC supports.
>

>> 2. a new agent neutron/plugins/XXX/ XXX_neutron_plugin.py

I don't know if this would be mandatory. May be you can just add necessary 
informations with extend_port_dict while your MD bind the port, as proposed by 
this patch :
https://review.openstack.org/#/c/69783/

Nova will then configure the port correctly. The only need for an agent would 
be to populate the agent DB with supported segment types, so that during 
bind_port, the MD find an appropriate segment (with check_segment_for_agent).

>>
>> After this, an issue it how to let neutron know it and load it by default or 
>> by configuration. Debugging is also an issue, nobody can write code 
>> correctly once :-),  does neutron have any good debugging way for a newbie?
>
> LOG.debug and debug middle ware.
> If there are any other better way, I'd also like to know.
>
> thanks,
>
>> I'm very eager to be able to get your help and sincerely thank you in 
>> advance.
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> --
> Isaku Yamahata 
>
> ___
> 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

___
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 binding of ports

[Irena Berezovsky]

Please see inline my understanding

-Original Message-
From: Robert Kukura [mailto:rkuk...@redhat.com] 
Sent: Tuesday, February 04, 2014 11:57 PM
To: Sandhya Dasu (sadasu); OpenStack Development Mailing List (not for usage 
questions); Irena Berezovsky; Robert Li (baoli); Brian Bowen (brbowen)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV binding of 
ports

On 02/04/2014 04:35 PM, Sandhya Dasu (sadasu) wrote:
> Hi,
>  I have a couple of questions for ML2 experts regarding support of 
> SR-IOV ports.

I'll try, but I think these questions might be more about how the various 
SR-IOV implementations will work than about ML2 itself...

> 1. The SR-IOV ports would not be managed by ova or linuxbridge L2 
> agents. So, how does a MD for SR-IOV ports bind/unbind its ports to 
> the host? Will it just be a db update?

I think whether or not to use an L2 agent depends on the specific SR-IOV 
implementation. Some (Mellanox?) might use an L2 agent, while others
(Cisco?) might put information in binding:vif_details that lets the nova VIF 
driver take care of setting up the port without an L2 agent.
[IrenaB] Based on VIF_Type that MD defines, and going forward with other 
binding:vif_details attributes, VIFDriver should do the VIF pluging part. As 
for required networking configuration is required, it is usually done either by 
L2 Agent or external Controller, depends on MD.

> 
> 2. Also, how do we handle the functionality in mech_agent.py, within 
> the SR-IOV context?

My guess is that those SR-IOV MechanismDrivers that use an L2 agent would 
inherit the AgentMechanismDriverBase class if it provides useful functionality, 
but any MechanismDriver implementation is free to not use this base class if 
its not applicable. I'm not sure if an SriovMechanismDriverBase (or 
SriovMechanismDriverMixin) class is being planned, and how that would relate to 
AgentMechanismDriverBase.

[IrenaB] Agree with Bob, and as I stated before I think there is a need for 
SriovMechanismDriverBase/Mixin that provides all the generic functionality and 
helper methods that are common to SRIOV ports.  
-Bob

> 
> Thanks,
> Sandhya
> 
> From: Sandhya Dasu mailto:sad...@cisco.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>  <mailto:openstack-dev@lists.openstack.org>>
> Date: Monday, February 3, 2014 3:14 PM
> To: "OpenStack Development Mailing List (not for usage questions)"
>  <mailto:openstack-dev@lists.openstack.org>>, Irena Berezovsky 
> mailto:ire...@mellanox.com>>, "Robert Li (baoli)"
> mailto:ba...@cisco.com>>, Robert Kukura 
> mailto:rkuk...@redhat.com>>, "Brian Bowen 
> (brbowen)" mailto:brbo...@cisco.com>>
> Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV 
> extra hr of discussion today
> 
> Hi,
> Since, openstack-meeting-alt seems to be in use, baoli and myself 
> are moving to openstack-meeting. Hopefully, Bob Kukura & Irena can 
> join soon.
> 
> Thanks,
> Sandhya
> 
> From: Sandhya Dasu mailto:sad...@cisco.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>  <mailto:openstack-dev@lists.openstack.org>>
> Date: Monday, February 3, 2014 1:26 PM
> To: Irena Berezovsky  <mailto:ire...@mellanox.com>>, "Robert Li (baoli)"  <mailto:ba...@cisco.com>>, Robert Kukura  <mailto:rkuk...@redhat.com>>, "OpenStack Development Mailing List (not for 
> usage questions)"
>  <mailto:openstack-dev@lists.openstack.org>>, "Brian Bowen (brbowen)"
> mailto:brbo...@cisco.com>>
> Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV 
> extra hr of discussion today
> 
> Hi all,
> Both openstack-meeting and openstack-meeting-alt are available 
> today. Lets meet at UTC 2000 @ openstack-meeting-alt.
> 
> Thanks,
> Sandhya
> 
> From: Irena Berezovsky  <mailto:ire...@mellanox.com>>
> Date: Monday, February 3, 2014 12:52 AM
> To: Sandhya Dasu mailto:sad...@cisco.com>>, "Robert 
> Li (baoli)" mailto:ba...@cisco.com>>, Robert Kukura 
> mailto:rkuk...@redhat.com>>, "OpenStack 
> Development Mailing List (not for usage questions)"
>  <mailto:openstack-dev@lists.openstack.org>>, "Brian Bowen (brbowen)"
> mailto:brbo...@cisco.com>>
> Subject: RE: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on 
> Jan. 30th
> 
> Hi Sandhya,
> 
> Can you please elaborate how do you suggest to extend the below bp for 
> SRIOV Ports managed by different Mechanism Driver?
> 
> I am not biased to any specific direction here, just think we need 
> common layer for manag

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV extra hr of discussion today

[Irena Berezovsky]

Seems the openstack-meeting-alt is busy, let's use openstack-meeting

From: Sandhya Dasu (sadasu) [mailto:sad...@cisco.com]
Sent: Monday, February 03, 2014 8:28 PM
To: Irena Berezovsky; Robert Li (baoli); Robert Kukura; OpenStack Development 
Mailing List (not for usage questions); Brian Bowen (brbowen)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV extra hr of 
discussion today

Hi all,
Both openstack-meeting and openstack-meeting-alt are available today. Lets 
meet at UTC 2000 @ openstack-meeting-alt.

Thanks,
Sandhya

From: Irena Berezovsky mailto:ire...@mellanox.com>>
Date: Monday, February 3, 2014 12:52 AM
To: Sandhya Dasu mailto:sad...@cisco.com>>, "Robert Li 
(baoli)" mailto:ba...@cisco.com>>, Robert Kukura 
mailto:rkuk...@redhat.com>>, "OpenStack Development Mailing 
List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>, 
"Brian Bowen (brbowen)" mailto:brbo...@cisco.com>>
Subject: RE: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Hi Sandhya,
Can you please elaborate how do you suggest to extend the below bp for SRIOV 
Ports managed by different Mechanism Driver?
I am not biased to any specific direction here, just think we need common layer 
for managing SRIOV port at neutron, since there is a common pass between nova 
and neutron.

BR,
Irena


From: Sandhya Dasu (sadasu) [mailto:sad...@cisco.com]
Sent: Friday, January 31, 2014 6:46 PM
To: Irena Berezovsky; Robert Li (baoli); Robert Kukura; OpenStack Development 
Mailing List (not for usage questions); Brian Bowen (brbowen)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Hi Irena,
  I was initially looking at 
https://blueprints.launchpad.net/neutron/+spec/ml2-typedriver-extra-port-info 
to take care of the extra information required to set up the SR-IOV port. When 
the scope of the BP was being decided, we had very little info about our own 
design so I didn't give any feedback about SR-IOV ports. But, I feel that this 
is the direction we should be going. Maybe we should target this in Juno.

Introducing, SRIOVPortProfileMixin would be creating yet another way to take 
care of extra port config. Let me know what you think.

Thanks,
Sandhya

From: Irena Berezovsky mailto:ire...@mellanox.com>>
Date: Thursday, January 30, 2014 4:13 PM
To: "Robert Li (baoli)" mailto:ba...@cisco.com>>, Robert 
Kukura mailto:rkuk...@redhat.com>>, Sandhya Dasu 
mailto:sad...@cisco.com>>, "OpenStack Development Mailing 
List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>, 
"Brian Bowen (brbowen)" mailto:brbo...@cisco.com>>
Subject: RE: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Robert,
Thank you very much for the summary.
Please, see inline

From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Thursday, January 30, 2014 10:45 PM
To: Robert Kukura; Sandhya Dasu (sadasu); Irena Berezovsky; OpenStack 
Development Mailing List (not for usage questions); Brian Bowen (brbowen)
Subject: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Hi,

We made a lot of progress today. We agreed that:
-- vnic_type will be a top level attribute as binding:vnic_type
-- BPs:
 * Irena's 
https://blueprints.launchpad.net/neutron/+spec/ml2-request-vnic-type for 
binding:vnic_type
 * Bob to submit a BP for binding:profile in ML2. SRIOV input info will be 
encapsulated in binding:profile
 * Bob to submit a BP for binding:vif_details in ML2. SRIOV output info 
will be encapsulated in binding:vif_details, which may include other 
information like security parameters. For SRIOV, vlan_id and profileid are 
candidates.
-- new arguments for port-create will be implicit arguments. Future release may 
make them explicit. New argument: --binding:vnic_type {virtio, direct, macvtap}.
I think that currently we can make do without the profileid as an input 
parameter from the user. The mechanism driver will return a profileid in the 
vif output.

Please correct any misstatement in above.

Issues:
  -- do we need a common utils/driver for SRIOV generic parts to be used by 
individual Mechanism drivers that support SRIOV? More details on what would be 
included in this sriov utils/driver? I'm thinking that a candidate would be the 
helper functions to interpret the pci_slot, which is proposed as a string. 
Anything else in your mind?
[IrenaB] I thought on some SRIOVPortProfileMixin to handle and persist SRIOV 
port related attributes

  -- what should mechanism drivers put in binding:vif_details and how nova 
would use this information? as far as I see it from the code, a VIF object is 
created and populated based on information provided by neutron (from get 
network and get port)

Questions:
  -- nova needs to work with both ML2 and non-ML2 plugins. For regular plugins, 

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

[Irena Berezovsky]

Hi Sandhya,
Can you please elaborate how do you suggest to extend the below bp for SRIOV 
Ports managed by different Mechanism Driver?
I am not biased to any specific direction here, just think we need common layer 
for managing SRIOV port at neutron, since there is a common pass between nova 
and neutron.

BR,
Irena


From: Sandhya Dasu (sadasu) [mailto:sad...@cisco.com]
Sent: Friday, January 31, 2014 6:46 PM
To: Irena Berezovsky; Robert Li (baoli); Robert Kukura; OpenStack Development 
Mailing List (not for usage questions); Brian Bowen (brbowen)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Hi Irena,
  I was initially looking at 
https://blueprints.launchpad.net/neutron/+spec/ml2-typedriver-extra-port-info 
to take care of the extra information required to set up the SR-IOV port. When 
the scope of the BP was being decided, we had very little info about our own 
design so I didn't give any feedback about SR-IOV ports. But, I feel that this 
is the direction we should be going. Maybe we should target this in Juno.

Introducing, SRIOVPortProfileMixin would be creating yet another way to take 
care of extra port config. Let me know what you think.

Thanks,
Sandhya

From: Irena Berezovsky mailto:ire...@mellanox.com>>
Date: Thursday, January 30, 2014 4:13 PM
To: "Robert Li (baoli)" mailto:ba...@cisco.com>>, Robert 
Kukura mailto:rkuk...@redhat.com>>, Sandhya Dasu 
mailto:sad...@cisco.com>>, "OpenStack Development Mailing 
List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>, 
"Brian Bowen (brbowen)" mailto:brbo...@cisco.com>>
Subject: RE: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Robert,
Thank you very much for the summary.
Please, see inline

From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Thursday, January 30, 2014 10:45 PM
To: Robert Kukura; Sandhya Dasu (sadasu); Irena Berezovsky; OpenStack 
Development Mailing List (not for usage questions); Brian Bowen (brbowen)
Subject: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Hi,

We made a lot of progress today. We agreed that:
-- vnic_type will be a top level attribute as binding:vnic_type
-- BPs:
 * Irena's 
https://blueprints.launchpad.net/neutron/+spec/ml2-request-vnic-type for 
binding:vnic_type
 * Bob to submit a BP for binding:profile in ML2. SRIOV input info will be 
encapsulated in binding:profile
 * Bob to submit a BP for binding:vif_details in ML2. SRIOV output info 
will be encapsulated in binding:vif_details, which may include other 
information like security parameters. For SRIOV, vlan_id and profileid are 
candidates.
-- new arguments for port-create will be implicit arguments. Future release may 
make them explicit. New argument: --binding:vnic_type {virtio, direct, macvtap}.
I think that currently we can make do without the profileid as an input 
parameter from the user. The mechanism driver will return a profileid in the 
vif output.

Please correct any misstatement in above.

Issues:
  -- do we need a common utils/driver for SRIOV generic parts to be used by 
individual Mechanism drivers that support SRIOV? More details on what would be 
included in this sriov utils/driver? I'm thinking that a candidate would be the 
helper functions to interpret the pci_slot, which is proposed as a string. 
Anything else in your mind?
[IrenaB] I thought on some SRIOVPortProfileMixin to handle and persist SRIOV 
port related attributes

  -- what should mechanism drivers put in binding:vif_details and how nova 
would use this information? as far as I see it from the code, a VIF object is 
created and populated based on information provided by neutron (from get 
network and get port)

Questions:
  -- nova needs to work with both ML2 and non-ML2 plugins. For regular plugins, 
binding:vnic_type will not be set, I guess. Then would it be treated as a 
virtio type? And if a non-ML2 plugin wants to support SRIOV, would it need to  
implement vnic-type, binding:profile, binding:vif-details for SRIOV itself?
[IrenaB] vnic_type will be added as an additional attribute to binding 
extension. For persistency it should be added in PortBindingMixin for non ML2. 
I didn't think to cover it as part of ML2 vnic_type bp.
For the rest attributes, need to see what Bob plans.

 -- is a neutron agent making decision based on the binding:vif_type?  In that 
case, it makes sense for binding:vnic_type not to be exposed to agents.
[IrenaB] vnic_type is input parameter that will eventually cause certain 
vif_type to be sent to GenericVIFDriver and create network interface. Neutron 
agents periodically scan for attached interfaces. For example, OVS agent will 
look only for OVS interfaces, so if SRIOV interface is created, it won't be 
discovered by OVS agent.

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. 30th

[Irena Berezovsky]

Robert,
Thank you very much for the summary.
Please, see inline

From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Thursday, January 30, 2014 10:45 PM
To: Robert Kukura; Sandhya Dasu (sadasu); Irena Berezovsky; OpenStack 
Development Mailing List (not for usage questions); Brian Bowen (brbowen)
Subject: [openstack-dev] [nova][neutron] PCI pass-through SRIOV on Jan. 30th

Hi,

We made a lot of progress today. We agreed that:
-- vnic_type will be a top level attribute as binding:vnic_type
-- BPs:
 * Irena's 
https://blueprints.launchpad.net/neutron/+spec/ml2-request-vnic-type for 
binding:vnic_type
 * Bob to submit a BP for binding:profile in ML2. SRIOV input info will be 
encapsulated in binding:profile
 * Bob to submit a BP for binding:vif_details in ML2. SRIOV output info 
will be encapsulated in binding:vif_details, which may include other 
information like security parameters. For SRIOV, vlan_id and profileid are 
candidates.
-- new arguments for port-create will be implicit arguments. Future release may 
make them explicit. New argument: --binding:vnic_type {virtio, direct, macvtap}.
I think that currently we can make do without the profileid as an input 
parameter from the user. The mechanism driver will return a profileid in the 
vif output.

Please correct any misstatement in above.

Issues:
  -- do we need a common utils/driver for SRIOV generic parts to be used by 
individual Mechanism drivers that support SRIOV? More details on what would be 
included in this sriov utils/driver? I'm thinking that a candidate would be the 
helper functions to interpret the pci_slot, which is proposed as a string. 
Anything else in your mind?
[IrenaB] I thought on some SRIOVPortProfileMixin to handle and persist SRIOV 
port related attributes

  -- what should mechanism drivers put in binding:vif_details and how nova 
would use this information? as far as I see it from the code, a VIF object is 
created and populated based on information provided by neutron (from get 
network and get port)

Questions:
  -- nova needs to work with both ML2 and non-ML2 plugins. For regular plugins, 
binding:vnic_type will not be set, I guess. Then would it be treated as a 
virtio type? And if a non-ML2 plugin wants to support SRIOV, would it need to  
implement vnic-type, binding:profile, binding:vif-details for SRIOV itself?
[IrenaB] vnic_type will be added as an additional attribute to binding 
extension. For persistency it should be added in PortBindingMixin for non ML2. 
I didn't think to cover it as part of ML2 vnic_type bp.
For the rest attributes, need to see what Bob plans.

 -- is a neutron agent making decision based on the binding:vif_type?  In that 
case, it makes sense for binding:vnic_type not to be exposed to agents.
[IrenaB] vnic_type is input parameter that will eventually cause certain 
vif_type to be sent to GenericVIFDriver and create network interface. Neutron 
agents periodically scan for attached interfaces. For example, OVS agent will 
look only for OVS interfaces, so if SRIOV interface is created, it won't be 
discovered by OVS agent.

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

[Irena Berezovsky]

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


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

[Irena Berezovsky]

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" 
mailto: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.com<mailto: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 
266<https://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 
424<https://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 defin

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

[Irena Berezovsky]

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" 
mailto: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

[Irena Berezovsky]

Hi Nrupal,
We definitely consider both these cases.
Agree with you that we should aim to support both.

BR,
Irena


From: Jani, Nrupal [mailto:nrupal.j...@intel.com]
Sent: Monday, January 27, 2014 11:17 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

Hi,

There are two possibilities for the hybrid compute nodes

-  In the first case, a compute node has two NICs,  one SRIOV NIC & the 
other NIC for the VirtIO

-  In the 2nd case, Compute node has only one SRIOV NIC, where VFs are 
used for the VMs, either macvtap or direct assignment.  And the PF is used for 
the uplink to the linux bridge or OVS!!

My question to the team is whether we consider both of these deployments or not?

Thx,

Nrupal

From: Irena Berezovsky [mailto:ire...@mellanox.com]
Sent: Monday, January 27, 2014 1:01 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

Hi Robert,
Please see inline

From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Monday, January 27, 2014 10:29 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

Hi Irena,

I agree on your first comment.

see inline as well.

thanks,
Robert

On 1/27/14 10:54 AM, "Irena Berezovsky" 
mailto:ire...@mellanox.com>> wrote:

Hi Robert, all,
My comments inline

Regards,
Irena
From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Monday, January 27, 2014 5:05 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

Hi Folks,

In today's meeting, we discussed a scheduler issue for SRIOV. The basic 
requirement is for coexistence of the following compute nodes in a cloud:
  -- SRIOV only compute nodes
  -- non-SRIOV only compute nodes
  -- Compute nodes that can support both SRIOV and non-SRIOV ports. Lack of 
a proper name, let's call them compute nodes with hybrid NICs support, or 
simply hybrid compute nodes.

I'm not sure if it's practical in having hybrid compute nodes in a real cloud. 
But it may be useful in the lab to bench mark the performance differences 
between SRIOV, non-SRIOV, and coexistence of both.
[IrenaB]
I would like to clarify a bit on the requirements you stated below.
As I see it, the hybrid compute nodes actually can be preferred in the real 
cloud, since one can define VM with one vNIC attached via SR-IOV virtual 
function while the other via some vSwitch.
But it definitely make sense to land VM with 'virtio' vNICs only on the 
non-SRIOV compute node.

Maybe there should be some sort of preference order of suitable nodes in 
scheduler choice, based on vnic types required for the VM.

In a cloud that supports SRIOV in some of the compute nodes, a request such as:

 nova boot -flavor m1.large -image  --nic net-id= vm

doesn't require a SRIOV port. However, it's possible for the nova scheduler to 
place it on a compute node that supports sriov port only. Since neutron plugin 
runs on the controller, port-create would succeed unless neutron knows the host 
doesn't support non-sriov port. But connectivity on the node would not be 
established since no agent is running on that host to establish such 
connectivity.
[IrenaB] I
Having ML2 plugin as neutron backend, will fail to bind the port, in no agent 
is running on the Host

[ROBERT] If a host supports SRIOV only, and there is an agent running on the 
host to support SRIOV, would binding succeed in ML2 plugin for the above 'nova 
boot' request?
[IrenaB] I think by adding the vnic_typem as we plan, Mechanism Driver will 
bind the port only if it supports vic_type and there is live agent on this 
host. So it should work

On a hybrid compute node, can we run multiple neutron L2 agents on a single 
host? It seems possible.

Irena brought up the idea of using host aggregate. This requires creation of a 
non-SRIOV host aggregate, and use that in the above 'nova boot' command. It 
should work.

The patch I had introduced a new constraint in the existing PCI passthrough 
filter.

The consensus seems to be having a better solution in a later release. And for 
now, people can either use host aggregate or resort to their own means.

Let's keep the discussion going on this.

Thanks,
Robert





On 1/24/14 4:50 PM, "Robert Li (baoli)" 
mailto:ba...@cisco.com>> wrote:

Hi Folks,

Based on Thursday's discussion and a chat with Irena, I took the liberty to add 
a summary and discussion points for SRIOV on Monday and onwards. Check it out 
https://wiki.openstack.org/wiki/Meetings/Passthrough. Please feel free to 
update it. Let's try to finalize it next week. The goal is to determine the BPs 
that need to get approved, and to start coding.

thanks,
Robe

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

[Irena Berezovsky]

Hi Robert,
Thank you for raising this issue.
Neutron side support for hybrid compute node is part of the mission  I want to 
achieve by implementing:
https://blueprints.launchpad.net/neutron/+spec/ml2-request-vnic-type.
I think it should be allowed to run more than one agent on certain node and 
Mechanism driver will bind the port if:

1.   It supports requested vnic_type

2.   Capable to manage segment for requested port (taking in to account 
physical network, network type, alive agent,..)
I think at least for now, new agents will be added and not mixed into existing 
one. But it may be a good idea to come up with Modular Agent.

BR,
Irena

From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Monday, January 27, 2014 11:16 PM
To: Irena Berezovsky; OpenStack Development Mailing List (not for usage 
questions)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

Ok, this is something that's going to be added in ml2. I was looking at the 
bind_port() routine in mech_agent.py. The routine check_segment_for_agent() 
seems to be performing static check. So we are going to add something like 
check_vnic_type_for_agent(), I guess? Is the pairing of an agent with the mech 
driver predetermined? The routine bind_port() just throws warnings, though.

In any case, this is after the fact the scheduler has decided to place the VM 
onto the host.

Maybe not for now, but we need to consider how to support the hybrid compute 
nodes. Would an agent be able to support multiple vnic types? Or is it possible 
to reuse ovs agent, in the same time running another agent to support sriov? 
Any thoughts?

--Robert

On 1/27/14 4:01 PM, "Irena Berezovsky" 
mailto:ire...@mellanox.com>> wrote:

Hi Robert,
Please see inline

From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Monday, January 27, 2014 10:29 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

Hi Irena,

I agree on your first comment.

see inline as well.

thanks,
Robert

On 1/27/14 10:54 AM, "Irena Berezovsky" 
mailto:ire...@mellanox.com>> wrote:

Hi Robert, all,
My comments inline

Regards,
Irena
From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Monday, January 27, 2014 5:05 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

Hi Folks,

In today's meeting, we discussed a scheduler issue for SRIOV. The basic 
requirement is for coexistence of the following compute nodes in a cloud:
  -- SRIOV only compute nodes
  -- non-SRIOV only compute nodes
  -- Compute nodes that can support both SRIOV and non-SRIOV ports. Lack of 
a proper name, let's call them compute nodes with hybrid NICs support, or 
simply hybrid compute nodes.

I'm not sure if it's practical in having hybrid compute nodes in a real cloud. 
But it may be useful in the lab to bench mark the performance differences 
between SRIOV, non-SRIOV, and coexistence of both.
[IrenaB]
I would like to clarify a bit on the requirements you stated below.
As I see it, the hybrid compute nodes actually can be preferred in the real 
cloud, since one can define VM with one vNIC attached via SR-IOV virtual 
function while the other via some vSwitch.
But it definitely make sense to land VM with 'virtio' vNICs only on the 
non-SRIOV compute node.

Maybe there should be some sort of preference order of suitable nodes in 
scheduler choice, based on vnic types required for the VM.

In a cloud that supports SRIOV in some of the compute nodes, a request such as:

 nova boot -flavor m1.large -image  --nic net-id= vm

doesn't require a SRIOV port. However, it's possible for the nova scheduler to 
place it on a compute node that supports sriov port only. Since neutron plugin 
runs on the controller, port-create would succeed unless neutron knows the host 
doesn't support non-sriov port. But connectivity on the node would not be 
established since no agent is running on that host to establish such 
connectivity.
[IrenaB] I
Having ML2 plugin as neutron backend, will fail to bind the port, in no agent 
is running on the Host

[ROBERT] If a host supports SRIOV only, and there is an agent running on the 
host to support SRIOV, would binding succeed in ML2 plugin for the above 'nova 
boot' request?
[IrenaB] I think by adding the vnic_typem as we plan, Mechanism Driver will 
bind the port only if it supports vic_type and there is live agent on this 
host. So it should work

On a hybrid compute node, can we run multiple neutron L2 agents on a single 
host? It seems possible.

Irena brought up the idea of using host aggregate. This requires creation of a 
non-SRIOV host aggregate, and use that in the above 'nova boot' command. It 
should work.

The patch I had introduced a new constraint in the existing PCI passthrough 
filter.

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

[Irena Berezovsky]

Hi Robert,
Please see inline

From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Monday, January 27, 2014 10:29 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

Hi Irena,

I agree on your first comment.

see inline as well.

thanks,
Robert

On 1/27/14 10:54 AM, "Irena Berezovsky" 
mailto:ire...@mellanox.com>> wrote:

Hi Robert, all,
My comments inline

Regards,
Irena
From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Monday, January 27, 2014 5:05 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

Hi Folks,

In today's meeting, we discussed a scheduler issue for SRIOV. The basic 
requirement is for coexistence of the following compute nodes in a cloud:
  -- SRIOV only compute nodes
  -- non-SRIOV only compute nodes
  -- Compute nodes that can support both SRIOV and non-SRIOV ports. Lack of 
a proper name, let's call them compute nodes with hybrid NICs support, or 
simply hybrid compute nodes.

I'm not sure if it's practical in having hybrid compute nodes in a real cloud. 
But it may be useful in the lab to bench mark the performance differences 
between SRIOV, non-SRIOV, and coexistence of both.
[IrenaB]
I would like to clarify a bit on the requirements you stated below.
As I see it, the hybrid compute nodes actually can be preferred in the real 
cloud, since one can define VM with one vNIC attached via SR-IOV virtual 
function while the other via some vSwitch.
But it definitely make sense to land VM with 'virtio' vNICs only on the 
non-SRIOV compute node.

Maybe there should be some sort of preference order of suitable nodes in 
scheduler choice, based on vnic types required for the VM.

In a cloud that supports SRIOV in some of the compute nodes, a request such as:

 nova boot -flavor m1.large -image  --nic net-id= vm

doesn't require a SRIOV port. However, it's possible for the nova scheduler to 
place it on a compute node that supports sriov port only. Since neutron plugin 
runs on the controller, port-create would succeed unless neutron knows the host 
doesn't support non-sriov port. But connectivity on the node would not be 
established since no agent is running on that host to establish such 
connectivity.
[IrenaB] I
Having ML2 plugin as neutron backend, will fail to bind the port, in no agent 
is running on the Host

[ROBERT] If a host supports SRIOV only, and there is an agent running on the 
host to support SRIOV, would binding succeed in ML2 plugin for the above 'nova 
boot' request?
[IrenaB] I think by adding the vnic_typem as we plan, Mechanism Driver will 
bind the port only if it supports vic_type and there is live agent on this 
host. So it should work

On a hybrid compute node, can we run multiple neutron L2 agents on a single 
host? It seems possible.

Irena brought up the idea of using host aggregate. This requires creation of a 
non-SRIOV host aggregate, and use that in the above 'nova boot' command. It 
should work.

The patch I had introduced a new constraint in the existing PCI passthrough 
filter.

The consensus seems to be having a better solution in a later release. And for 
now, people can either use host aggregate or resort to their own means.

Let's keep the discussion going on this.

Thanks,
Robert





On 1/24/14 4:50 PM, "Robert Li (baoli)" 
mailto:ba...@cisco.com>> wrote:

Hi Folks,

Based on Thursday's discussion and a chat with Irena, I took the liberty to add 
a summary and discussion points for SRIOV on Monday and onwards. Check it out 
https://wiki.openstack.org/wiki/Meetings/Passthrough. Please feel free to 
update it. Let's try to finalize it next week. The goal is to determine the BPs 
that need to get approved, and to start coding.

thanks,
Robert


On 1/22/14 8:03 AM, "Robert Li (baoli)" 
mailto:ba...@cisco.com>> wrote:

Sounds great! Let's do it on Thursday.

--Robert

On 1/22/14 12:46 AM, "Irena Berezovsky" 
mailto:ire...@mellanox.com>> wrote:

Hi Robert, all,
I would suggest not to delay the SR-IOV discussion to the next week.
Let's try to cover the SRIOV side and especially the nova-neutron interaction 
points and interfaces this Thursday.
Once we have the interaction points well defined, we can run parallel patches 
to cover the full story.

Thanks a lot,
Irena

From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Wednesday, January 22, 2014 12:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova][neutron] PCI passthrough SRIOV

Hi Folks,

As the debate about PCI flavor versus host aggregate goes on, I'd like to move 
forward with the SRIOV side of things in the same time. I know that tomorrow's 
IRC will be focusing on the BP review, and it may well c

Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

[Irena Berezovsky]

Hi Robert, all,
My comments inline

Regards,
Irena
From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Monday, January 27, 2014 5:05 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova][neutron] PCI pass-through SRIOV

Hi Folks,

In today's meeting, we discussed a scheduler issue for SRIOV. The basic 
requirement is for coexistence of the following compute nodes in a cloud:
  -- SRIOV only compute nodes
  -- non-SRIOV only compute nodes
  -- Compute nodes that can support both SRIOV and non-SRIOV ports. Lack of 
a proper name, let's call them compute nodes with hybrid NICs support, or 
simply hybrid compute nodes.

I'm not sure if it's practical in having hybrid compute nodes in a real cloud. 
But it may be useful in the lab to bench mark the performance differences 
between SRIOV, non-SRIOV, and coexistence of both.
[IrenaB]
I would like to clarify a bit on the requirements you stated below.
As I see it, the hybrid compute nodes actually can be preferred in the real 
cloud, since one can define VM with one vNIC attached via SR-IOV virtual 
function while the other via some vSwitch.
But it definitely make sense to land VM with 'virtio' vNICs only on the 
non-SRIOV compute node.

Maybe there should be some sort of preference order of suitable nodes in 
scheduler choice, based on vnic types required for the VM.

In a cloud that supports SRIOV in some of the compute nodes, a request such as:

 nova boot -flavor m1.large -image  --nic net-id= vm

doesn't require a SRIOV port. However, it's possible for the nova scheduler to 
place it on a compute node that supports sriov port only. Since neutron plugin 
runs on the controller, port-create would succeed unless neutron knows the host 
doesn't support non-sriov port. But connectivity on the node would not be 
established since no agent is running on that host to establish such 
connectivity.
[IrenaB] I
Having ML2 plugin as neutron backend, will fail to bind the port, in no agent 
is running on the Host

Irena brought up the idea of using host aggregate. This requires creation of a 
non-SRIOV host aggregate, and use that in the above 'nova boot' command. It 
should work.

The patch I had introduced a new constraint in the existing PCI passthrough 
filter.

The consensus seems to be having a better solution in a later release. And for 
now, people can either use host aggregate or resort to their own means.

Let's keep the discussion going on this.

Thanks,
Robert





On 1/24/14 4:50 PM, "Robert Li (baoli)" 
mailto:ba...@cisco.com>> wrote:

Hi Folks,

Based on Thursday's discussion and a chat with Irena, I took the liberty to add 
a summary and discussion points for SRIOV on Monday and onwards. Check it out 
https://wiki.openstack.org/wiki/Meetings/Passthrough. Please feel free to 
update it. Let's try to finalize it next week. The goal is to determine the BPs 
that need to get approved, and to start coding.

thanks,
Robert


On 1/22/14 8:03 AM, "Robert Li (baoli)" 
mailto:ba...@cisco.com>> wrote:

Sounds great! Let's do it on Thursday.

--Robert

On 1/22/14 12:46 AM, "Irena Berezovsky" 
mailto:ire...@mellanox.com>> wrote:

Hi Robert, all,
I would suggest not to delay the SR-IOV discussion to the next week.
Let's try to cover the SRIOV side and especially the nova-neutron interaction 
points and interfaces this Thursday.
Once we have the interaction points well defined, we can run parallel patches 
to cover the full story.

Thanks a lot,
Irena

From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Wednesday, January 22, 2014 12:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova][neutron] PCI passthrough SRIOV

Hi Folks,

As the debate about PCI flavor versus host aggregate goes on, I'd like to move 
forward with the SRIOV side of things in the same time. I know that tomorrow's 
IRC will be focusing on the BP review, and it may well continue into Thursday. 
Therefore, let's start discussing SRIOV side of things on Monday.

Basically, we need to work out the details on:
-- regardless it's PCI flavor or host aggregate or something else, how 
to use it to specify a SRIOV port.
-- new parameters for -nic
-- new parameters for neutron net-create/neutron port-create
-- interface between nova and neutron
-- nova side of work
-- neutron side of work

We should start coding ASAP.

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

[Irena Berezovsky]

Hi Robert, all,
I would suggest not to delay the SR-IOV discussion to the next week.
Let's try to cover the SRIOV side and especially the nova-neutron interaction 
points and interfaces this Thursday.
Once we have the interaction points well defined, we can run parallel patches 
to cover the full story.

Thanks a lot,
Irena

From: Robert Li (baoli) [mailto:ba...@cisco.com]
Sent: Wednesday, January 22, 2014 12:02 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [nova][neutron] PCI passthrough SRIOV

Hi Folks,

As the debate about PCI flavor versus host aggregate goes on, I'd like to move 
forward with the SRIOV side of things in the same time. I know that tomorrow's 
IRC will be focusing on the BP review, and it may well continue into Thursday. 
Therefore, let's start discussing SRIOV side of things on Monday.

Basically, we need to work out the details on:
-- regardless it's PCI flavor or host aggregate or something else, how 
to use it to specify a SRIOV port.
-- new parameters for -nic
-- new parameters for neutron net-create/neutron port-create
-- interface between nova and neutron
-- nova side of work
-- neutron side of work

We should start coding ASAP.

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

[Irena Berezovsky]

Hi,
Having post PCI meeting discussion with Ian based on his proposal 
https://docs.google.com/document/d/1vadqmurlnlvZ5bv3BlUbFeXRS_wh-dsgi5plSjimWjU/edit?pli=1#,
I am  not sure that the case that quite usable for SR-IOV based networking is 
covered well by this proposal. The understanding I got is that VM can land on 
the Host that will lack suitable PCI resource.
Can you please provide an example for the required cloud admin PCI related 
configurations on nova-compute and controller node with regards to the 
following simplified scenario:
 -- There are 2 provider networks (phy1, phy2), each one has associated range 
on vlan-ids
 -- Each compute node has 2 vendor adapters with SR-IOV  enabled feature, 
exposing xx Virtual Functions.
 -- Every VM vnic on virtual network on provider network  phy1 or phy2  should 
be pci pass-through vnic. 

Thanks a lot,
Irena

-Original Message-
From: Robert Li (baoli) [mailto:ba...@cisco.com] 
Sent: Saturday, January 18, 2014 12:33 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

Yunhong,

I'm hoping that these comments can be directly addressed:
  a practical deployment scenario that requires arbitrary attributes.
  detailed design on the following (that also take into account the 
introduction of predefined attributes):
* PCI stats report since the scheduler is stats based
* the scheduler in support of PCI flavors with arbitrary attributes and 
potential overlapping.
  networking requirements to support multiple provider nets/physical nets

I guess that the above will become clear as the discussion goes on. And we also 
need to define the deliveries
 
Thanks,
Robert

On 1/17/14 2:02 PM, "Jiang, Yunhong"  wrote:

>Robert, thanks for your long reply. Personally I'd prefer option 2/3 as 
>it keep Nova the only entity for PCI management.
>
>Glad you are ok with Ian's proposal and we have solution to resolve the 
>libvirt network scenario in that framework.
>
>Thanks
>--jyh
>
>> -Original Message-
>> From: Robert Li (baoli) [mailto:ba...@cisco.com]
>> Sent: Friday, January 17, 2014 7:08 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through 
>> network support
>> 
>> Yunhong,
>> 
>> Thank you for bringing that up on the live migration support. In 
>>addition  to the two solutions you mentioned, Irena has a different 
>>solution. Let me  put all the them here again:
>> 1. network xml/group based solution.
>>In this solution, each host that supports a provider 
>>net/physical  net can define a SRIOV group (it's hard to avoid the 
>>term as you can see  from the suggestion you made based on the PCI 
>>flavor proposal). For each  SRIOV group supported on a compute node, A 
>>network XML will be  created the  first time the nova compute service 
>>is running on that node.
>> * nova will conduct scheduling, but not PCI device allocation
>> * it's a simple and clean solution, documented in libvirt as 
>>the  way to support live migration with SRIOV. In addition, a network 
>>xml is  nicely mapped into a provider net.
>> 2. network xml per PCI device based solution
>>This is the solution you brought up in this email, and Ian  
>>mentioned this to me as well. In this solution, a network xml is 
>>created  when A VM is created. the network xml needs to be removed 
>>once the  VM is  removed. This hasn't been tried out as far as I  
>>know.
>> 3. interface xml/interface rename based solution
>>Irena brought this up. In this solution, the ethernet 
>>interface  name corresponding to the PCI device attached to the VM 
>>needs to be  renamed. One way to do so without requiring system reboot 
>>is to change  the  udev rule's file for interface renaming, followed 
>>by a udev reload.
>> 
>> Now, with the first solution, Nova doesn't seem to have control over 
>>or  visibility of the PCI device allocated for the VM before the VM is  
>>launched. This needs to be confirmed with the libvirt support and see 
>>if  such capability can be provided. This may be a potential drawback 
>>if a  neutron plugin requires detailed PCI device information for operation.
>> Irena may provide more insight into this. Ideally, neutron shouldn't 
>>need  this information because the device configuration can be done by 
>>libvirt  invoking the PCI device driver.
>> 
>> The other two solutions are similar. For example, you can view the 
>>second  solution as one way to rename an interface, or camouflage an 
>>interface  under a network name. They all require additional works 
>>before the VM is  created and after the VM is removed.
>> 
>> I also agree with you that we should take a look at XenAPI on this.
>> 
>> 
>> With regard to your suggestion on how to implement the first solution 
>>with  some predefined group attribute, I think it defi

Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

[Irena Berezovsky]

Hi Robert, Yonhong,
Although network XML solution (option 1) is very elegant, it has one major 
disadvantage. As Robert mentioned, the disadvantage of the network XML is the 
inability to know what SR-IOV PCI device was actually allocated. When neutron 
is responsible to set networking configuration, manage admin status, set 
security groups, it should be able to identify the SR-IOV PCI device to apply 
configuration. Within current libvirt Network XML implementation, it does not 
seem possible.
Between option (2) and (3), I do not have any preference, it should be as 
simple as possible.
Option (3) that I raised can be achieved by renaming the network interface of 
Virtual Function via 'ip link set  name'. Interface logical name can be based 
on neutron port UUID. This will  allow neutron to discover devices, if backend 
plugin requires it. Once VM is migrating, suitable Virtual Function on the 
target node should be allocated, and then its corresponding network interface 
should be renamed to same logical name. This can be done without system 
rebooting. Still need to check how the Virtual Function corresponding network 
interface can be returned to its original name once is not used anymore as VM 
vNIC.

Regards,
Irena 

-Original Message-
From: Jiang, Yunhong [mailto:yunhong.ji...@intel.com] 
Sent: Friday, January 17, 2014 9:06 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

Robert, thanks for your long reply. Personally I'd prefer option 2/3 as it keep 
Nova the only entity for PCI management.

Glad you are ok with Ian's proposal and we have solution to resolve the libvirt 
network scenario in that framework.

Thanks
--jyh

> -Original Message-
> From: Robert Li (baoli) [mailto:ba...@cisco.com]
> Sent: Friday, January 17, 2014 7:08 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network 
> support
> 
> Yunhong,
> 
> Thank you for bringing that up on the live migration support. In 
> addition to the two solutions you mentioned, Irena has a different 
> solution. Let me put all the them here again:
> 1. network xml/group based solution.
>In this solution, each host that supports a provider 
> net/physical net can define a SRIOV group (it's hard to avoid the term 
> as you can see from the suggestion you made based on the PCI flavor 
> proposal). For each SRIOV group supported on a compute node, A network 
> XML will be created the first time the nova compute service is running 
> on that node.
> * nova will conduct scheduling, but not PCI device allocation
> * it's a simple and clean solution, documented in libvirt as 
> the way to support live migration with SRIOV. In addition, a network 
> xml is nicely mapped into a provider net.
> 2. network xml per PCI device based solution
>This is the solution you brought up in this email, and Ian 
> mentioned this to me as well. In this solution, a network xml is 
> created when A VM is created. the network xml needs to be removed once 
> the VM is removed. This hasn't been tried out as far as I  know.
> 3. interface xml/interface rename based solution
>Irena brought this up. In this solution, the ethernet interface 
> name corresponding to the PCI device attached to the VM needs to be 
> renamed. One way to do so without requiring system reboot is to change 
> the udev rule's file for interface renaming, followed by a udev 
> reload.
> 
> Now, with the first solution, Nova doesn't seem to have control over 
> or visibility of the PCI device allocated for the VM before the VM is 
> launched. This needs to be confirmed with the libvirt support and see 
> if such capability can be provided. This may be a potential drawback 
> if a neutron plugin requires detailed PCI device information for operation.
> Irena may provide more insight into this. Ideally, neutron shouldn't 
> need this information because the device configuration can be done by 
> libvirt invoking the PCI device driver.
> 
> The other two solutions are similar. For example, you can view the 
> second solution as one way to rename an interface, or camouflage an 
> interface under a network name. They all require additional works 
> before the VM is created and after the VM is removed.
> 
> I also agree with you that we should take a look at XenAPI on this.
> 
> 
> With regard to your suggestion on how to implement the first solution 
> with some predefined group attribute, I think it definitely can be 
> done. As I have pointed it out earlier, the PCI flavor proposal is 
> actually a generalized version of the PCI group. In other words, in 
> the PCI group proposal, we have one predefined attribute called PCI 
> group, and everything else works on top of that. In the PCI flavor 
> proposal, attribute is arbitrary. So certainly we can define a 
> parti

Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

[Irena Berezovsky]

Ian,
Thank you for putting in writing the ongoing discussed specification.
I have added few comments on the Google doc [1].

As for live migration support, this can be done also without libvirt network 
usage.
Not very elegant, but working:  rename the interface of the PCI device to some 
logical name, let's say based on neutron port UUID and put it into the 
interface XML, i.e.:
If PCI device network interface name  is eth8 and neutron port UUID is   
02bc4aec-b4f4-436f-b651-024 then rename it to something like: eth02bc4aec-b4'. 
The interface XML will look like this:

  ...










...

[1] 
https://docs.google.com/document/d/1vadqmurlnlvZ5bv3BlUbFeXRS_wh-dsgi5plSjimWjU/edit?pli=1#heading=h.308b0wqn1zde

BR,
Irena
From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
Sent: Thursday, January 16, 2014 2:34 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

To clarify a couple of Robert's points, since we had a conversation earlier:
On 15 January 2014 23:47, Robert Li (baoli) 
mailto:ba...@cisco.com>> wrote:
  ---  do we agree that BDF address (or device id, whatever you call it), and 
node id shouldn't be used as attributes in defining a PCI flavor?

Note that the current spec doesn't actually exclude it as an option.  It's just 
an unwise thing to do.  In theory, you could elect to define your flavors using 
the BDF attribute but determining 'the card in this slot is equivalent to all 
the other cards in the same slot in other machines' is probably not the best 
idea...  We could lock it out as an option or we could just assume that 
administrators wouldn't be daft enough to try.
* the compute node needs to know the PCI flavor. [...]
  - to support live migration, we need to use it to create 
network xml

I didn't understand this at first and it took me a while to get what Robert 
meant here.

This is based on Robert's current code for macvtap based live migration.  The 
issue is that if you wish to migrate a VM and it's tied to a physical 
interface, you can't guarantee that the same physical interface is going to be 
used on the target machine, but at the same time you can't change the 
libvirt.xml as it comes over with the migrating machine.  The answer is to 
define a network and refer out to it from libvirt.xml.  In Robert's current 
code he's using the group name of the PCI devices to create a network 
containing the list of equivalent devices (those in the group) that can be 
macvtapped.  Thus when the host migrates it will find another, equivalent, 
interface.  This falls over in the use case under consideration where a device 
can be mapped using more than one flavor, so we have to discard the use case or 
rethink the implementation.

There's a more complex solution - I think - where we create a temporary network 
for each macvtap interface a machine's going to use, with a name based on the 
instance UUID and port number, and containing the device to map.  Before 
starting the migration we would create a replacement network containing only 
the new device on the target host; migration would find the network from the 
name in the libvirt.xml, and the content of that network would behave 
identically.  We'd be creating libvirt networks on the fly and a lot more of 
them, and we'd need decent cleanup code too ('when freeing a PCI device, delete 
any network it's a member of'), so it all becomes a lot more hairy.
--
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 network support

[Irena Berezovsky]

Ian,
It's great news.
Thank you for bringing Bob's attention to this effort. I'll look for Bob on IRC 
to get the details.
And of course, core support raises our chances to make PCI pass-through 
networking into icehouse.

BR,
Irena

From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
Sent: Monday, January 13, 2014 2:02 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

Irena, have a word with Bob (rkukura on IRC, East coast), he was talking about 
what would be needed already and should be able to help you.  Conveniently he's 
also core. ;)
--
Ian.

On 12 January 2014 22:12, Irena Berezovsky 
mailto:ire...@mellanox.com>> wrote:
Hi John,
Thank you for taking an initiative and summing up the work that need to be done 
to provide PCI pass-through network support.
The only item I think is missing is the neutron support for PCI pass-through. 
Currently we have Mellanox Plugin that supports PCI pass-through assuming 
Mellanox Adapter card embedded switch technology. But in order to have fully 
integrated  PCI pass-through networking support for the use cases Robert listed 
on previous mail, the generic neutron PCI pass-through support is required. 
This can be enhanced with vendor specific task that may differ (Mellanox 
Embedded switch vs Cisco 802.1BR), but there is still common part of being PCI 
aware mechanism driver.
I have already started with definition for this part:
https://docs.google.com/document/d/1RfxfXBNB0mD_kH9SamwqPI8ZM-jg797ky_Fze7SakRc/edit#<https://docs.google.com/document/d/1RfxfXBNB0mD_kH9SamwqPI8ZM-jg797ky_Fze7SakRc/edit>
I also plan to start coding soon.

Depends on how it goes, I can take also nova parts that integrate with neutron 
APIs from item 3.

Regards,
Irena

-Original Message-
From: John Garbutt [mailto:j...@johngarbutt.com<mailto:j...@johngarbutt.com>]
Sent: Friday, January 10, 2014 4:34 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support
Apologies for this top post, I just want to move this discussion towards action.

I am traveling next week so it is unlikely that I can make the meetings. Sorry.

Can we please agree on some concrete actions, and who will do the coding?
This also means raising new blueprints for each item of work.
I am happy to review and eventually approve those blueprints, if you email me 
directly.

Ideas are taken from what we started to agree on, mostly written up here:
https://wiki.openstack.org/wiki/Meetings/Passthrough#Definitions


What doesn't need doing...


We have PCI whitelist and PCI alias at the moment, let keep those names the 
same for now.
I personally prefer PCI-flavor, rather than PCI-alias, but lets discuss any 
rename separately.

We seemed happy with the current system (roughly) around GPU passthrough:
nova flavor-key  set "pci_passthrough:alias"=" 
large_GPU:1,small_GPU:2"
nova boot --image some_image --flavor  

Again, we seemed happy with the current PCI whitelist.

Sure, we could optimise the scheduling, but again, please keep that a separate 
discussion.
Something in the scheduler needs to know how many of each PCI alias are 
available on each host.
How that information gets there can be change at a later date.

PCI alias is in config, but its probably better defined using host aggregates, 
or some custom API.
But lets leave that for now, and discuss it separately.
If the need arrises, we can migrate away from the config.


What does need doing...
==

1) API & CLI changes for "nic-type", and associated tempest tests

* Add a user visible "nic-type" so users can express on of several network 
types.
* We need a default nic-type, for when the user doesn't specify one (might 
default to SRIOV in some cases)
* We can easily test the case where the default is virtual and the user 
expresses a preference for virtual
* Above is much better than not testing it at all.

nova boot --flavor m1.large --image 
  --nic net-id=
  --nic net-id=,nic-type=fast
  --nic net-id=,nic-type=fast 

or

neutron port-create
  --fixed-ip subnet_id=,ip_address=192.168.57.101
  --nic-type=
  
nova boot --flavor m1.large --image  --nic port-id=

Where nic-type is just an extra bit metadata string that is passed to nova and 
the VIF driver.


2) Expand PCI alias information

We need extensions to PCI alias so we can group SRIOV devices better.

I still think we are yet to agree on a format, but I would suggest this as a 
starting point:

{
 "name":"GPU_fast",
 devices:[
  {"vendor_id":"1137","product_id":"0071", address:"*", "attach-type":"direct"},
  {"vendor_id":"1137","product_id":"0072", address:"*

Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

[Irena Berezovsky]

Hi,
After having a lot of discussions both on IRC and mailing list, I would like to 
suggest to define basic use cases for PCI pass-through network support with 
agreed list of limitations and assumptions  and implement it.  By doing this 
Proof of Concept we will be able to deliver basic PCI pass-through network 
support in Icehouse timeframe and understand better how to provide complete 
solution starting from  tenant /admin API enhancement, enhancing nova-neutron 
communication and eventually provide neutron plugin  supporting the PCI 
pass-through networking.
We can try to split tasks between currently involved participants and bring up 
the basic case. Then we can enhance the implementation.
Having more knowledge and experience with neutron parts, I would like  to start 
working on neutron mechanism driver support.  I have already started to arrange 
the following blueprint doc based on everyone's ideas:
https://docs.google.com/document/d/1RfxfXBNB0mD_kH9SamwqPI8ZM-jg797ky_Fze7SakRc/edit#

For the basic PCI pass-through networking case we can assume the following:

1.   Single provider network (PN1)

2.   White list of available SRIOV PCI devices for allocation as NIC for 
neutron networks on provider network  (PN1) is defined on each compute node

3.   Support directly assigned SRIOV PCI pass-through device as vNIC. (This 
will limit the number of tests)

4.   More 


If my suggestion seems reasonable to you, let's try to reach an agreement and 
split the work during our Monday IRC meeting.

BR,
Irena

From: Jiang, Yunhong [mailto:yunhong.ji...@intel.com]
Sent: Saturday, January 11, 2014 8:36 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

Comments with prefix [yjiang5_2] , including the double confirm.

I think we (you and me) is mostly on the same page, would you please give a 
summary, and then we can have community , including Irena/Robert, to check it. 
We need Cores to sponsor it. We should check with John to see if this is 
different with his mentor picture, and we may need a neutron core (I assume 
Cisco has a bunch of Neutron cores :) )to sponsor it?

And, will anyone from Cisco can help on the implementation? After this long 
discussion, we are in half bottom of I release and I'm not sure if Yongli and I 
alone can finish them in I release.

Thanks
--jyh

From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
Sent: Friday, January 10, 2014 6:34 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support


>
> OK - so if this is good then I think the question is how we could change the 
> 'pci_whitelist' parameter we have - which, as you say, should either *only* 
> do whitelisting or be renamed - to allow us to add information.  Yongli has 
> something along those lines but it's not flexible and it distinguishes poorly 
> between which bits are extra information and which bits are matching 
> expressions (and it's still called pci_whitelist) - but even with those 
> criticisms it's very close to what we're talking about.  When we have that I 
> think a lot of the rest of the arguments should simply resolve themselves.
>
>
>
> [yjiang5_1] The reason that not easy to find a flexible/distinguishable 
> change to pci_whitelist is because it combined two things. So a stupid/naive 
> solution in my head is, change it to VERY generic name, 
> 'pci_devices_information',
>
> and change schema as an array of {'devices_property'=regex exp, 'group_name' 
> = 'g1'} dictionary, and the device_property expression can be 'address ==xxx, 
> vendor_id == xxx' (i.e. similar with current white list),  and we can squeeze 
> more into the "pci_devices_information" in future, like 'network_information' 
> = xxx or "Neutron specific information" you required in previous mail.


We're getting to the stage that an expression parser would be useful, 
annoyingly, but if we are going to try and squeeze it into JSON can I suggest:

{ match = { class = "Acme inc. discombobulator" }, info = { group = "we like 
teh groups", volume = "11" } }

[yjiang5_2] Double confirm that 'match' is whitelist, and info is 'extra info', 
right?  Can the key be more meaningful, for example, 
s/match/pci_device_property,  s/info/pci_device_info, or s/match/pci_devices/  
etc.
Also assume the class should be the class code in the configuration space, and 
be digital, am I right? Otherwise, it's not easy to get the 'Acme inc. 
discombobulator' information.


>
> All keys other than 'device_property' becomes extra information, i.e. 
> software defined property. These extra information will be carried with the 
> PCI devices,. Some implementation details, A)we can limit the acceptable 
> keys, like we only support 'group_name', 'network_id', or we can accept any 

Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

[Irena Berezovsky]

Hi John,
Thank you for taking an initiative and summing up the work that need to be done 
to provide PCI pass-through network support.
The only item I think is missing is the neutron support for PCI pass-through. 
Currently we have Mellanox Plugin that supports PCI pass-through assuming 
Mellanox Adapter card embedded switch technology. But in order to have fully 
integrated  PCI pass-through networking support for the use cases Robert listed 
on previous mail, the generic neutron PCI pass-through support is required. 
This can be enhanced with vendor specific task that may differ (Mellanox 
Embedded switch vs Cisco 802.1BR), but there is still common part of being PCI 
aware mechanism driver. 
I have already started with definition for this part:
https://docs.google.com/document/d/1RfxfXBNB0mD_kH9SamwqPI8ZM-jg797ky_Fze7SakRc/edit#
I also plan to start coding soon.

Depends on how it goes, I can take also nova parts that integrate with neutron 
APIs from item 3.
 
Regards,
Irena

-Original Message-
From: John Garbutt [mailto:j...@johngarbutt.com] 
Sent: Friday, January 10, 2014 4:34 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

Apologies for this top post, I just want to move this discussion towards action.

I am traveling next week so it is unlikely that I can make the meetings. Sorry.

Can we please agree on some concrete actions, and who will do the coding?
This also means raising new blueprints for each item of work.
I am happy to review and eventually approve those blueprints, if you email me 
directly.

Ideas are taken from what we started to agree on, mostly written up here:
https://wiki.openstack.org/wiki/Meetings/Passthrough#Definitions


What doesn't need doing...


We have PCI whitelist and PCI alias at the moment, let keep those names the 
same for now.
I personally prefer PCI-flavor, rather than PCI-alias, but lets discuss any 
rename separately.

We seemed happy with the current system (roughly) around GPU passthrough:
nova flavor-key  set "pci_passthrough:alias"=" 
large_GPU:1,small_GPU:2"
nova boot --image some_image --flavor  

Again, we seemed happy with the current PCI whitelist.

Sure, we could optimise the scheduling, but again, please keep that a separate 
discussion.
Something in the scheduler needs to know how many of each PCI alias are 
available on each host.
How that information gets there can be change at a later date.

PCI alias is in config, but its probably better defined using host aggregates, 
or some custom API.
But lets leave that for now, and discuss it separately.
If the need arrises, we can migrate away from the config.


What does need doing...
==

1) API & CLI changes for "nic-type", and associated tempest tests

* Add a user visible "nic-type" so users can express on of several network 
types.
* We need a default nic-type, for when the user doesn't specify one (might 
default to SRIOV in some cases)
* We can easily test the case where the default is virtual and the user 
expresses a preference for virtual
* Above is much better than not testing it at all.

nova boot --flavor m1.large --image 
  --nic net-id=
  --nic net-id=,nic-type=fast
  --nic net-id=,nic-type=fast 

or

neutron port-create
  --fixed-ip subnet_id=,ip_address=192.168.57.101
  --nic-type=
  
nova boot --flavor m1.large --image  --nic port-id=

Where nic-type is just an extra bit metadata string that is passed to nova and 
the VIF driver.


2) Expand PCI alias information

We need extensions to PCI alias so we can group SRIOV devices better.

I still think we are yet to agree on a format, but I would suggest this as a 
starting point:

{
 "name":"GPU_fast",
 devices:[
  {"vendor_id":"1137","product_id":"0071", address:"*", "attach-type":"direct"},
  {"vendor_id":"1137","product_id":"0072", address:"*", "attach-type":"direct"} 
 ],
 sriov_info: {}
}

{
 "name":"NIC_fast",
 devices:[
  {"vendor_id":"1137","product_id":"0071", address:"0:[1-50]:2:*", 
"attach-type":"macvtap"}
  {"vendor_id":"1234","product_id":"0081", address:"*", "attach-type":"direct"} 
 ],
 sriov_info: {
  "nic_type":"fast",
  "network_ids": ["net-id-1", "net-id-2"]  } }

{
 "name":"NIC_slower",
 devices:[
  {"vendor_id":"1137","product_id":"0071", address:"*", "attach-type":"direct"}
  {"vendor_id":"1234","product_id":"0081", address:"*", "attach-type":"direct"} 
 ],
 sriov_info: {
  "nic_type":"fast",
  "network_ids": ["*"]  # this means could attach to any network  } }

The idea being the VIF driver gets passed this info, when network_info includes 
a nic that matches.
Any other details, like VLAN id, would come from neutron, and passed to the VIF 
driver as normal.


3) Reading "nic_type" and doing the PCI passthrough of NIC user requests

Not sure we are agreed on this, but basically:
* network_info contains "nic-type" from neutron
* need to select the correct VIF driver
* need to pass

Re: [openstack-dev] [nova] [neutron] Todays' meeting log: PCI pass-through network support

[Irena Berezovsky]

Please, see inline

From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
Sent: Tuesday, December 24, 2013 1:38 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [neutron] Todays' meeting log: PCI 
pass-through network support

On autodiscovery and configuration, we agree that each compute node finds out 
what it has based on some sort of list of match expressions; we just disagree 
on where they should live.

I know we've talked APIs for setting that matching expression, but I would 
prefer that compute nodes are responsible for their own physical configuration 
- generally this seems wiser on the grounds that configuring new hardware 
correctly is a devops problem and this pushes the problem into the installer, 
clear devops territory.  It also makes the (I think likely) assumption that the 
config may differ per compute node without having to add more complexity to the 
API with host aggregates and so on.  And it means that a compute node can start 
working without consulting the central database or reporting its entire device 
list back to the central controller.
[IrenaB] Totally agree on this.  For both auto-discovery and configuration, we 
need to close the format  and content that is will be available to nova.
My concern here if there is a way to provide auto-discovery based on network 
connectivity (something like what neutron has i.e. 
'physical_interface_mappings')
For configuration, maybe worth to provide some reference flow for managing it 
by installer.
On PCI groups, I think it is a good idea to have them declared centrally (their 
name, not their content).  Now, I would use config to define them and maybe an 
API for the tenant to list their names, personally; that's simpler and easier 
to implement and doesn't preclude adding an (admin) API in the future.  But I 
don't imagine the list of groups will change frequently so any update API would 
be very infrequently used, and if someone really feels they want to implement 
it I'm not going to stop them.

[IrenaB] The issue we need to resolve is nova scheduler taking its decision 
that satisfies network connectivity

On nova boot, I completely agree that we need a new argument to --nic to 
specify the PCI group of the NIC.  The rest of the arguments - I'm wondering if 
we could perhaps do this in two stages:
1. Neutron will read those arguments (attachment type, additional stuff like 
port group where relevant) from the port during an attach and pass relevant 
information to the plugging driver in Nova
[IrenaB] Do you mean via 'neutron port-create before 'nova boot'? Hopefully we 
can close the details during the discussion today.
2. We add a feature to nova so that you can specify other properties in the 
--nic section line and they're passed straight to the port-create called from 
within nova.
[IrenaB] I like this option. This should also allow to request virtio versus 
SR-IOV nic. It should be possible to have  both options available on the same 
Host.
This is not specific to passthrough at all, just a useful general purpose 
feature.  However, it would simplify both the problem and design here, because 
these parameters, whatever they are, are now entirely the responsibility of 
Neutron and Nova's simply transporting them into it.  A PCI aware Neutron will 
presumably understand the attachment type, the port group and so on, or will 
reject them if they're meaningless to it, and we've even got room for future 
expansion without changing Nova or Neutron, just the plugin.  We can propose it 
now and independently, put in a patch and have it ready before we need it.  I 
think anything that helps to clarify and divide the responsibilities of Nova 
and Neutron will be helpful, because then we don't end up with too many 
cross-project-interrelated patches.
[IrenaB] +2
I'm going to ignore the allocation problem for now.  If a single user can 
allocate all the NICs in the cluster to himself, we still have a more useful 
solution than the one now where he can't use them, so it's not the top of our 
list.
[IrenaB] Agree
Time seems to be running out for Icehouse. We need to come to agreement ASAP. I 
will be out from wednesday until after new year. I'm thinking that to move it 
forward after the new year, we may need to have the IRC meeting in a daily 
basis until we reach agreement. This should be one of our new year's 
resolutions?

Whatever gets it done.
[IrenaB] Fine with me. If we reach required decisions today regarding  neutron, 
I can start to dive into the details of SR-IOV mechanism driver assuming ML2 
plugin.

BR,
Irena
--
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 network support

[Irena Berezovsky]

Hi Ian,
My comments are inline
I  would like to suggest to focus the next PCI-pass though IRC meeting on:

1.Closing the administration and tenant that powers the VM use cases.

2.   Decouple the nova and neutron parts to start focusing on the neutron 
related details.

BR,
Irena

From: Ian Wells [mailto:ijw.ubu...@cack.org.uk]
Sent: Friday, December 20, 2013 2:50 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

On 19 December 2013 15:15, John Garbutt 
mailto:j...@johngarbutt.com>> wrote:
> Note, I don't see the person who boots the server ever seeing the pci-flavor, 
> only understanding the server flavor.
> [IrenaB] I am not sure that elaborating PCI device request into server flavor 
> is the right approach for the PCI pass-through network case. vNIC by its 
> nature is something dynamic that can be plugged or unplugged after VM boot. 
> server flavor is  quite static.
I was really just meaning the server flavor specify the type of NIC to attach.

The existing port specs, etc, define how many nics, and you can hot
plug as normal, just the VIF plugger code is told by the server flavor
if it is able to PCI passthrough, and which devices it can pick from.
The idea being combined with the neturon network-id you know what to
plug.

The more I talk about this approach the more I hate it :(

The thinking we had here is that nova would provide a VIF or a physical NIC for 
each attachment.  Precisely what goes on here is a bit up for grabs, but I 
would think:
Nova specifiies the type at port-update, making it obvious to Neutron it's 
getting a virtual interface or a passthrough NIC (and the type of that NIC, 
probably, and likely also the path so that Neutron can distinguish between NICs 
if it needs to know the specific attachment port)
Neutron does its magic on the network if it has any to do, like faffing(*) with 
switches
Neutron selects the VIF/NIC plugging type that Nova should use, and in the case 
that the NIC is a VF and it wants to set an encap, returns that encap back to 
Nova
Nova plugs it in and sets it up (in libvirt, this is generally in the XML; 
XenAPI and others are up for grabs).
[IrenaB] I agree on the described flow. Still need to close how to elaborate 
the request for pass-through vNIC into the  'nova boot'.
> We might also want a "nic-flavor" that tells neutron information it requires, 
> but lets get to that later...
> [IrenaB] nic flavor is definitely something that we need in order to choose 
> if  high performance (PCI pass-through) or virtio (i.e. OVS) nic will be 
> created.
Well, I think its the right way go. Rather than overloading the server
flavor with hints about which PCI devices you could use.

The issue here is that additional attach.  Since for passthrough that isn't 
NICs (like crypto cards) you would almost certainly specify it in the flavor, 
if you did the same for NICs then you would have a preallocated pool of NICs 
from which to draw.  The flavor is also all you need to know for billing, and 
the flavor lets you schedule.  If you have it on the list of NICs, you have to 
work out how many physical NICs you need before you schedule (admittedly not 
hard, but not in keeping) and if you then did a subsequent attach it could fail 
because you have no more NICs on the machine you scheduled to - and at this 
point you're kind of stuck.

Also with the former, if you've run out of NICs, the already-extant resize call 
would allow you to pick a flavor with more NICs and you can then reschedule the 
subsequent VM to wherever resources are available to fulfil the new request.
[IrenaB] Still think that putting PCI NIC request into Server Flavor is not 
right approach. You will need to create different server flavors per any 
possible combination of tenant networks attachment options, or maybe assume he 
is connecting to all. As for billing, you can use type of vNIC in addition to 
packets in/out for billing per vNIC. This way, tenant will be charged only for  
used vNICs.
One question here is whether Neutron should become a provider of billed 
resources (specifically passthrough NICs) in the same way as Cinder is of 
volumes - something we'd not discussed to date; we've largely worked on the 
assumption that NICs are like any other passthrough resource, just one where, 
once it's allocated out, Neutron can work magic with it.
[IrenaB] I am not so familiar with Ceilometer, but seems that if we are talking 
about network resources, neutron should be in charge.

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

[Irena Berezovsky]

Hi John,
I totally agree that we should define the use cases both for administration and 
tenant that powers the VM.
Since we are trying to support PCI pass-through network, let's focus on the 
related use cases.
Please see my comments inline.

Regards,
Irena
-Original Message-
From: John Garbutt [mailto:j...@johngarbutt.com] 
Sent: Thursday, December 19, 2013 1:42 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [nova] [neutron] PCI pass-through network support

Apologies for being late onto this thread, and not making the meeting the other 
day.
Also apologies this is almost totally a top post.

On 17 December 2013 15:09, Ian Wells  wrote:
> Firstly, I disagree that
> https://wiki.openstack.org/wiki/PCI_passthrough_SRIOV_support is an 
> accurate reflection of the current state.  It's a very unilateral 
> view, largely because the rest of us had been focussing on the google 
> document that we've been using for weeks.

I haven't seen the google doc. I got involved through the blueprint review of 
this:
https://blueprints.launchpad.net/nova/+spec/pci-extra-info

I assume its this one?
https://docs.google.com/document/d/1EMwDg9J8zOxzvTnQJ9HwZdiotaVstFWKIuKrPse6JOs

On a quick read, my main concern is separating out the "user" more:
* administration (defines pci-flavor, defines which hosts can provide it, 
defines server flavor...)
* person who boots server (picks server flavor, defines neutron ports)

Note, I don't see the person who boots the server ever seeing the pci-flavor, 
only understanding the server flavor.
[IrenaB] I am not sure that elaborating PCI device request into server flavor 
is the right approach for the PCI pass-through network case. vNIC by its nature 
is something dynamic that can be plugged or unplugged after VM boot. server 
flavor is  quite static.

We might also want a "nic-flavor" that tells neutron information it requires, 
but lets get to that later...
[IrenaB] nic flavor is definitely something that we need in order to choose if  
high performance (PCI pass-through) or virtio (i.e. OVS) nic will be created.

> Secondly, I totally disagree with this approach.  This assumes that 
> description of the (cloud-internal, hardware) details of each compute 
> node is best done with data stored centrally and driven by an API.  I 
> don't agree with either of these points.

Possibly, but I would like to first agree on the use cases and data model we 
want.

Nova has generally gone for APIs over config in recent times.
Mostly so you can do run-time configuration of the system.
But lets just see what makes sense when we have the use cases agreed.

>> On 2013年12月16日 22:27, Robert Li (baoli) wrote:
>> I'd like to give you guy a summary of current state, let's discuss it 
>> then.
>> https://wiki.openstack.org/wiki/PCI_passthrough_SRIOV_support
>>
>>
>> 1)  fade out alias ( i think this ok for all)
>> 2)  white list became pic-flavor ( i think this ok for all)
>> 3)  address simply regular expression support: only * and a number 
>> range is support [hex-hex]. ( i think this ok?)
>> 4)  aggregate : now it's clear enough, and won't impact SRIOV.  ( i 
>> think this irrelevant to SRIOV now)

So... this means we have:

PCI-flavor:
* i.e. standardGPU, standardGPUnew, fastGPU, hdFlash1TB etc

Host mapping:
* decide which hosts you allow a particular flavor to be used
* note, the scheduler still needs to find out if any devices are "free"

flavor (of the server):
* usual RAM, CPU, Storage
* use extra specs to add PCI devices
* example:
** add one PCI device, choice of standardGPU or standardGPUnew
** also add: one hdFlash1TB

Now, the other bit is SRIOV... At a high level:

Neutron:
* user wants to connect to a particular neutron network
* user wants a super-fast SRIOV connection

Administration:
* needs to map PCI device to what neutron network the connect to

The big question is:
* is this a specific SRIOV only (provider) network
* OR... are other non-SRIOV connections also made to that same network

I feel we have to go for that latter. Imagine a network on VLAN 42, you might 
want some SRIOV into that network, and some OVS connecting into the same 
network. The user might have VMs connected using both methods, so wants the 
same IP address ranges and same network id spanning both.
[IrenaB] Agree. SRIOV connection is the choice for certain VM on certain 
network. The same VM can be connected to other network via virtio nic as well 
as other VMs can be connected to the same network via virtio nics.

If we go for that latter new either need:
* some kind of nic-flavor
** boot ... -nic nic-id:"public-id:,nic-flavor:"10GBpassthrough"
** but neutron could store nic-flavor, and pass it through to VIF driver, and 
user says port-id
* OR add NIC config into the server flavor
** extra spec to say, tell VIF driver it could use on of this list of PCI 
devices: (list pci-flavors)
* OR do both

I vote for nic-flavor only, because it matches the volume-t