Re: [openstack-dev] [Neutron] (RE: Change in openstack/neutron-specs[master]: Introducing Tap-as-a-Service)

2015-02-25 Thread Salvatore Orlando
From previous discussion, it appeared the proposer really felt this needed
to be a core neutron aspect.
Where by core they meant both be part of the core API and part of
openstack/neutron.

On the other hand, we also agreed that the best way forward was to develop
a service plugin which in a way contradicts the claim about the necessity
of being part of openstack/neutron.
When it comes to what repo the project should leave in I really think
we're splitting hairs and often talking nonsense. To be a fundamental
component of openstack networking one does not have to be in
openstack/neutron - load balancing docet. At some point I think I lost the
reasons brought up by the proposers for not being able to do this work
outside of openstack/neutron.

Personally, I feel we should collaborate as much as possible, and be open
to take the TAP service as part of openstack/neutron provided that there
are compelling reasons for doing so. I'm afraid however that misperceptions
around the suitability of stackforge/* projects won't be a valid reason (at
least for me), but I'm fairly sure this is not the case of this specific
project.

Salvatore


On 25 February 2015 at 02:32, Kyle Mestery mest...@mestery.com wrote:

 There is a -2 (from me). And this was done from the auto-abandon script
 which I try to run once a month.

 As Kevin said, the suggestion multiple times was to do a StackForge
 project for this work, that's the best way forward here.

 On Tue, Feb 24, 2015 at 5:01 PM, CARVER, PAUL pc2...@att.com wrote:

 Maybe I'm misreading review.o.o, but I don't see the -2. There was a -2
 from Salvatore Orlando with the comment The -2 on this patch is only to
 deter further comments and a link to 140292, but 140292 has a comment from
 Kyle saying it's been abandoned in favor of going back to 96149. Are we in
 a loop here?

 We're moving forward internally with proprietary mechanisms for attaching
 analyzers but it sure would be nice if there were a standard API. Anybody
 who thinks switches don't need SPAN/mirror ports has probably never working
 in Operations on a real production network where SLAs were taken seriously
 and enforced.

 I know there's been a lot of heated discussion around this spec for a
 variety of reasons, but there isn't an enterprise class hardware switch on
 the market that doesn't support SPAN/mirror. Lack of this capability is a
 glaring omission in Neutron that keeps Operations type folks opposed to
 using it because it causes them to lose visibility that they've had for
 ages. We're getting a lot of pressure to continue deploying hardware
 analyzers and/or deploy non-OpenStack mechanisms for implementing
 tap/SPAN/mirror capability when I'd much rather integrate the analyzers
 into OpenStack.


 -Original Message-
 From: Kyle Mestery (Code Review) [mailto:rev...@openstack.org]
 Sent: Tuesday, February 24, 2015 17:37
 To: vinay yadhav
 Cc: CARVER, PAUL; Marios Andreou; Sumit Naiksatam; Anil Rao; Carlos
 Gonçalves; YAMAMOTO Takashi; Ryan Moats; Pino de Candia; Isaku Yamahata;
 Tomoe Sugihara; Stephen Wong; Kanzhe Jiang; Bao Wang; Bob Melander;
 Salvatore Orlando; Armando Migliaccio; Mohammad Banikazemi; mark mcclain;
 Henry Gessau; Adrian Hoban; Hareesh Puthalath; Subrahmanyam Ongole; Fawad
 Khaliq; Baohua Yang; Maruti Kamat; Stefano Maffulli 'reed'; Akihiro Motoki;
 ijw-ubuntu; Stephen Gordon; Rudrajit Tapadar; Alan Kavanagh; Zoltán Lajos
 Kis
 Subject: Change in openstack/neutron-specs[master]: Introducing
 Tap-as-a-Service

 Kyle Mestery has abandoned this change.

 Change subject: Introducing Tap-as-a-Service
 ..


 Abandoned

 This review is  4 weeks without comment and currently blocked by a core
 reviewer with a -2. We are abandoning this for now. Feel free to reactivate
 the review by pressing the restore button and contacting the reviewer with
 the -2 on this review to ensure you address their concerns.

 --
 To view, visit https://review.openstack.org/96149
 To unsubscribe, visit https://review.openstack.org/settings

 Gerrit-MessageType: abandon
 Gerrit-Change-Id: I087d9d2a802ea39c02259f17d2b8c4e2f6d8d714
 Gerrit-PatchSet: 8
 Gerrit-Project: openstack/neutron-specs
 Gerrit-Branch: master
 Gerrit-Owner: vinay yadhav vinay.yad...@ericsson.com
 Gerrit-Reviewer: Adrian Hoban adrian.ho...@intel.com
 Gerrit-Reviewer: Akihiro Motoki amot...@gmail.com
 Gerrit-Reviewer: Alan Kavanagh alan.kavan...@ericsson.com
 Gerrit-Reviewer: Anil Rao arao...@gmail.com
 Gerrit-Reviewer: Armando Migliaccio arma...@gmail.com
 Gerrit-Reviewer: Bao Wang baowan...@yahoo.com
 Gerrit-Reviewer: Baohua Yang bao...@linux.vnet.ibm.com
 Gerrit-Reviewer: Bob Melander bob.melan...@gmail.com
 Gerrit-Reviewer: Carlos Gonçalves m...@cgoncalves.pt
 Gerrit-Reviewer: Fawad Khaliq fa...@plumgrid.com
 Gerrit-Reviewer: Hareesh Puthalath hareesh.puthal...@gmail.com
 Gerrit-Reviewer: Henry Gessau ges...@cisco.com
 Gerrit-Reviewer: Isaku Yamahata 

Re: [openstack-dev] [Neutron] (RE: Change in openstack/neutron-specs[master]: Introducing Tap-as-a-Service)

2015-02-25 Thread Paul Carver

On 2/24/2015 6:47 PM, Kevin Benton wrote:


More seriously, have you considered starting a tap-as-a-service project on
stackforge now that the services split has established a framework for
advanced services? Uploading the code you are using to do it is a great way
to get people motivated to try it, propose new features, critique it, etc.
If you can't upload it because your approach would be proprietary, then
would upstream support even be relevant?



Right now we haven't written any code, but my concern is really more 
about standardizing the API. We're currently weighing two categories of 
options. One is to evaluate a number of open and closed source SDN 
software as plugins to Neutron. I'm not going to list names, but the 
candidates are represented in the plugins and ml2 subdirectories of 
Neutron. Many of these provide tap/mirror functionality, but since 
there's no standard Neutron API they we would be coding to a vendor 
specific API and have to call multiple different APIs to do the same 
thing if we deploy different ones in different locations over time.


The other option that we've considered is to extend a piece of software 
we've written that currently has nothing to do with tap/mirror but does 
perform some OvS flow modifications. If we went with this route we 
certainly would consider open sourcing it, but right now this is the 
less likely plan B.


It actually doesn't matter to me very much whether Neutron implements 
the tap functionality, but I'd really like to see a standard API call 
that the various SDN vendors could get behind. Right now it's possible 
to make Neutron API calls to manipulate networks, ports, and subnets and 
expect that they will function essentially the same way regardless of 
the underlying implementation from a variety of hardware and software 
vendors. But if we want to mirror a vSwitch port to an analyzer we have 
a myriad of vendor specific API calls that are entirely dependent on the 
underlying software and/or hardware beneath Neutron.



__
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] (RE: Change in openstack/neutron-specs[master]: Introducing Tap-as-a-Service)

2015-02-24 Thread Kyle Mestery
There is a -2 (from me). And this was done from the auto-abandon script
which I try to run once a month.

As Kevin said, the suggestion multiple times was to do a StackForge project
for this work, that's the best way forward here.

On Tue, Feb 24, 2015 at 5:01 PM, CARVER, PAUL pc2...@att.com wrote:

 Maybe I'm misreading review.o.o, but I don't see the -2. There was a -2
 from Salvatore Orlando with the comment The -2 on this patch is only to
 deter further comments and a link to 140292, but 140292 has a comment from
 Kyle saying it's been abandoned in favor of going back to 96149. Are we in
 a loop here?

 We're moving forward internally with proprietary mechanisms for attaching
 analyzers but it sure would be nice if there were a standard API. Anybody
 who thinks switches don't need SPAN/mirror ports has probably never working
 in Operations on a real production network where SLAs were taken seriously
 and enforced.

 I know there's been a lot of heated discussion around this spec for a
 variety of reasons, but there isn't an enterprise class hardware switch on
 the market that doesn't support SPAN/mirror. Lack of this capability is a
 glaring omission in Neutron that keeps Operations type folks opposed to
 using it because it causes them to lose visibility that they've had for
 ages. We're getting a lot of pressure to continue deploying hardware
 analyzers and/or deploy non-OpenStack mechanisms for implementing
 tap/SPAN/mirror capability when I'd much rather integrate the analyzers
 into OpenStack.


 -Original Message-
 From: Kyle Mestery (Code Review) [mailto:rev...@openstack.org]
 Sent: Tuesday, February 24, 2015 17:37
 To: vinay yadhav
 Cc: CARVER, PAUL; Marios Andreou; Sumit Naiksatam; Anil Rao; Carlos
 Gonçalves; YAMAMOTO Takashi; Ryan Moats; Pino de Candia; Isaku Yamahata;
 Tomoe Sugihara; Stephen Wong; Kanzhe Jiang; Bao Wang; Bob Melander;
 Salvatore Orlando; Armando Migliaccio; Mohammad Banikazemi; mark mcclain;
 Henry Gessau; Adrian Hoban; Hareesh Puthalath; Subrahmanyam Ongole; Fawad
 Khaliq; Baohua Yang; Maruti Kamat; Stefano Maffulli 'reed'; Akihiro Motoki;
 ijw-ubuntu; Stephen Gordon; Rudrajit Tapadar; Alan Kavanagh; Zoltán Lajos
 Kis
 Subject: Change in openstack/neutron-specs[master]: Introducing
 Tap-as-a-Service

 Kyle Mestery has abandoned this change.

 Change subject: Introducing Tap-as-a-Service
 ..


 Abandoned

 This review is  4 weeks without comment and currently blocked by a core
 reviewer with a -2. We are abandoning this for now. Feel free to reactivate
 the review by pressing the restore button and contacting the reviewer with
 the -2 on this review to ensure you address their concerns.

 --
 To view, visit https://review.openstack.org/96149
 To unsubscribe, visit https://review.openstack.org/settings

 Gerrit-MessageType: abandon
 Gerrit-Change-Id: I087d9d2a802ea39c02259f17d2b8c4e2f6d8d714
 Gerrit-PatchSet: 8
 Gerrit-Project: openstack/neutron-specs
 Gerrit-Branch: master
 Gerrit-Owner: vinay yadhav vinay.yad...@ericsson.com
 Gerrit-Reviewer: Adrian Hoban adrian.ho...@intel.com
 Gerrit-Reviewer: Akihiro Motoki amot...@gmail.com
 Gerrit-Reviewer: Alan Kavanagh alan.kavan...@ericsson.com
 Gerrit-Reviewer: Anil Rao arao...@gmail.com
 Gerrit-Reviewer: Armando Migliaccio arma...@gmail.com
 Gerrit-Reviewer: Bao Wang baowan...@yahoo.com
 Gerrit-Reviewer: Baohua Yang bao...@linux.vnet.ibm.com
 Gerrit-Reviewer: Bob Melander bob.melan...@gmail.com
 Gerrit-Reviewer: Carlos Gonçalves m...@cgoncalves.pt
 Gerrit-Reviewer: Fawad Khaliq fa...@plumgrid.com
 Gerrit-Reviewer: Hareesh Puthalath hareesh.puthal...@gmail.com
 Gerrit-Reviewer: Henry Gessau ges...@cisco.com
 Gerrit-Reviewer: Isaku Yamahata yamahata.rev...@gmail.com
 Gerrit-Reviewer: Jenkins
 Gerrit-Reviewer: Kanzhe Jiang kan...@gmail.com
 Gerrit-Reviewer: Kyle Mestery mest...@mestery.com
 Gerrit-Reviewer: Marios Andreou mar...@redhat.com
 Gerrit-Reviewer: Maruti Kamat maruti.ka...@hp.com
 Gerrit-Reviewer: Mohammad Banikazemi m...@us.ibm.com
 Gerrit-Reviewer: Paul Carver pcar...@att.com
 Gerrit-Reviewer: Pino de Candia gdecan...@midokura.com
 Gerrit-Reviewer: Rudrajit Tapadar rudrajit.tapa...@gmail.com
 Gerrit-Reviewer: Ryan Moats rmo...@us.ibm.com
 Gerrit-Reviewer: Salvatore Orlando salv.orla...@gmail.com
 Gerrit-Reviewer: Stefano Maffulli 'reed' stef...@openstack.org
 Gerrit-Reviewer: Stephen Gordon sgor...@redhat.com
 Gerrit-Reviewer: Stephen Wong stephen.kf.w...@gmail.com
 Gerrit-Reviewer: Subrahmanyam Ongole song...@oneconvergence.com
 Gerrit-Reviewer: Sumit Naiksatam sumitnaiksa...@gmail.com
 Gerrit-Reviewer: Tomoe Sugihara to...@midokura.com
 Gerrit-Reviewer: Welcome, new contributor!
 Gerrit-Reviewer: YAMAMOTO Takashi yamam...@valinux.co.jp
 Gerrit-Reviewer: Zoltán Lajos Kis zoltan.lajos@ericsson.com
 Gerrit-Reviewer: ijw-ubuntu iawe...@cisco.com
 Gerrit-Reviewer: mark mcclain m...@mcclain.xyz
 Gerrit-Reviewer: vinay yadhav 

[openstack-dev] [Neutron] (RE: Change in openstack/neutron-specs[master]: Introducing Tap-as-a-Service)

2015-02-24 Thread CARVER, PAUL
Maybe I'm misreading review.o.o, but I don't see the -2. There was a -2 from 
Salvatore Orlando with the comment The -2 on this patch is only to deter 
further comments and a link to 140292, but 140292 has a comment from Kyle 
saying it's been abandoned in favor of going back to 96149. Are we in a loop 
here?

We're moving forward internally with proprietary mechanisms for attaching 
analyzers but it sure would be nice if there were a standard API. Anybody who 
thinks switches don't need SPAN/mirror ports has probably never working in 
Operations on a real production network where SLAs were taken seriously and 
enforced.

I know there's been a lot of heated discussion around this spec for a variety 
of reasons, but there isn't an enterprise class hardware switch on the market 
that doesn't support SPAN/mirror. Lack of this capability is a glaring omission 
in Neutron that keeps Operations type folks opposed to using it because it 
causes them to lose visibility that they've had for ages. We're getting a lot 
of pressure to continue deploying hardware analyzers and/or deploy 
non-OpenStack mechanisms for implementing tap/SPAN/mirror capability when I'd 
much rather integrate the analyzers into OpenStack.


-Original Message-
From: Kyle Mestery (Code Review) [mailto:rev...@openstack.org] 
Sent: Tuesday, February 24, 2015 17:37
To: vinay yadhav
Cc: CARVER, PAUL; Marios Andreou; Sumit Naiksatam; Anil Rao; Carlos Gonçalves; 
YAMAMOTO Takashi; Ryan Moats; Pino de Candia; Isaku Yamahata; Tomoe Sugihara; 
Stephen Wong; Kanzhe Jiang; Bao Wang; Bob Melander; Salvatore Orlando; Armando 
Migliaccio; Mohammad Banikazemi; mark mcclain; Henry Gessau; Adrian Hoban; 
Hareesh Puthalath; Subrahmanyam Ongole; Fawad Khaliq; Baohua Yang; Maruti 
Kamat; Stefano Maffulli 'reed'; Akihiro Motoki; ijw-ubuntu; Stephen Gordon; 
Rudrajit Tapadar; Alan Kavanagh; Zoltán Lajos Kis
Subject: Change in openstack/neutron-specs[master]: Introducing Tap-as-a-Service

Kyle Mestery has abandoned this change.

Change subject: Introducing Tap-as-a-Service
..


Abandoned

This review is  4 weeks without comment and currently blocked by a core 
reviewer with a -2. We are abandoning this for now. Feel free to reactivate the 
review by pressing the restore button and contacting the reviewer with the -2 
on this review to ensure you address their concerns.

-- 
To view, visit https://review.openstack.org/96149
To unsubscribe, visit https://review.openstack.org/settings

Gerrit-MessageType: abandon
Gerrit-Change-Id: I087d9d2a802ea39c02259f17d2b8c4e2f6d8d714
Gerrit-PatchSet: 8
Gerrit-Project: openstack/neutron-specs
Gerrit-Branch: master
Gerrit-Owner: vinay yadhav vinay.yad...@ericsson.com
Gerrit-Reviewer: Adrian Hoban adrian.ho...@intel.com
Gerrit-Reviewer: Akihiro Motoki amot...@gmail.com
Gerrit-Reviewer: Alan Kavanagh alan.kavan...@ericsson.com
Gerrit-Reviewer: Anil Rao arao...@gmail.com
Gerrit-Reviewer: Armando Migliaccio arma...@gmail.com
Gerrit-Reviewer: Bao Wang baowan...@yahoo.com
Gerrit-Reviewer: Baohua Yang bao...@linux.vnet.ibm.com
Gerrit-Reviewer: Bob Melander bob.melan...@gmail.com
Gerrit-Reviewer: Carlos Gonçalves m...@cgoncalves.pt
Gerrit-Reviewer: Fawad Khaliq fa...@plumgrid.com
Gerrit-Reviewer: Hareesh Puthalath hareesh.puthal...@gmail.com
Gerrit-Reviewer: Henry Gessau ges...@cisco.com
Gerrit-Reviewer: Isaku Yamahata yamahata.rev...@gmail.com
Gerrit-Reviewer: Jenkins
Gerrit-Reviewer: Kanzhe Jiang kan...@gmail.com
Gerrit-Reviewer: Kyle Mestery mest...@mestery.com
Gerrit-Reviewer: Marios Andreou mar...@redhat.com
Gerrit-Reviewer: Maruti Kamat maruti.ka...@hp.com
Gerrit-Reviewer: Mohammad Banikazemi m...@us.ibm.com
Gerrit-Reviewer: Paul Carver pcar...@att.com
Gerrit-Reviewer: Pino de Candia gdecan...@midokura.com
Gerrit-Reviewer: Rudrajit Tapadar rudrajit.tapa...@gmail.com
Gerrit-Reviewer: Ryan Moats rmo...@us.ibm.com
Gerrit-Reviewer: Salvatore Orlando salv.orla...@gmail.com
Gerrit-Reviewer: Stefano Maffulli 'reed' stef...@openstack.org
Gerrit-Reviewer: Stephen Gordon sgor...@redhat.com
Gerrit-Reviewer: Stephen Wong stephen.kf.w...@gmail.com
Gerrit-Reviewer: Subrahmanyam Ongole song...@oneconvergence.com
Gerrit-Reviewer: Sumit Naiksatam sumitnaiksa...@gmail.com
Gerrit-Reviewer: Tomoe Sugihara to...@midokura.com
Gerrit-Reviewer: Welcome, new contributor!
Gerrit-Reviewer: YAMAMOTO Takashi yamam...@valinux.co.jp
Gerrit-Reviewer: Zoltán Lajos Kis zoltan.lajos@ericsson.com
Gerrit-Reviewer: ijw-ubuntu iawe...@cisco.com
Gerrit-Reviewer: mark mcclain m...@mcclain.xyz
Gerrit-Reviewer: vinay yadhav vinay.yad...@ericsson.com
__
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] (RE: Change in openstack/neutron-specs[master]: Introducing Tap-as-a-Service)

2015-02-24 Thread Kevin Benton
I think Kyle's auto-abandon script made a mistake in this case, unless it
was seeing into the future and saw it's own -2... :)

More seriously, have you considered starting a tap-as-a-service project on
stackforge now that the services split has established a framework for
advanced services? Uploading the code you are using to do it is a great way
to get people motivated to try it, propose new features, critique it, etc.
If you can't upload it because your approach would be proprietary, then
would upstream support even be relevant?

On Tue, Feb 24, 2015 at 3:01 PM, CARVER, PAUL pc2...@att.com wrote:

 Maybe I'm misreading review.o.o, but I don't see the -2. There was a -2
 from Salvatore Orlando with the comment The -2 on this patch is only to
 deter further comments and a link to 140292, but 140292 has a comment from
 Kyle saying it's been abandoned in favor of going back to 96149. Are we in
 a loop here?

 We're moving forward internally with proprietary mechanisms for attaching
 analyzers but it sure would be nice if there were a standard API. Anybody
 who thinks switches don't need SPAN/mirror ports has probably never working
 in Operations on a real production network where SLAs were taken seriously
 and enforced.

 I know there's been a lot of heated discussion around this spec for a
 variety of reasons, but there isn't an enterprise class hardware switch on
 the market that doesn't support SPAN/mirror. Lack of this capability is a
 glaring omission in Neutron that keeps Operations type folks opposed to
 using it because it causes them to lose visibility that they've had for
 ages. We're getting a lot of pressure to continue deploying hardware
 analyzers and/or deploy non-OpenStack mechanisms for implementing
 tap/SPAN/mirror capability when I'd much rather integrate the analyzers
 into OpenStack.


 -Original Message-
 From: Kyle Mestery (Code Review) [mailto:rev...@openstack.org]
 Sent: Tuesday, February 24, 2015 17:37
 To: vinay yadhav
 Cc: CARVER, PAUL; Marios Andreou; Sumit Naiksatam; Anil Rao; Carlos
 Gonçalves; YAMAMOTO Takashi; Ryan Moats; Pino de Candia; Isaku Yamahata;
 Tomoe Sugihara; Stephen Wong; Kanzhe Jiang; Bao Wang; Bob Melander;
 Salvatore Orlando; Armando Migliaccio; Mohammad Banikazemi; mark mcclain;
 Henry Gessau; Adrian Hoban; Hareesh Puthalath; Subrahmanyam Ongole; Fawad
 Khaliq; Baohua Yang; Maruti Kamat; Stefano Maffulli 'reed'; Akihiro Motoki;
 ijw-ubuntu; Stephen Gordon; Rudrajit Tapadar; Alan Kavanagh; Zoltán Lajos
 Kis
 Subject: Change in openstack/neutron-specs[master]: Introducing
 Tap-as-a-Service

 Kyle Mestery has abandoned this change.

 Change subject: Introducing Tap-as-a-Service
 ..


 Abandoned

 This review is  4 weeks without comment and currently blocked by a core
 reviewer with a -2. We are abandoning this for now. Feel free to reactivate
 the review by pressing the restore button and contacting the reviewer with
 the -2 on this review to ensure you address their concerns.

 --
 To view, visit https://review.openstack.org/96149
 To unsubscribe, visit https://review.openstack.org/settings

 Gerrit-MessageType: abandon
 Gerrit-Change-Id: I087d9d2a802ea39c02259f17d2b8c4e2f6d8d714
 Gerrit-PatchSet: 8
 Gerrit-Project: openstack/neutron-specs
 Gerrit-Branch: master
 Gerrit-Owner: vinay yadhav vinay.yad...@ericsson.com
 Gerrit-Reviewer: Adrian Hoban adrian.ho...@intel.com
 Gerrit-Reviewer: Akihiro Motoki amot...@gmail.com
 Gerrit-Reviewer: Alan Kavanagh alan.kavan...@ericsson.com
 Gerrit-Reviewer: Anil Rao arao...@gmail.com
 Gerrit-Reviewer: Armando Migliaccio arma...@gmail.com
 Gerrit-Reviewer: Bao Wang baowan...@yahoo.com
 Gerrit-Reviewer: Baohua Yang bao...@linux.vnet.ibm.com
 Gerrit-Reviewer: Bob Melander bob.melan...@gmail.com
 Gerrit-Reviewer: Carlos Gonçalves m...@cgoncalves.pt
 Gerrit-Reviewer: Fawad Khaliq fa...@plumgrid.com
 Gerrit-Reviewer: Hareesh Puthalath hareesh.puthal...@gmail.com
 Gerrit-Reviewer: Henry Gessau ges...@cisco.com
 Gerrit-Reviewer: Isaku Yamahata yamahata.rev...@gmail.com
 Gerrit-Reviewer: Jenkins
 Gerrit-Reviewer: Kanzhe Jiang kan...@gmail.com
 Gerrit-Reviewer: Kyle Mestery mest...@mestery.com
 Gerrit-Reviewer: Marios Andreou mar...@redhat.com
 Gerrit-Reviewer: Maruti Kamat maruti.ka...@hp.com
 Gerrit-Reviewer: Mohammad Banikazemi m...@us.ibm.com
 Gerrit-Reviewer: Paul Carver pcar...@att.com
 Gerrit-Reviewer: Pino de Candia gdecan...@midokura.com
 Gerrit-Reviewer: Rudrajit Tapadar rudrajit.tapa...@gmail.com
 Gerrit-Reviewer: Ryan Moats rmo...@us.ibm.com
 Gerrit-Reviewer: Salvatore Orlando salv.orla...@gmail.com
 Gerrit-Reviewer: Stefano Maffulli 'reed' stef...@openstack.org
 Gerrit-Reviewer: Stephen Gordon sgor...@redhat.com
 Gerrit-Reviewer: Stephen Wong stephen.kf.w...@gmail.com
 Gerrit-Reviewer: Subrahmanyam Ongole song...@oneconvergence.com
 Gerrit-Reviewer: Sumit Naiksatam sumitnaiksa...@gmail.com
 Gerrit-Reviewer: Tomoe Sugihara to...@midokura.com