Re: [openstack-dev] [Neutron] Tungsten Fabric (formally OpenContrail) at Denver PTG

[Sukhdev Kapur]

Folks,

This is a reminder of this event at OpenStack PTG in Denver. If you have
not already RSVP'd please use the link below to do so.
Couple of changes - this event is from 9-5 (not 9-6), and lunch is from
12:30-1:30pm (not 1:00-2:00).

Look forward to seeing you there.

regards
-Sukhdev


On Tue, Aug 28, 2018 at 6:36 PM Sukhdev Kapur 
wrote:

> The Tungsten Fabric community invites you to join us at the OpenStack
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openstack.org_ptg_=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Y9QaEJ2cs4La8kQDqQ-N2rBJnxrPyFqAIO8efLhSqZ0=HGRXthlMxhSQNArAgnxrtePz2KWyiVUqa5MsLQyEL84=2VLCfYnNOglgYtbeQnNpYwuisNoEssd39J-xwSg0Huw=>
>  PTG in Denver
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openstack.org_ptg_=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Y9QaEJ2cs4La8kQDqQ-N2rBJnxrPyFqAIO8efLhSqZ0=HGRXthlMxhSQNArAgnxrtePz2KWyiVUqa5MsLQyEL84=2VLCfYnNOglgYtbeQnNpYwuisNoEssd39J-xwSg0Huw=>
> to discuss and contribute to two great projects: Tungsten
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tungsten.io_=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Y9QaEJ2cs4La8kQDqQ-N2rBJnxrPyFqAIO8efLhSqZ0=HGRXthlMxhSQNArAgnxrtePz2KWyiVUqa5MsLQyEL84=T1RwTJlfkcEoVOeBj_lWqDekZifcOYyOklBqYo0cwxY=>
>  Fabric
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tungsten.io_=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Y9QaEJ2cs4La8kQDqQ-N2rBJnxrPyFqAIO8efLhSqZ0=HGRXthlMxhSQNArAgnxrtePz2KWyiVUqa5MsLQyEL84=T1RwTJlfkcEoVOeBj_lWqDekZifcOYyOklBqYo0cwxY=>
> and Networking-OpenContrail
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_networking-2Dopencontrail=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Y9QaEJ2cs4La8kQDqQ-N2rBJnxrPyFqAIO8efLhSqZ0=HGRXthlMxhSQNArAgnxrtePz2KWyiVUqa5MsLQyEL84=Blz_oe4JgFYJORXh3dy8czBDf6DYhcO9NvXCKGjZBs4=>
> .
>
>
> We’ll be meeting on Tuesday, September 11, in Room Telluride B of Renaissance
> Denver Stapleton Hotel from 9am - 6pm. Here’s the agenda:
>
>
> 9am - 1:00 pm: *Networking-OpenContrail*
>
>Networking-OpenContrail is the OpenStack Neutron ML2 driver to
> integrate Tungsten Fabric to OpenStack. It is designed to eventually
> replace the old monolithic driver.
>
>This session will provide an update on the project, and then we’ll
> discuss the next steps.
>
>
> 1:00-2:00: Lunch
>
>
> 2:00-6:00: *Tungsten **Fabric *
>
> In this session, we’ll start with a brief overview of Tungsten
> Fabric for the benefit of those who may be new to the project.
>
> Then we’ll dive in deeper, discussing the Tungsten Fabric
> architecture, developer workflow, getting patches into Gerrit, and building
> and testing TF for OpenStack and Kubernetes.
>
>
>
> We hope you’ll join us:
>
>
> *Register* for the PTG here
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.eventbrite.com_e_project-2Dteams-2Dgathering-2Ddenver-2D2018-2Dtickets-2D45296703660=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Y9QaEJ2cs4La8kQDqQ-N2rBJnxrPyFqAIO8efLhSqZ0=HGRXthlMxhSQNArAgnxrtePz2KWyiVUqa5MsLQyEL84=eQUrSJ6UODp1OSQdEiXloBqId9JRAj6rdQjtn4yGelY=>,
> and
>
> Please let us know if you’ll attend these sessions: RSVP
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_forms_d_e_1FAIpQLScA-5Fd8m-2Dlrxme49gJJzUXcO6385IGD7690-5FFRQKYsfQnfsJnA_viewform-3Fusp-3Dsf-5Flink=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Y9QaEJ2cs4La8kQDqQ-N2rBJnxrPyFqAIO8efLhSqZ0=HGRXthlMxhSQNArAgnxrtePz2KWyiVUqa5MsLQyEL84=ED015IjOfPhiKlH0QxBCKTRWqO5Zou8mKei8In4cpEo=>
>
>
>
> Sukhdev Kapur and TF Networking Team
>
> IRC - Sukhdev
>
> sukhdevka...@gmail.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

[openstack-dev] [Neutron] Tungsten Fabric (formally OpenContrail) at Denver PTG

[Sukhdev Kapur]

The Tungsten Fabric community invites you to join us at the OpenStack
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openstack.org_ptg_=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Y9QaEJ2cs4La8kQDqQ-N2rBJnxrPyFqAIO8efLhSqZ0=HGRXthlMxhSQNArAgnxrtePz2KWyiVUqa5MsLQyEL84=2VLCfYnNOglgYtbeQnNpYwuisNoEssd39J-xwSg0Huw=>
 PTG in Denver
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openstack.org_ptg_=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Y9QaEJ2cs4La8kQDqQ-N2rBJnxrPyFqAIO8efLhSqZ0=HGRXthlMxhSQNArAgnxrtePz2KWyiVUqa5MsLQyEL84=2VLCfYnNOglgYtbeQnNpYwuisNoEssd39J-xwSg0Huw=>
to discuss and contribute to two great projects: Tungsten
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tungsten.io_=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Y9QaEJ2cs4La8kQDqQ-N2rBJnxrPyFqAIO8efLhSqZ0=HGRXthlMxhSQNArAgnxrtePz2KWyiVUqa5MsLQyEL84=T1RwTJlfkcEoVOeBj_lWqDekZifcOYyOklBqYo0cwxY=>
 Fabric
<https://urldefense.proofpoint.com/v2/url?u=https-3A__tungsten.io_=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Y9QaEJ2cs4La8kQDqQ-N2rBJnxrPyFqAIO8efLhSqZ0=HGRXthlMxhSQNArAgnxrtePz2KWyiVUqa5MsLQyEL84=T1RwTJlfkcEoVOeBj_lWqDekZifcOYyOklBqYo0cwxY=>
and Networking-OpenContrail
<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_networking-2Dopencontrail=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Y9QaEJ2cs4La8kQDqQ-N2rBJnxrPyFqAIO8efLhSqZ0=HGRXthlMxhSQNArAgnxrtePz2KWyiVUqa5MsLQyEL84=Blz_oe4JgFYJORXh3dy8czBDf6DYhcO9NvXCKGjZBs4=>
.


We’ll be meeting on Tuesday, September 11, in Room Telluride B of Renaissance
Denver Stapleton Hotel from 9am - 6pm. Here’s the agenda:


9am - 1:00 pm: *Networking-OpenContrail*

   Networking-OpenContrail is the OpenStack Neutron ML2 driver to
integrate Tungsten Fabric to OpenStack. It is designed to eventually
replace the old monolithic driver.

   This session will provide an update on the project, and then we’ll
discuss the next steps.


1:00-2:00: Lunch


2:00-6:00: *Tungsten **Fabric *

In this session, we’ll start with a brief overview of Tungsten
Fabric for the benefit of those who may be new to the project.

Then we’ll dive in deeper, discussing the Tungsten Fabric
architecture, developer workflow, getting patches into Gerrit, and building
and testing TF for OpenStack and Kubernetes.



We hope you’ll join us:


*Register* for the PTG here
<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.eventbrite.com_e_project-2Dteams-2Dgathering-2Ddenver-2D2018-2Dtickets-2D45296703660=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Y9QaEJ2cs4La8kQDqQ-N2rBJnxrPyFqAIO8efLhSqZ0=HGRXthlMxhSQNArAgnxrtePz2KWyiVUqa5MsLQyEL84=eQUrSJ6UODp1OSQdEiXloBqId9JRAj6rdQjtn4yGelY=>,
and

Please let us know if you’ll attend these sessions: RSVP
<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_forms_d_e_1FAIpQLScA-5Fd8m-2Dlrxme49gJJzUXcO6385IGD7690-5FFRQKYsfQnfsJnA_viewform-3Fusp-3Dsf-5Flink=DwMFaQ=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI=Y9QaEJ2cs4La8kQDqQ-N2rBJnxrPyFqAIO8efLhSqZ0=HGRXthlMxhSQNArAgnxrtePz2KWyiVUqa5MsLQyEL84=ED015IjOfPhiKlH0QxBCKTRWqO5Zou8mKei8In4cpEo=>



Sukhdev Kapur and TF Networking Team

IRC - Sukhdev

sukhdevka...@gmail.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] Stepping down from core

[Sukhdev Kapur]

Hey Armando,

Your leadership will be sorely missed.

Cheers..
-Sukhdev


On Fri, Dec 15, 2017 at 11:01 AM, Armando M.  wrote:

> Hi neutrinos,
>
> To some of you this email may not come as a surprise.
>
> During the past few months my upstream community engagements have been
> more and more sporadic. While I tried hard to stay committed and fulfill my
> core responsibilities I feel like I failed to retain the level of quality
> and consistency that I would have liked ever since I stepped down from
> being the Neutron PTL back at the end of Ocata.
>
> I stated many times when talking to other core developers that being core
> is a duty rather than a privilege, and I personally feel like it's way
> overdue for me to recognize on the mailing list that it's the time that I
> state officially my intention to step down due to other commitments.
>
> This does not mean that I will disappear tomorrow. I'll continue to be on
> neutron IRC channels, support the neutron team, being the release liasion
> for Queens, participate at meetings, and be open to providing feedback to
> anyone who thinks my opinion is still valuable, especially when dealing
> with the neutron quirks for which I might be (git) blamed :)
>
> Cheers,
> Armando
>
>
> __
> 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] Denver Team Dinner

[Sukhdev Kapur]

+1


On Tue, Sep 12, 2017 at 4:23 PM, Miguel Lavalle  wrote:

> Dear Neutrinos,
>
> Our social event will take place on Thursday September 12th at 7:30pm. The
> venue is going to be https://www.famousdaves.com/Denver-Stapleton. It is
> located 0.4 miles from the Renaissance Hotel, which translates to an easy 9
> minutes walk.
>
> I have a reservation for a group of 30 people under my name. Please
> respond to this message with your attendance confirmation by Wednesday
> night, so I can get a more accurate head count.
>
> Looking forward to see y'all Thursday night
>
> Best regards
>
> Miguel
>
> __
> 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] - Summit "Making Neutron easy for people who want basic Networking" summary

[Sukhdev Kapur]

Folks,

I moderated the above referenced session at Boston Summit (sorry for
posting the summary a bit late - because of personal reason).

The etherpad of the session [1] gives you the details of the discussion.
 Based upon the discussions, there were two critical take aways from this
session:

   - IP address allocation (DHCP) for the default/basic configurations. It
   would be desirable, for simpler deployments, to allow a straightforward
   method to specify the IP address for an instance - e.g. one should be able
   to use config drive to config the address and pass it to neutron
   - The documentation for simpler deployments is bit confusing. It is more
   OVS centric and does not provide clear documentation or steps for non-OVS
   deployments. Perhaps update it so that user that are not familiar with
   neutron should be able to deploy instances by answering few simple
   questions in a single config file.  I have filed an RFE [2] to address this.


1. https://etherpad.openstack.org/p/pike-neutron-making-it-easy
2. https://bugs.launchpad.net/neutron/+bug/1694165

regards
-Sukhdev
__
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] - are you attending the Boston summit?

[Sukhdev Kapur]

I will see you guys there... I hope they serve beer/wine :-):-)


On Tue, May 9, 2017 at 1:48 PM, Miguel Lavalle <mig...@mlavalle.com> wrote:

> Dear Neutrinos,
>
> We have a plan for tomorrow night, Wednesday 10th at 7pm. We are going to
> meet at UNO Pizzeria and Grill, 731 Boylston Street Boston, MA 02116, phone
> number (617) 267-8554. This location is a very easy walk of less than 5
> minutes from the convention center
>
> We are going to have an "all you can eat" menu with the following options:
>
> House Salad
> Deep Dish Pizza (cheese, pepperoni, veggie)
> Pasta (penne marinara, chicken broccoli alfredo)
> Fountain Soda drinks and Ice tea are included are at $16.50 per person.
>
> They will present present each person with an individual check for this
> package and charge separately for any other requests
>
> Looking forward to see you all tomorrow night!
>
> Regards
>
> Miguel
>
> On Mon, May 8, 2017 at 5:18 PM, Miguel Lavalle <mig...@mlavalle.com>
> wrote:
>
>> Dear Neutrinos,
>>
>> I am working with Legal Sea Foods on a reservation for 30 people,
>> Wednesday at 7pm. I am assuming the 30 people who registered in the
>> etherpad will attend (https://etherpad.openstack.or
>> g/p/neutron-boston-summit-attendees). If your name is in the etherpad
>> and you DON'T plan to attend, please let me know.
>>
>> Legal Sea Foods has several locations close to the convention center. I
>> will send an update with the slected location as soon as I can finalize the
>> the details with them. Please keep an eye on your inbox
>>
>> Cheers
>>
>> Miguel
>>
>> On Mon, May 8, 2017 at 7:57 AM, Kevin Benton <ke...@benton.pub> wrote:
>>
>>> Let's plan for a social Wednesday night. I'll update this with a
>>> location once we find a place.
>>>
>>> On May 8, 2017 08:50, "MCCASLAND, TREVOR" <tm2...@att.com> wrote:
>>>
>>>> Looking forward to it! RSVP? +1
>>>>
>>>>
>>>>
>>>> *From:* Sukhdev Kapur [mailto:sukhdevka...@gmail.com]
>>>> *Sent:* Saturday, May 06, 2017 12:31 AM
>>>> *To:* OpenStack Development Mailing List (not for usage questions) <
>>>> openstack-dev@lists.openstack.org>
>>>> *Subject:* Re: [openstack-dev] [neutron] - are you attending the
>>>> Boston summit?
>>>>
>>>>
>>>>
>>>> Hey Neutron Folks,
>>>>
>>>>
>>>>
>>>> Following our past tradition, we should have Neutron dinner while we
>>>> are all in Boston.
>>>>
>>>> Miguel has few places in mind. I would propose that we nominate him as
>>>> the dinner organizer lieutenant.
>>>>
>>>>
>>>>
>>>> Miguel, I hope you will take us to some cool place.
>>>>
>>>>
>>>>
>>>> Thanks
>>>>
>>>> -Sukhdev
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Apr 20, 2017 at 4:31 PM, Kevin Benton <ke...@benton.pub> wrote:
>>>>
>>>> Hi,
>>>>
>>>>
>>>>
>>>> If you are a Neutron developer attending the Boston summit, please add
>>>> your name to the etherpad here so we can plan a Neutron social and easily
>>>> coordinate in person meetings: https://etherpad.ope
>>>> nstack.org/p/neutron-boston-summit-attendees
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__etherpad.openstack.org_p_neutron-2Dboston-2Dsummit-2Dattendees=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=afs6hELVfCxZDDqAHhTowQ=5B3JeBxxBxSVSDyEE4CrscFosRJrbSlh0iHA6KKtPp0=aiu832G95vnwmAese4JWyLFwm99d1p4m8LE0iNWjDtc=>
>>>>
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> Kevin Benton
>>>>
>>>>
>>>> 
>>>> __
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: openstack-dev-requ...@lists.op
>>>> enstack.org?subject:unsubscribe
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__OpenStack-2Ddev-2Drequest-40lists.openstack.org-3Fsubject-3Aunsubscribe=DwMFaQ=LFYZ-o9_HUMeMTSQicvjIg=afs6hELVfCxZDDqAHhTowQ=5B3JeBxxBxSVSDyEE4CrscFosRJrbSlh0iHA6KKtPp0=GvGDJtQQuOUlcPAlm42SYXhLvjxuyBONmUgyN3kMKZk=>
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>> <https://urldefense.proofpoint.com/

Re: [openstack-dev] [neutron] - are you attending the Boston summit?

[Sukhdev Kapur]

Hey Neutron Folks,

Following our past tradition, we should have Neutron dinner while we are
all in Boston.
Miguel has few places in mind. I would propose that we nominate him as the
dinner organizer lieutenant.

Miguel, I hope you will take us to some cool place.

Thanks
-Sukhdev


On Thu, Apr 20, 2017 at 4:31 PM, Kevin Benton  wrote:

> Hi,
>
> If you are a Neutron developer attending the Boston summit, please add
> your name to the etherpad here so we can plan a Neutron social and easily
> coordinate in person meetings: https://etherpad.openstack.org/p/neutron-
> boston-summit-attendees
>
> Cheers,
> Kevin Benton
>
> __
> 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] stepping down from core

[Sukhdev Kapur]

Rossella,

It has been nothing but pleasure working with you. Wish you best of luck in
your new endeavors.

regards..
-Sukhdev


On Thu, May 4, 2017 at 6:52 AM, Rossella Sblendido 
wrote:

> Hi all,
>
> I've moved to a new position recently and despite my best intentions I
> was not able to devote to Neutron as much time and energy as I wanted.
> It's time for me to move on and to leave room for new core reviewers.
>
> It's been a great experience working with you all, I learned a lot both
> on the technical and on the human side.
> I won't disappear, you will see me around in IRC, etc, don't hesitate to
> contact me if you have any question or would like my feedback on something.
>
> ciao,
>
> Rossella
>
> __
> 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] [Forum] Moderators needed!

[Sukhdev Kapur]

If no body has claimed it yet, I will be happy to moderate Making Neutron
easy session -
https://www.openstack.org/summit/boston-2017/summit-schedule/events/18800/making-neutron-easy-for-people-who-want-basic-networking


I am already presenter into two sessions. Let me know if you want me to do
this so that I can plan accordingly.

Thanks
-Sukhdev


On Fri, Apr 28, 2017 at 5:22 AM, Shamail Tahir  wrote:

> Hi everyone,
>
> Most of the proposed/accepted Forum sessions currently have moderators but
> there are six sessions that do not have a confirmed moderator yet. Please
> look at the list below and let us know if you would be willing to help
> moderate any of these sessions.
>
> The topics look really interesting but it will be difficult to keep the
> sessions on the schedule if there is not an assigned moderator. We look
> forward to seeing you at the Summit/Forum in Boston soon!
>
> Achieving Resiliency at Scales of 1000+
> 
> Feedback from users for I18n & translation - important part?
> 
> Neutron Pain Points
> 
> Making Neutron easy for people who want basic networking
> 
> High Availability in OpenStack
> 
> Cloud-Native Design/Refactoring across OpenStack
> 
>
>
> Thanks,
> Doug, Emilien, Melvin, Mike, Shamail & Tom
> Forum Scheduling Committee
>
> __
> 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][networking-l2gw] ocata release?

[Sukhdev Kapur]

Gary,

Thank you - you da man...

-Sukhdev


On Sun, Feb 5, 2017 at 11:27 PM, Gary Kotton  wrote:

> Done - https://review.openstack.org/gitweb?p=openstack/networking-
> l2gw.git;a=shortlog;h=refs/heads/stable/ocata
> A luta continua
>
> On 2/6/17, 8:51 AM, "Gary Kotton"  wrote:
>
> Hi,
> Yes, I will go and do this.
> Thanks
> Gary
>
> On 2/6/17, 4:05 AM, "Takashi Yamamoto"  wrote:
>
> hi,
>
> is anyone going to cut ocata release/branch for networking-l2gw?
>
> 
> __
> 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] PTL candidacy

[Sukhdev Kapur]

On Tue, Jan 24, 2017 at 5:04 PM, Kevin Benton <ke...@benton.pub> wrote:

> >I would really like us to discuss this issue head-on and see what is
> missing in Neutron APIs and what would take to make them extensible so that
> vendors do not run around trying to figure out alternative solutions
>
> The Neutron API is already very extensible and that's problematic. Right
> now a vendor can write an out-of-tree service plugin or driver that adds
> arbitrary fields and endpoints to the API that results in whatever behavior
> they want. This is great for vendors because they can directly expose
> features without having to make them vendor agnostic. However, it's
> terrible for operators because it leads to lock-in and terrible for the
> users because it leads to cross-cloud compatibility issues.
>
> For a concrete example of what I mean, take a look at this extension here:
> [1]. This is directly exposing vendor-specific things onto Neutron network
> API payloads. Nobody can build any tooling that depends on those fields
> without being locked into a specific vendor.
>

I do not believe this is a good example. I believe this is for monolithic
plugin (and probably pre-ML2 plugin time frame). If memory serves me right,
there were no specific guidelines at the time. I am sure there are many
other such examples relating to monolithic plugins.
However, I do get your point. Hence, the need to have a good look at the
API so that it can provide way for vendors and operators to expose the
strengths/features of their back-ends in a vendor agnostic fashion.

-Sukhdev



> So what I would like to encourage is bringing API extension work into
> Neutron-lib where we can ensure that the relevant abstractions are in place
> and it's not just a pass-through to a bunch of vendor-specific features. I
> would rather relax our constraint around requiring a reference
> implementation for new extensions in neutron-lib than continue to encourage
> developers to do expose whatever they want with the the existing extension
> framework.
>
> So I'm all for developing new APIs *as a community* to enable NFV use
> cases not supported by the current APIs. However, I don't want to encourage
> or make it easier for vendors to just build arbitrary extensions on top of
> Neutron that expose backend details.
>
> In my view, Neutron should provide a unified API for networking across
> OpenStack clouds, not a platform for writing deployment-specific networking
> APIs.
>
> 1. https://github.com/Juniper/contrail-neutron-plugin/blob/1
> 9ad4bcee4c1ff3bf2d2093e14727866412a694a/neutron_plugin_contr
> ail/extensions/contrail.py#L9-L22
>
> Cheers,
> Kevin Benton
>
> On Tue, Jan 24, 2017 at 3:42 PM, Sukhdev Kapur <sukhdevka...@gmail.com>
> wrote:
>
>>
>> Ihar and Kevin,
>>
>> As our potential future PTLs, I would like to draw your attention to one
>> of the critical issue regarding Neutron as "the" networking service in
>> OpenStack.
>>
>> I keep hearing off and on that Neutron is not flexible to address many
>> networking use cases and hence a new (or additional) networking project is
>> needed. For example, to address the use cases around NFV (rigid resource
>> inter-dependencies).  Another one keeps popping up is that it is very
>> hard/difficult to add/enhance Neutron API - hence, I picked this one goal
>> called out in Ihar's candidacy.
>>
>> I would really like us to discuss this issue head-on and see what is
>> missing in Neutron APIs and what would take to make them extensible so that
>> vendors do not run around trying to figure out alternative solutions
>>
>> cheers..
>> -Sukhdev
>>
>>
>>
>>
>>> * Explore alternative ways to evolve Neutron API.  Piling up
>>> extensions and allowing third parties to completely change core
>>> resource behaviour is not ideal, and now that api-ref and API
>>> consolidation effort in neutron-lib are closer to completion, we may
>>> have better answers to outstanding questions than during previous
>>> attempts to crack the nut. I would like to restart the discussion some
>>> time during Pike.
>>>
>>
>>
>>
>>
>>>
>>> Thanks for attention,
>>> Ihar
>>>
>>> 
>>> __
>>> 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
>>>
>>
>>
>> _

Re: [openstack-dev] [neutron] PTL candidacy

[Sukhdev Kapur]

Folks,

This thread has gotten too long and hard to follow.
It is clear that we should discuss/address this.
My suggestion is that we organize a session in Atlanta PTG meeting and
discuss this.

I am going to add this on the Neutron etherpad - should this be included in
any other session as well?

-Sukhdev




On Tue, Jan 24, 2017 at 12:33 AM, Ihar Hrachyshka 
wrote:

> Hi team,
>
> I would like to propose my PTL candidacy for Pike.
>
> Some of you already know me. If not, here is my brief OpenStack bio. I
> joined the community back in Havana, and managed to stick around till
> now. During the time, I fit several project roles like serving as a
> Neutron liaison of different kinds (stable, oslo, release), fulfilling
> my Neutron core reviewer duties, taking part in delivering some
> longstanding features, leading QoS and upgrades subteams, as well as
> being part of Neutron Drivers team. I also took part in miscellaneous
> cross project efforts.
>
> I think my experience gives me broad perspective on how the OpenStack
> community and more specifically Networking works, and what is expected
> from its PTL.
>
> First, let me describe my vision of PTL role.
>
> * It's not only about technical intricacies. It's also about people
> and procedures that make the project run smoothly day by day. The role
> of PTL is in empowering other team members, keeping track of any
> roadblocks and inconveniences that the team have, and working on
> streamlining workflow.
>
> * It's about delegation. We should make it a habit to look at the list
> of potential candidates for core membership and other leadership and
> administrative positions not just in times we are short on existing
> members.
>
> * PTL should be transparent and replaceable. I will work with outgoing
> PTL to capture oral wisdom and state of affairs into a publicly
> accessible project dashboard, and I will continue sharing such
> information with the team on constant basis. The project dashboard
> will give you answers to questions like: what's the project direction?
> what are current priorities, and where does each stand?  what's on PTL
> and Drivers' mind? which cross-project and governance initiatives are
> currently worked on? etc.
>
> As PTL, I'd like to focus on the following things:
>
> * Speed up the RFE/spec process. We should manage RFE/spec review
> pipeline in such a way so that initiatives that are given a green
> light on writing up design details get timely feedback and can get
> past spec process in reasonable time.  At the same time we should be
> honest to the community not to accept proposals that have high risk to
> fall through cracks due to lack of manpower. I will encourage usage of
> reviewday and other tools to keep focus of the team. We will mull over
> the idea of virtual code sprints for high demand topics.
>
> * Continue Stadium program without drastic changes of direction.
> Thanks to Armando, we filled the Stadium with tangible meaning. I want
> us to build on top of that foundation to drive consistency and high
> quality standards between participating projects.
>
> * Support Marketplace rework. With huge number of drivers and plugins
> available for Neutron, it became hard for operators to pick the right
> one and for vendors to advertise their features. There is strong
> vendor interest to improve situation there. We should boost Feature
> Classification work, and integrate it with how third party CI systems
> report test results so that they become useful for Marketplace.
>
> * Introduce Gate Keeper role. We've recently made significant progress
> in how we deal with gate: we expanded coverage to new types of jobs,
> we utilize Grafana and other community tools, we review gate-failure
> tagged bugs during weekly meetings. Sadly, sometimes gate becomes
> unstable, and it slows down work progress for everyone.  In such
> cases, it's all about timely addressing the issue. For that matter, I
> will work with the team on defining a new Gate Keeper role that would
> help prioritizing current gate issues, as well as proactively work
> with the team on gate instability vectors. I believe clear ownership
> is the key.
>
> * Make centralized L3 legacy indeed. We have DVR and HA in tree for
> quite some time. Both technologies are now mature enough, and are no
> longer mutually exclusive. Sadly, they are still second class citizens
> in our own gate.  My belief is we should give users a clear signal
> that old L3 is indeed legacy by switching our jobs to DVR+HA where
> applicable.  I am sure that will surface some previously unknown
> issues, but we'll be ready to tackle them.  While it's never black or
> white, I suggest we prioritize this work over adding new major L3
> features.
>
> * Support existing maintenance initiatives. I'd like us to close
> neutron-lib saga in Pike, and consider neutron-lib switch for a
> requirement to all Stadium projects starting from Queens. We should
> also close OSC transition 

Re: [openstack-dev] [neutron] PTL candidacy

[Sukhdev Kapur]

Folks, this is a great discussion. I hope this leads us to some good
consensus and direction :-)
I would suggest that we discuss this in upcoming PTG meeting as well.


On Wed, Jan 25, 2017 at 5:20 AM, Kevin Benton  wrote:

> >So I'm not sure that Kevin and Thierry's answers address Sukhdev's point.
>
> I stated that I am happy to develop new APIs in Neutron. "So I'm all for
> developing new APIs *as a community*"...
>

+1


>
> The important distinction I am making is that we can make new APIs (and we
> do with routed networks as you mentioned, VLAN aware VMs, etc), but I don't
> want to see the project just become a framework to make it even easier than
> it is to define an arbitrary networking API.
>

There is no such thing as arbitrary API. It is like one person's treasure
is other person's trash no body loves to create arbitrary APIs - there
are genuine needs. Some times we fail to understand requirements, other
times the requirements are not articulated clearly, which could lead to
impressions that arbitrary things are being added.



> >But I think that the point that Sukhdev raised - about other networking
> projects being suggested because of Neutron being perceived as not flexible
> enough
>
> I'm explicitly stating that if someone wants Neutron to become more
> flexible to develop arbitrary APIs that diverge across deployments even
> more, that's not something I'm going to support. However, making it
> flexible for operators/users by adding new vendor-agnostic APIs is
> something I will encourage.
>

> The reason I am stressing that distinction is because we have vendors that
> want something like Gluon that allows them to define new arbitrary APIs
> without upstreaming anything or working with the community to standardize
> anything.
>
I understand that may be useful for some artisanal NFV workloads, but
> that's not the direction I want to take Neutron.
>

OpenStack community consists of vendors and operators/users to facilitate
and adoption of newer technologies as they evolve. As newer
workloads/technologies evolve, the need to orchestrate them requires
flexibility in the API. Labeling them as an arbitrary API  just because
they do not fall into traditional L2/L3 networking model) is a harsh
characterization.



> Flexibility for operators/users = GOOD
> Flexibility for vendor API injection = BAD
>

As I read/understand more about Gluon, that is being pushed by both
Operators/Users and Vendors. I wonder which one is GOOD and which one is
BAD :-):-)

cheers..
-Sukhdev




>
> On Wed, Jan 25, 2017 at 4:55 AM, Neil Jerram  wrote:
>
>> On Wed, Jan 25, 2017 at 10:20 AM Thierry Carrez 
>> wrote:
>>
>>> Kevin Benton wrote:
>>> > [...]
>>> > The Neutron API is already very extensible and that's problematic.
>>> Right
>>> > now a vendor can write an out-of-tree service plugin or driver that
>>> adds
>>> > arbitrary fields and endpoints to the API that results in whatever
>>> > behavior they want. This is great for vendors because they can directly
>>> > expose features without having to make them vendor agnostic. However,
>>> > it's terrible for operators because it leads to lock-in and terrible
>>> for
>>> > the users because it leads to cross-cloud compatibility issues.
>>>
>>> +1000 on this being a major problem in Neutron. Happy to see that you
>>> want to work on trying to reduce it.
>>
>>
>> The Neutron API is a model of what forms of connectivity can be
>> expressed, between instances and the outside world.  Once that model is
>> chosen, it is inevitably (and simultaneously):
>>
>> (a) overconstraining - in other words, there will be forms of
>> connectivity that someone could reasonably want, but that are not allowed
>> by the model
>>
>> (b) underconstraining - in other words, there will be nuances of
>> behaviour, delivered by a particular implementation, that are arguably
>> within what the model allows, but (as we're talking about semantics) it
>> would really be better to revise the API so that it can explicitly express
>> those nuances.
>>
>> Sometimes - since the semantics of the Neutron API are not precisely
>> documented - it's not clear which of these situations one is in.  But I
>> think that the point that Sukhdev raised - about other networking projects
>> being suggested because of Neutron being perceived as not flexible enough -
>> is to do with (a); whereas the points that Kevin and Thierry responded with
>> - ways that the API is already _too_ flexible - are to do with (b).  So I'm
>> not sure that Kevin and Thierry's answers address Sukhdev's point.
>>
>> It's possible for an API to have (a) and (b) problems simultaneously, and
>> to make progress on addressing them both.  In Neutron's case, a major
>> example of (a) has been the routed networks work, which (among other
>> things) generalized Neutron's network concept from being something that
>> always provides L2 adjacency between its ports, to something that 

Re: [openstack-dev] [Neutron] PTL Candidacy

[Sukhdev Kapur]

On Tue, Jan 24, 2017 at 3:24 PM, Edgar Magana <edgar.mag...@workday.com>
wrote:

> You just made me remember my time as police man for Neutron plugins!  ☺
>

Now we can have distributed police men :-)

-Sukhdev



>
>
> Edgar
>
>
>
> *From: *Sukhdev Kapur <sukhdevka...@gmail.com>
> *Reply-To: *"OpenStack Development Mailing List (not for usage
> questions)" <openstack-dev@lists.openstack.org>
> *Date: *Tuesday, January 24, 2017 at 3:14 PM
> *To: *"OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [Neutron] PTL Candidacy
>
>
>
> I remember good old days when CI was introduced in Neutron (during
> Icehouse time frame). There was excellent momentum behind it. We did not
> know some of the enforcement details, which created lots of
> confusion/havoc.
>
>
>
> Now that we have a better understanding of the past issues, and lots of
> good ideas to address them, I think it is appropriate to reactivate the
> process.
>
> As to Jeremy's options, I think option B makes the best sense - the driver
> author/owner should bare the burden of declaring a driver/plugin compatible.
>
>
>
> cheers..
>
> -Sukhdev
>
>
>
>
>
> On Tue, Jan 24, 2017 at 12:46 PM, Jeremy Stanley <fu...@yuggoth.org>
> wrote:
>
> On 2017-01-24 10:51:39 -0800 (-0800), Ihar Hrachyshka wrote:
> > On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton <ke...@benton.pub> wrote:
> > > I'm on board with getting visibility into the drivers with
> improvements to
> > > driverlog, etc. What I'm uncertain of is providing much in the lines of
> > > 'validation'. Core reviewers don't frequently have access to the
> hardware or
> > > software required to validate these drivers so we can't be sure if the
> > > features really are working as expected.
> > >
> > > If validation is as flexible as you highlighted in the email, we can at
> > > least get it to a point where all recent CI runs are linkable from
> driverlog
> > > and people can see recent tempest runs. I don't foresee the Neutron
> team
> > > getting to a point soon where we vouch for certain drivers though just
> > > because it is so hard to keep up with their changes (even ignoring
> changes
> > > in the vendor hardware itself).
> >
> > Good point. We may guide plugins and drivers on how to set up CI; we
> > may help Foundation to set up Marketplace in such a way that would
> > allow to automatically consume test artifacts from driver owners; we
> > may provide guidance to Foundation about which features are more
> > important to reflect that in Marketplace; but I would hope we don't
> > put the Neutron team on the hook to validate each driver, or even
> > police CI owners to produce consumable results. (The stick in the
> > latter case would be driver not showing up in Marketplace, or showing
> > up with no feature support information.)
>
> I guess the question I have is who, then, can tell our
> operators/users what Neutron drivers are reasonably supported? It
> sounds like you're saying Neutron developers are not well-placed to
> determine that, which leaves us with these other options:
>
> A. Have the OpenStack Foundation as maintainers of the Marketplace
>decide which Neutron drivers are usable (they don't really staff
>for this purpose so would be throwing darts I think)
>
> B. Trust the driver authors to declare whether they're supported and
>what features they provide (maybe that works better than I
>expect?)
>
> C. Identify another party with a vested interest in validating
>driver support (a board of operators from different organizations
>maybe?)
>
> D. Provide links/aggregation of QA/CI and let the consumers attempt
>to divine supportability for themselves (seems a bit downstream
>hostile)
>
> Are any of those options preferable?
> --
> Jeremy Stanley
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__OpenStack-2Ddev-2Drequest-40lists.openstack.org-3Fsubject-3Aunsubscribe=DwMFaQ=DS6PUFBBr_KiLo7Sjt3ljp5jaW5k2i9ijVXllEdOozc=G0XRJfDQsuBvqa_wpWyDAUlSpeMV4W1qfWqBfctlWwQ=stAqZEa1UaR75JvzJ0FZBG0scAKmZwHhoC7exuAKsUc=J3l_htX2j4f1reTu2w6i8YUD4Q_0YgpguIiCHlJB0PE=>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.op

Re: [openstack-dev] [Neutron] PTL Candidacy

[Sukhdev Kapur]

I remember good old days when CI was introduced in Neutron (during Icehouse
time frame). There was excellent momentum behind it. We did not know some
of the enforcement details, which created lots of confusion/havoc.

Now that we have a better understanding of the past issues, and lots of
good ideas to address them, I think it is appropriate to reactivate the
process.
As to Jeremy's options, I think option B makes the best sense - the driver
author/owner should bare the burden of declaring a driver/plugin compatible.

cheers..
-Sukhdev


On Tue, Jan 24, 2017 at 12:46 PM, Jeremy Stanley  wrote:

> On 2017-01-24 10:51:39 -0800 (-0800), Ihar Hrachyshka wrote:
> > On Tue, Jan 24, 2017 at 12:50 AM, Kevin Benton  wrote:
> > > I'm on board with getting visibility into the drivers with
> improvements to
> > > driverlog, etc. What I'm uncertain of is providing much in the lines of
> > > 'validation'. Core reviewers don't frequently have access to the
> hardware or
> > > software required to validate these drivers so we can't be sure if the
> > > features really are working as expected.
> > >
> > > If validation is as flexible as you highlighted in the email, we can at
> > > least get it to a point where all recent CI runs are linkable from
> driverlog
> > > and people can see recent tempest runs. I don't foresee the Neutron
> team
> > > getting to a point soon where we vouch for certain drivers though just
> > > because it is so hard to keep up with their changes (even ignoring
> changes
> > > in the vendor hardware itself).
> >
> > Good point. We may guide plugins and drivers on how to set up CI; we
> > may help Foundation to set up Marketplace in such a way that would
> > allow to automatically consume test artifacts from driver owners; we
> > may provide guidance to Foundation about which features are more
> > important to reflect that in Marketplace; but I would hope we don't
> > put the Neutron team on the hook to validate each driver, or even
> > police CI owners to produce consumable results. (The stick in the
> > latter case would be driver not showing up in Marketplace, or showing
> > up with no feature support information.)
>
> I guess the question I have is who, then, can tell our
> operators/users what Neutron drivers are reasonably supported? It
> sounds like you're saying Neutron developers are not well-placed to
> determine that, which leaves us with these other options:
>
> A. Have the OpenStack Foundation as maintainers of the Marketplace
>decide which Neutron drivers are usable (they don't really staff
>for this purpose so would be throwing darts I think)
>
> B. Trust the driver authors to declare whether they're supported and
>what features they provide (maybe that works better than I
>expect?)
>
> C. Identify another party with a vested interest in validating
>driver support (a board of operators from different organizations
>maybe?)
>
> D. Provide links/aggregation of QA/CI and let the consumers attempt
>to divine supportability for themselves (seems a bit downstream
>hostile)
>
> Are any of those options preferable?
> --
> Jeremy Stanley
>
> __
> 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] PTL candidacy

[Sukhdev Kapur]

Ihar and Kevin,

As our potential future PTLs, I would like to draw your attention to one of
the critical issue regarding Neutron as "the" networking service in
OpenStack.

I keep hearing off and on that Neutron is not flexible to address many
networking use cases and hence a new (or additional) networking project is
needed. For example, to address the use cases around NFV (rigid resource
inter-dependencies).  Another one keeps popping up is that it is very
hard/difficult to add/enhance Neutron API - hence, I picked this one goal
called out in Ihar's candidacy.

I would really like us to discuss this issue head-on and see what is
missing in Neutron APIs and what would take to make them extensible so that
vendors do not run around trying to figure out alternative solutions

cheers..
-Sukhdev




> * Explore alternative ways to evolve Neutron API.  Piling up
> extensions and allowing third parties to completely change core
> resource behaviour is not ideal, and now that api-ref and API
> consolidation effort in neutron-lib are closer to completion, we may
> have better answers to outstanding questions than during previous
> attempts to crack the nut. I would like to restart the discussion some
> time during Pike.
>




>
> Thanks for attention,
> Ihar
>
> __
> 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] PTL Candidacy

[Sukhdev Kapur]

In deed, excellent and well qualified candidates.

Best of Luck to both

-Sukhdev


On Tue, Jan 24, 2017 at 7:16 AM, Armando M.  wrote:

> Hi neutrinos,
>
> No, it's not what you might be thinking...I am just delighted to see two
> excellent candidates willing to take the reins of the project going forward
> [1,2].
>
> I couldn't hope for more enthusiasm; best of luck to both candidates and
> anyone else who is going to step up! This is exciting!
>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/423552/
> [2] https://review.openstack.org/#/c/424500/
>
> __
> 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] PTL nominations deadline and non-candidacy

[Sukhdev Kapur]

Hey Armando,

Too bad we can't pick on you anymore :-)

On a serious note, thanks for the leadership you brought to the Neutron
team and the project. Your contributions will always be appreciated.

Look forward to continue to work with you.

regards..
-Sukhdev


On Mon, Jan 9, 2017 at 6:11 AM, Armando M.  wrote:

> Hi neutrinos,
>
> The PTL nomination week is fast approaching [0], and as you might have
> guessed by the subject of this email, I am not planning to run for Pike. If
> I look back at [1], I would like to think that I was able to exercise the
> influence on the goals I set out with my first self-nomination [2].
>
> That said, when it comes to a dynamic project like neutron one can't never
> claim to be *done done* and for this reason, I will continue to be part of
> the neutron core team, and help the future PTL drive the next stage of the
> project's journey.
>
> I must admit, I don't write this email lightly, however I feel that it is
> now the right moment for me to step down, and give someone else the
> opportunity to grow in the amazing role of neutron PTL! I have certainly
> loved every minute of it!
>
> Cheers,
> Armando
>
> [0] https://releases.openstack.org/ocata/schedule.html
> [1] https://review.openstack.org/#/q/project:openstack/elect
> ion+owner:armando-migliaccio
> [2] https://review.openstack.org/#/c/223764/
>
> __
> 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][ml2] Mechanism drivers ! OpenvSwich or Linuxbridge or both of them?

[Sukhdev Kapur]

Zhi,

Selection of driver is deployment dependent. You could run or more ML2
drivers simultaneous depending upon your deployment.

Hierarchical Port Binding (HPB) facilitates multi-segmented L2 networks
where the scope of the Segmentation ID is local to a given segment.
For example - if you want to inter-connect two VLAN based network segments
with an overlay network of VXLAN, you would use HPB. With HPB, each VLAN
segment could use the same or different VLAN ID. Therefore, HPB facilitates
the deployments with greater than 4K VLANs.
Without HPB, L2 networks in Neutron are limited to 4K VLANS.

As to the binding information, it is bit tricky in case of HPB. There is no
generic CLI in neutron which lists the binding information. However, this
information is available in the driver. Drivers bind the ports dynamically
(segment by segment)
You can refer to Cisco or Arista ML2 drivers to see how this information is
used/retrieved.

regards..
-Sukhdev


On Fri, Dec 30, 2016 at 5:49 AM, zhi  wrote:

> Hi, all
>
> First of all. Happy New year for everyone!
>
> I have a question about mechanism drivers when using ML2 driver.
>
> When should I use openvswitch mechanism driver ?
>
> When should I use linuxbridge mechanism driver ?
>
> And, when should I use openvswitch and linuxbridge mechanism drivers ?
>
> In my opinion, ML2 driver has supported hierarchical port binding. By
> using hierarchical port binding,
> neutron will know every binding info in network topology, isn't it? If
> yes, where I can found the every binding info. And what the relationship
> between hierarchical port binding and mechanism drivers?
>
>
> Hope for your reply.
>
> Thanks
> Zhi Chang
>
> __
> 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][Ironic] Ironic-Neutron Integration meeting termination notification

[Sukhdev Kapur]

Folks,

As you know we started out the charter to bring multi-tenancy for Bare
metal Service (Ironic) using Neutron networking in Liberty Cycle. We have
been meeting weekly to discuss this Ironic/ Neutron integration and make it
a reality.

 We successfully completed the charter - thanks to everybody who
participated and contributed to make it a reality.
The charter that we  laid out initially as specified in [1] has been
accomplished. We have few pieces which are in the final stages of
completion and will be completed (hopefully) in Ocata cycle.

Our weekly meetings have become more or less status meetings. Therefore, we
have decided to to discontinue our meetings and instead roll out the
sub-team status into Ironic weekly meeting.
Starting 2017, we will cancel our weekly meetings. We will roll up the
status of this sub-team into the Ironic meetings.

If anybody feels that there is a need to keep this meeting separately, feel
free to express your opinion. In the absence of any objection, I will
proceed with the plan. I will push a patch to relinquish the time slot so
that other OpenStack projects can avail that time slot.

Thanks and HAPPY NEW YEAR

regards..
-Sukhdev

[1] -
https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#Tracking_Ironic.2FNeutron_integration_Discussions
__
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] Neutron team social event in Barcelona

[Sukhdev Kapur]

+1

Count me in...

-Sukhdev


On Fri, Oct 14, 2016 at 11:30 AM, Miguel Lavalle 
wrote:

> Dear Neutrinos,
>
> I am organizing a social event for the team on Thursday 27th at 19:30.
> After doing some Google research, I am proposing Raco de la Vila, which is
> located in Poblenou: http://www.racodelavila.com/en/index.htm. The menu
> is here: http://www.racodelavila.com/en/carta-racodelavila.htm
>
> It is easy to get there by subway from the Summit venue:
> https://goo.gl/maps/HjaTEcBbDUR2. I made a reservation for 25 people
> under 'Neutron' or "Miguel Lavalle". Please confirm your attendance so we
> can get a final count.
>
> Here's some reviews: https://www.tripadvisor.com/
> Restaurant_Review-g187497-d1682057-Reviews-Raco_De_La_
> Vila-Barcelona_Catalonia.html
>
> Cheers
>
> Miguel
>
> __
> 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][L2GW] New core member

[Sukhdev Kapur]

Folks,

I am pleased to announce the addition of  Ofer Ben-Yakov as new core team
member of L2 Gateway team.

Ofer has been working hard and contributing to solidify L2GW framework as
well adding new features to the L2GW.

The team welcomes Ofer on board and look forward to work with him.

Thanks and regards...
-Sukhdev
__
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] [ironic] why do we need setting network driver per node?

[Sukhdev Kapur]

Hi Devananda,

This is a good summary. I think the proposal makes a lot of sense.

We need to agree to this as soon as possible so that we can get the Ironic
patches merged by this Friday - to meet the timelines.

Can you set up the number for the voice call so that we can all dial in,
discuss, if further discussion is needed, and get this closed off.
Ideally, we can work to approve/modify the patches while we are all on the
call.

thoughts?

-Sukhdev


On Mon, Jul 11, 2016 at 3:03 PM, Sam Betts (sambetts) 
wrote:

> Thanks for following up with this Devananda, I¹ve left a couple of
> corrections to my proposal inline, unfortunately IRC isn¹t the best for
> putting ideas this complex across :)
>
> Sam
>
> On 11/07/2016 21:57, "Devananda van der Veen" 
> wrote:
>
> >We spent the majority of today's weekly IRC meeting [1] discussing the
> >finer
> >points of this question. I agreed to post a summary of those to the list
> >(it's
> >below the break).
> >
> >tldr;
> >
> >* we don't know if network_interface should behave like other hardware
> >interfaces, but...
> >* we need to come to an agreement on it this week, so we can proceed with
> >the
> >network integration work.
> >
> >
> >Background:
> >
> >- As proposed in the driver composition reform spec [2], each
> >hardware_type
> >class (eg, ilo_gen8) shall specify a set of allowable interface
> >implementations
> >(eg, noop, flat, neutron are all network_interfaces) for each interface
> >type
> >(eg, deploy_interface, power_interface, network_interface).
> >- A hardware_type shall also indicate a default for each interface_type.
> >(**
> >this is what we debated ** )
> >- There is no CONF option to specify a global default for each
> >interface_type
> >(eg, there is no CONF.default_power_interface setting, because it varies
> >by
> >hardware_type)
> >- There will be a CONF option to enable ("allow") hardware classes and
> >CONF
> >options to enable ("allow") interface classes.
> >
> >
> >Points raised in the meeting today:
> >
> >- in "most" cases, network_interface will depend more on the environment
> >than a
> >specific Node's hardware or out-of-band management device
> >
> >- in "exceptional" cases, a Node may only support specific
> >network_interfaces
> >(eg, certain Cisco hardware, a Blade enclosure)
> >
> >- maybe hardware_type should specify a default for some interfaces but not
> >others? Example:
> >  - the ilo_gen8 hardware class should specify power, deploy, and
> >management
> >interface defaults to ilo-specific interface classes
> >  - but the operator should set the network interface as appropriate to
> >their
> >environment
> >
> >- if we were to force the operator to specify Node.network_interface (but
> >not
> >any other interface) when enrolling every node, this will be apoor
> >experience.
> >
> >- we should add a global CONF setting to allow operators to set a default
> >network interface for their environment.
> >
> >- words are hard. we shouldn't call network_interface an "interface" if it
> >behaves differently than other interfaces.
> >
> >- we have two "types" of interfaces on drivers: hardware-types and
> >environment-types. maybe we should treat them differently?
> >
> >- other things also depend on the environment (rather than the Node's
> >hardware
> >or BMC) such as deploy_interface and volume_interface.
> >
> >
> >There was a proposal from sambetts towards the end of the meeting, which
> >I've
> >edited for clarity (please correct if I misunderstood any of your
> >points). This
> >seems to capture/address most of the points above and proposes a way
> >forward,
> >while keeping within the intent of our driver composition reform spec. It
> >was
> >the only clear suggestion during the meeting.
> >
> >- in-tree hardware_types declare supported_network_interfaces to be empty
> >[4]
> >and declare no default_network_interface
>
> Your suggestion in [4] is what I meant, but I couldn¹t type fast enough in
> the meeting. In-tree hardware_types will list support for
> network_interfaces according to their vendor¹s preference (I expect for
> most/all drivers that will at least be [noop, flat, neutron]). And if in
> the future as a vendor I want to, for example, push my hardware specific
> network interface in tree, then my Cisco drivers will gain an additional
> network_interface in their supported_network_interfaces list, [noop, flat,
> neutron, cisco].
>
> >- we add a CONF option for default_network_interface, with a sane default
> >value
> >- this CONF option is validated on conductor load to be supported by all
> >loaded
> >hardware_types, and the conductor refuses to start if this CONF option is
> >set to
> >a value not supported by one or more enabled_hardware_types
> >- if a(n out of tree) hardware_type declares a default_network_interface,
> >this
> >will take precedence over the CONF option
>
> I believe that all hardware_types should specify their supported network
> interfaces, 

[openstack-dev] [Neutron][L2 Gateway] No meeting on July 4th

[Sukhdev Kapur]

Folks,

Due the US holiday on 4th of July, there will be no meeting for L2 Gateway.

The channel will be available for anybody to use, should you need to
discuss anything during the meeting's time slot.

Happy 4th..

-Sukhdev
__
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] [Ironic][Neutron] No Ironic-Neutron Integration meeting on July 4th

[Sukhdev Kapur]

Folks,

Due the US holiday on 4th of July, there will be no meeting on
Ironic-Neutron Integration.

The channel will be available for anybody to use, should you need to
discuss anything during the meeting's time slot.

Happy 4th..

-Sukhdev
__
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][L2GW] Mitaka release of L2 Gateway now available

[Sukhdev Kapur]

Hi Martinx,

L2GW is designed to bridge neutron networks with non-neutron networks to
form a L2 broadcast domain - not two neutron networks.

regards..

-Sukhdev


On Mon, May 16, 2016 at 8:58 PM, Martinx - ジェームズ <thiagocmarti...@gmail.com>
wrote:

>
>
> On 11 May 2016 at 16:05, Sukhdev Kapur <sukhdevka...@gmail.com> wrote:
>
>>
>> Folks,
>>
>> I am happy to announce that Mitaka release for L2 Gateway is released and
>> now available at https://pypi.python.org/pypi/networking-l2gw.
>>
>> You can install it by using "pip install networking-l2gw"
>>
>> This release has several enhancements and fixes for issues discovered in
>> liberty release.
>>
>> Thanks
>> Sukhdev Kapur
>>
>>
> Sounds very interesting!
>
> Currently, I have a DPDK App that is a L2 Bridge, however, when I bridge
> two Neutron Networks together (under the same L2 broadcast domain),
> OpenStack itself is "not aware" of this!
>
> Basically, OpenStack doesn't "knows" that a "regular Instance" is a L2
> Bridge, which make things very weird for NFV applications like mine.
>
> So, my question is: can this "L2 Gateway" help my setup? I mean, can I use
> "L2 Gateway" to tell: "Hey, OpenStack, those two Networks X & Y are in
> fact, just one. Is this possible?
>
> Cheers!
> Thiago
>
> __
> 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][L2GW] Mitaka release of L2 Gateway now available

[Sukhdev Kapur]

Hi Matt,

If you look through the documentation, there are steps described to install
L2GW outside of devstack.

-Sukhdev


On Wed, May 11, 2016 at 1:54 PM, Matt Kassawara <mkassaw...@gmail.com>
wrote:

> Do you have any examples of how to implement L2GW outside of DevStack?
> Operators do not deploy on DevStack.
>
> On Wed, May 11, 2016 at 2:47 PM, Sukhdev Kapur <sukhdevka...@gmail.com>
> wrote:
>
>> Hi Matt,
>>
>>
>> Here is the wiki - https://wiki.openstack.org/wiki/Neutron/L2-GW
>>
>> This should provide you all the information that you need.
>>
>> -Sukhdev
>>
>>
>>
>> On Wed, May 11, 2016 at 1:14 PM, Matt Kassawara <mkassaw...@gmail.com>
>> wrote:
>>
>>> Can you point me to the documentation?
>>>
>>> On Wed, May 11, 2016 at 2:05 PM, Sukhdev Kapur <sukhdevka...@gmail.com>
>>> wrote:
>>>
>>>>
>>>> Folks,
>>>>
>>>> I am happy to announce that Mitaka release for L2 Gateway is released
>>>> and now available at https://pypi.python.org/pypi/networking-l2gw.
>>>>
>>>> You can install it by using "pip install networking-l2gw"
>>>>
>>>> This release has several enhancements and fixes for issues discovered
>>>> in liberty release.
>>>>
>>>> Thanks
>>>> Sukhdev Kapur
>>>>
>>>>
>>>>
>>>> __
>>>> 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
>
>
__
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][L2GW] Mitaka release of L2 Gateway now available

[Sukhdev Kapur]

Hi Matt,


Here is the wiki - https://wiki.openstack.org/wiki/Neutron/L2-GW

This should provide you all the information that you need.

-Sukhdev



On Wed, May 11, 2016 at 1:14 PM, Matt Kassawara <mkassaw...@gmail.com>
wrote:

> Can you point me to the documentation?
>
> On Wed, May 11, 2016 at 2:05 PM, Sukhdev Kapur <sukhdevka...@gmail.com>
> wrote:
>
>>
>> Folks,
>>
>> I am happy to announce that Mitaka release for L2 Gateway is released and
>> now available at https://pypi.python.org/pypi/networking-l2gw.
>>
>> You can install it by using "pip install networking-l2gw"
>>
>> This release has several enhancements and fixes for issues discovered in
>> liberty release.
>>
>> Thanks
>> Sukhdev Kapur
>>
>>
>> __
>> 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][L2GW] Mitaka release of L2 Gateway now available

[Sukhdev Kapur]

Folks,

I am happy to announce that Mitaka release for L2 Gateway is released and
now available at https://pypi.python.org/pypi/networking-l2gw.

You can install it by using "pip install networking-l2gw"

This release has several enhancements and fixes for issues discovered in
liberty release.

Thanks
Sukhdev Kapur
__
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] L2gw

[Sukhdev Kapur]

Yes, I am on it. I was waiting for a Green Light from few folks, which I
got this morning.
So, I will be working on releasing it sometime tomorrow.

Hope that is OK with everybody.

-Sukhdev


On Mon, May 9, 2016 at 6:46 PM, Armando M.  wrote:

>
>
> On 9 May 2016 at 18:03, Gary Kotton  wrote:
>
>> Hi,
>> Are there plans to cut a a stable/mitaka version for the l2gw?
>> https://github.com/openstack/networking-l2gw
>> Thanks
>> Gary
>>
>
> I know Sukhdev was working on it.
>
>
>>
>> __
>> 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] Re: [stable] Requesting exception for stable/kilo

[Sukhdev Kapur]

Hi Akihito,

I think from the requirements.txt point of view, we are good.

Thanks
-Sukhdev




On Mon, May 9, 2016 at 2:11 PM, Akihiro Motoki <amot...@gmail.com> wrote:

> Hi Sukhdev, Dave,
>
> I think this backport is acceptable.
>
> In Kilo release, neutron is in a middle way of splitting vendor codes
> to separate repositories.
> The master fix is available at https://review.openstack.org/#/c/309622/
> and
> as far as I checked, stable/kilo fix are split into two parts:
> - networking-arista (db_api code):
> https://review.openstack.org/#/c/309651/
> - neutron : https://review.openstack.org/#/c/309653/
> It satisfies the guideline of backport of split-out vendor code [1].
>
> One point I'd like to mention is that this change requires a new
> release of networking-arista
> because the change uses new method from networking-arista.
> Do you need to update the vendor requirements.txt file [2] ?
>
> Otherwise it looks good.
>
> Akihiro
>
> [1]
> http://docs.openstack.org/developer/neutron/devref/contribute.html#backport-management-strategies
> [2]
> https://github.com/openstack/neutron/blob/stable/kilo/neutron/plugins/ml2/drivers/arista/requirements.txt
>
> 2016-05-10 4:46 GMT+09:00 Dave Walker <em...@daviey.com>:
> >
> >
> > On 4 May 2016 at 17:55, Sukhdev Kapur <sukhdevka...@gmail.com> wrote:
> >>
> >> Hi Stable Maintainers,
> >>
> >> We have a critical bug impacting customers production network. This is a
> >> minor fix.
> >> I would like to request an exception so that the customers do not have
> to
> >> baby
> >> sit this patch.
> >>
> >> https://review.openstack.org/#/c/309653/
> >>
> >> Please allow this to be merged.
> >>
> >> Thanks
> >> -Sukhdev
> >>
> >
> > Hi,
> >
> > Thanks for raising this.
> >
> > I'm currently blocking the 2015.1.4 release on this request.  As it
> isn't a
> > clean backport and the 11th hour, I really want a review from
> neutron-core.
> >
> > However, this hasn't been forthcoming.  I really need this asap, or we
> will
> > have to release without it.
> >
> > Ps. apologies for the empty reply just now.
> >
> > --
> > Kind Regards,
> > Dave Walker
> >
> >
> __
> > 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] Re: [stable] Requesting exception for stable/kilo

[Sukhdev Kapur]

Hi Dave,

I will get on it right away. Let me find Neutron Cores to review it.

Please stand by

-Sukhdev


On Mon, May 9, 2016 at 12:46 PM, Dave Walker <em...@daviey.com> wrote:

>
>
> On 4 May 2016 at 17:55, Sukhdev Kapur <sukhdevka...@gmail.com> wrote:
>
>> Hi Stable Maintainers,
>>
>> We have a critical bug impacting customers production network. This is a
>> minor fix.
>> I would like to request an exception so that the customers do not have to
>> baby
>> sit this patch.
>>
>> https://review.openstack.org/#/c/309653/
>>
>> Please allow this to be merged.
>>
>> Thanks
>> -Sukhdev
>>
>>
> Hi,
>
> Thanks for raising this.
>
> I'm currently blocking the 2015.1.4 release on this request.  As it isn't
> a clean backport and the 11th hour, I really want a review from
> neutron-core.
>
> However, this hasn't been forthcoming.  I really need this asap, or we
> will have to release without it.
>
> Ps. apologies for the empty reply just now.
>
> --
> Kind Regards,
> Dave Walker
>
> __
> 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] [stable] Requesting exception for stable/kilo

[Sukhdev Kapur]

Hi Stable Maintainers,

We have a critical bug impacting customers production network. This is a
minor fix.
I would like to request an exception so that the customers do not have to
baby
sit this patch.

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

Please allow this to be merged.

Thanks
-Sukhdev
__
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] Newton blueprints call for action

[Sukhdev Kapur]

Hi Rossella,

Good to hear that you will follow through with this. Ironic is looking for
this API as well for bare metal deployments. We would love to work with you
to make sure that this API/Implementation works for all servers ( VMs as
well BMs)

Thanks
-Sukhdev


On Wed, Apr 6, 2016 at 4:32 AM, Rossella Sblendido 
wrote:

>
>
> On 04/05/2016 05:43 AM, Armando M. wrote:
> >
> > With this email I would like to appeal to the people in CC to report
> > back their interest in continuing working on these items in their
> > respective capacities, and/or the wider community, in case new owners
> > need to be identified.
> >
> > I look forward to hearing back, hoping we can find the right resources
> > to resume progress, and bring these important requirements to completion
> > in time for Newton.
>
> Count me in for the vlan-aware-vms. We have now a solid design, it's
> only a matter of putting it into code. I will help any way I can, I
> really want to see this feature in Newton.
>
> cheers,
>
> Rossella
>
> __
> 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] Somebody posted this on #openstack-meetng-4

[Sukhdev Kapur]

I just noticed that somebody posted this on the above meeting channel.


[23:22:31]   Allah is doing

[23:22:42]   sun is not doing Allah is doing

[23:22:42]   *yamamoto* (~yamam...@i118-21-144-234.s30.a048.ap.plala.or.jp)
left IRC (Remote host closed the connection)

[23:22:54]   moon is not doing Allah is doing

[23:23:10]   stars are not doing Allah is doing

[23:23:22]   planets are not doing Allah is doing

[23:23:35]   galaxies are not doing Allah is doing

[23:23:47]   oceans are not doing Allah is doing

[23:23:51]   *Sukhdev* (~textual@162.210.130.3) left IRC (Ping timeout: 246
seconds)

[23:24:04]   mountains are not doing Allah is doing

[23:24:16]   trees are not doing Allah is doing

[23:24:29]   mom is not doing Allah is doing

[23:24:38]   dad is not doing Allah is doing

[23:24:50]   boss is not doing Allah is doing

[23:24:59]   job is not doing Allah is doing

[23:25:11]   dollar is not doing Allah is doing

[23:25:23]   degree is not doing Allah is doing

[23:25:41]   medicine is not doing Allah is doing

[23:25:59]   customers are not doing Allah is doing

[23:26:20]   you can not get a job without the permission of
allah

[23:26:43]   you can not get married without the permission of
allah

[23:27:05]   nobody can get angry at you without the permission
of allah

[23:27:18]   light is not doing Allah is doing

[23:27:29]   fan is not doing Allah is doing

[23:27:30]   *amotoki* (~amot...@fl1-119-242-22-153.tky.mesh.ad.jp) joined
the channel

[23:27:40]   businessess are not doing Allah is doing

[23:27:52]   america is not doing Allah is doing

[23:28:12]   fire can not burn without the permission of allah

[23:28:28]   knife can not cut without the permission of allah

[23:28:45]   rulers are not doing Allah is doing

[23:29:01]   governments are not doing Allah is doing

[23:29:13]   sleep is not doing Allah is doing

[23:29:26]   hunger is not doing Allah is doing

[23:31:37]   food does not take away the hunger Allah takes away
the hunger

[23:31:54]   *amotoki* (~amot...@fl1-119-242-22-153.tky.mesh.ad.jp) left
IRC (Ping timeout: 250 seconds)

[23:32:03]   water does not take away the thirst Allah takes
away the thirst

[23:32:18]   seeing is not doing Allah is doing

[23:32:33]   hearing is not doing Allah is doing

[23:32:47]   seasons are not doing Allah is doing

[23:33:01]   weather is not doing Allah is doing

[23:33:10]   humans are not doing Allah is doing

[23:33:20]   animals are not doing Allah is doing

[23:33:42]   the best amongst you are those who learn and teach
quran

[23:34:39]   *spzala* (~spzala@107.15.105.223) joined the channel

[23:35:17]   one letter read from book of Allah amounts to one
good deed ten times

[23:35:55]   one letter read from book of Allah amounts to one
good deed and Allah multiplies one good deed ten times

[23:36:34]   hearts get rusted as does iron with water to remove
rust from heart recitation of Quran and rememberance of death

[23:36:37]   *Jeffrey4l__* (~Jeffrey@119.251.238.37) joined the channel

[23:36:44]   heart is likened to a mirror

[23:37:09]   when a person commits one sin a black dot sustains
the heart

[23:38:38]   Allah is doing

[23:38:55]   sun is not doing Allah is doing

[23:39:31]   *spzala* (~spzala@107.15.105.223) left IRC (Ping timeout: 248
seconds)

[23:39:34]   *user_9876* (779dcd38@gateway/web/cgi-irc/
kiwiirc.com/ip.119.157.205.56) left IRC (Quit: http://www.kiwiirc.com/ - A
hand crafted IRC client)

[23:41:51]   *yamamoto* (~yamam...@i118-21-144-234.s30.a048.ap.plala.or.jp)
joined the channel
__
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][ml2][Manila] API to query segments used during port binding

[Sukhdev Kapur]

Hi Marc,

I am driving the ironic-ml2 integration and introduced baremetal type for
vmic_type.
You can very much use the same integration here - however, I am not
completely clear about your use case.
Do you want neutron/ML2 to plumb the network for Manila or do you want to
find out what VLAN (segmentation id) is used on the segment which connects
TOR to the storage device?

You had this on the agenda of ML2 meeting for tomorrow and I was going to
discuss this with you in the meeting. But, I noticed that you removed it
from the agenda. Do you have what you need? If not, you may want to join us
in the ML2 meeting tomorrow and we can discuss this use case there.

-Sukhdev


On Tue, Mar 1, 2016 at 1:08 AM, Koderer, Marc  wrote:

>
> On 01 Mar 2016, at 06:22, Kevin Benton  wrote:
>
> >This seems gross and backwards. It makes sense as a short term hack but
> given that we have time to design this correctly I'd prefer to get this
> information in a more straighforward way.
>
> Well it depends on what is happening here. If Manilla is wiring up a
> specific VLAN for a port, that makes it part of the port binding process,
> in which case it should be an ML2 driver. Can you provide some more details
> about what Manilla is doing with this info?
>
>
> The VLAN segment ID and IP address is used in the share driver to
> configure the
> corresponding interface resources within the storage. Just to give some
> examples:
>
>  - NetApp driver uses it to create a logical interface and assign it to a
>“storage virtual machine” [1]
>  - EMC driver does it in similar manner [2]
>
> My idea was to use the same principle as ironic ml2 intregration is doing
> [3]
> by setting the vnic_type to “baremetal”.
>
> In Manila's current implementation storage drivers are also responsible to
> setup the right networking setup. Would you suggest to move this part into
> the
> port binding phase?
>
> Regards
> Marc
>
>
> [1]:
> https://github.com/openstack/manila/blob/master/manila/share/drivers/netapp/dataontap/cluster_mode/lib_multi_svm.py#L272
> [2]:
> https://github.com/openstack/manila/blob/master/manila/share/drivers/emc/plugins/vnx/connection.py#L609
> [3]:
> https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/ironic-ml2-integration.html
>
>
>
> On Mon, Feb 29, 2016 at 5:29 PM, Ben Swartzlander 
> wrote:
>
>> On 02/29/2016 04:38 PM, Kevin Benton wrote:
>>
>>> You're correct. Right now there is no way via the HTTP API to find which
>>> segments a port is bound to.
>>> This is something we can certainly consider adding, but it will need an
>>> RFE so it wouldn't land until Newton at the earliest.
>>>
>>
>> I believe Newton is the target for this work. This is feature freeze week
>> after all.
>>
>> Have you considered writing an ML2 driver that just notifies Manilla of
>>> the port's segment info? All of this information is available to ML2
>>> drivers in the PortContext object that is passed to them.
>>>
>>
>> This seems gross and backwards. It makes sense as a short term hack but
>> given that we have time to design this correctly I'd prefer to get this
>> information in a more straighforward way.
>>
>> -Ben Swartzlander
>>
>>
>> On Mon, Feb 29, 2016 at 6:48 AM, Ihar Hrachyshka >> > wrote:
>>>
>>> Fixed neutron tag in the subject.
>>>
>>> Marc > wrote:
>>>
>>> Hi Neutron team,
>>>
>>> I am currently working on a feature for hierarchical port
>>> binding support in
>>> Manila [1] [2]. Just to give some context: In the current
>>> implementation Manila
>>> creates a neutron port but let it unbound (state DOWN).
>>> Therefore Manila uses
>>> the port create only retrieve an IP address and segmentation ID
>>> (some drivers
>>> only support VLAN here).
>>>
>>> My idea is to change this behavior and do an actual port binding
>>> action so that
>>> the configuration of VLAN isn’t a manual job any longer. And
>>> that multi-segment
>>> and HPB is supported on the long-run.
>>>
>>> My current issue is: How can Manila retrieve the segment
>>> information for a
>>> bound port? Manila only is interested in the last (bottom)
>>> segmentation ID
>>> since I assume the storage is connected to a ToR switch.
>>>
>>> Database-wise it’s possible to query it using
>>> ml2_port_binding_levels table.
>>> But AFAIK there is no API to query this. The only information
>>> that is exposed
>>> are all segments of a network. But this is not sufficient to
>>> identify which
>>> segments actually used for a port binding.
>>>
>>> Regards
>>> Marc
>>> SAP SE
>>>
>>> [1]:
>>>
>>> 

[openstack-dev] [neutron][L2 Gateway]

[Sukhdev Kapur]

Folks,

Due to holiday on Monday in USA, there will be no L2 Gateway meeting on
February 15.

Feel free to use the channel for any discussions that you would want to
carry during that hour.

Thanks
-Sukhdev
__
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][ironic] - no meeting on Feb 15

[Sukhdev Kapur]

Folks,

Due to holiday on Monday in USA, there will be no Ironic-Neutron
integration meeting on February 15.

Feel free to use the channel for any discussions that you would want to
carry during that hour.

Thanks
Sukhdev
__
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] Liberty release for L2GW

[Sukhdev Kapur]

Folks,

This is to let everybody know that Liberty release for L2GW project is
released and is available at - https://pypi.python.org/pypi/networking-l2gw

Feel free to download it and use it. Please let us know if you see any
issue with it.

Authors of outstanding or new patches, please use your best judgement to
back-port them appropriately.

Thanks
-Sukhdev
__
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] [Ironic][Neutron] Testing of Ironic/Neutron integration on devstack

[Sukhdev Kapur]

Hi Vasyl,

This is great. Kevin and I was working on the similar thing. I just
finished testing his patch and gave a +1.
This is a missing (and needed) functionality for getting the Ironic/Neutron
integration completed.

As Kevin suggests, it will be best if we can combine these approaches and
come up with the best solution.

If you are available, please join us in our next weekly meeting at 8AM
(pacific time) at #openstack-meeting-4.
I am sure team will be excited to know about this solution and this will
give an opportunity to make sure we cover all angles of this testing.

Thanks
-Sukhdev


On Wed, Nov 25, 2015 at 7:27 AM, Vasyl Saienko 
wrote:

> Hello Community,
>
> As you know Ironic/Neutron integration is planned in Mitaka. And at the
> moment we don't have any CI that will test it. Unfortunately we can't test
> Ironic/Neutron integration on HW as we don't have it.
> So probably the best way is to develop ML2 driver that will work with OVS.
>
> At the moment we have a PoC [1] of ML2 driver that works with Cisco and
> OVS on linux.
> Also we have some patches to devstack that allows to try Ironic/Neutron
> integration on VM and real HW. And quick guide how to test it locally [0]
>
> https://review.openstack.org/#/c/247513/
> https://review.openstack.org/#/c/248048/
> https://review.openstack.org/#/c/249717/
> https://review.openstack.org/#/c/248074/
>
> I'm interested in Neutron/Ironic integration. It would be great if we have
> it in Mitaka.
> I'm asking Community to check [0] and [1] and share your thoughts.
>
>  Also I would like to request a repo on openstack.org for [1]
>
>
> [0]
> https://github.com/jumpojoy/ironic-neutron/blob/master/devstack/examples/ironic-neutron-vm.md
> [1] https://github.com/jumpojoy/generic_switch
>
> --
> Sincerely
> Vasyl Saienko
>
> __
> 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][ironic] Ironic-Neutron meeting cancellation notice

[Sukhdev Kapur]

Folks,

We are canceling this week's Ironic-neutron integration meeting. I have a
family obligation to take care of and I have not been able to find a
replacement person who can chair this meeting. Therefore, we will cancel
this week's meeting.

Next meeting will take place on Monday, January 23 at the usual time at
usual place.

https://wiki.openstack.org/wiki/Meetings/Ironic-neutron#November_16_meeting_is_cancelled_-_Next_meeting_on_November_23.2C_2015


Thanks
-Sukhdev
__
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] [Ironic][Nova][Neutron] Multi-tenancy support

[Sukhdev Kapur]

Hi Vasyl,

I have not cross checked every patch in your list, but, the list looks
about right.
>From the Ironic, Nova, and Neutron point of the code is pretty much in
place with these patches.

In this week's meeting we discussed the plan for merging these patches.
Couple of things are holding us - namely the CI and documentation. We are
working on getting the CI addressed so that automated testing can be kicked
off, which will enable us to merge these patches (hopefully in M1).
Documentation is also underway.

As to ML2 driver (which you are looking for), in order make the CI work, we
are considering couple of options - either write a canned ML2 driver to
test this or enhance OVS driver to allow/accept/deal with new interface. We
did not have full quorum in this week's meeting. Hopefully, we will have
some concrete plans by the next week. But, this ML2 driver is being
considered to deal with devstack/CI related testing only.

In order to test the real world scenarios, you will need real HW and vendor
ML2 driver. The only two vendors that I am aware of who has this working
are HP and Arista. I do not know if HP is in a position to release it yet.
Arista will take some time to release it, as we follow very strict quality
control guidelines before releasing any software. I am only techie and do
not control the release of software, but, my guess is, its release will be
aligned with release of Mitaka.

If you believe you can be good with canned ML2 driver for devstack
initially, that may become available much earlier.
We meet every Monday at 1700 UTC (8am Pacific time) on
#openstack-meeting-4. Feel free to drop by or join us - as this is one of
the things we plan on discussing next Monday's meeting. This will give you
a better feel.

Hope this helps.

-Sukhdev
P.S. feel free to ping me on IRC (IRC handle: Sukhdev) on neutron or Ironic
channels


On Tue, Nov 10, 2015 at 3:05 AM, Vasyl Saienko 
wrote:

> Hello community,
>
> I would like to start preliminary testing of Ironic multi-tenant network
> setup which is supported by Neutron in Liberty according to [1]. I found
> the following patches that are on review. Also neutron ML2 plugin is
> needed. I can't find any plugin that supports multi-tenancy and Cisco
> (Catalyst)/Arista switches. I would be grateful for any information on
> the matter.
>
> *Ironic:*
>
> https://review.openstack.org/#/c/206232/
>
> https://review.openstack.org/#/c/206238/
>
> https://review.openstack.org/#/c/206243/
>
> https://review.openstack.org/#/c/206244/
>
> https://review.openstack.org/#/c/206245/
>
> https://review.openstack.org/#/c/139687/
>
> https://review.openstack.org/#/c/213262/
> https://review.openstack.org/#/c/228496/
>
> *Nova:*
>
> https://review.openstack.org/#/c/186855/
> https://review.openstack.org/#/c/194413/
>
> *python-ironicclient*:
> https://review.openstack.org/#/c/206144
>
>
> [1]
> https://blueprints.launchpad.net/neutron/+spec/neutron-ironic-integration
>
> __
> 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] HenryG addition to the Neutron Drivers team

[Sukhdev Kapur]

Hey Kevin,

It was always Henry's fault - now we can formally blame him :-):-)

Excellent move!! Well deserved addition!!!

Congratulations Henry!!!

-Sukhdev


On Tue, Oct 20, 2015 at 10:49 PM, Kevin Benton  wrote:

> Excellent addition! Remember everyone, if the feature you want doesn't
> make it into Neutron, it's now Henry's fault. :)
>
> On Tue, Oct 20, 2015 at 8:14 PM, Armando M.  wrote:
>
>> Hi folks,
>>
>> Henry has been instrumental in many areas of the projects and his crazy
>> working hours makes even Kevin and I bow in awe.
>>
>> Jokes aside, I would like to announce HenryG as a new member of the
>> Neutron Drivers team.
>>
>> Having a propension to attendance, and desire to review of RFEs puts you
>> on the right foot to join the group, whose members are rotated regularly so
>> that everyone is given the opportunity to grow, and no-one burns out.
>>
>> The team [1] meets regularly on Tuesdays [2], and anyone is welcome to
>> attend.
>>
>> Please, join me in welcome Henry to the team.
>>
>> Cheers,
>> Armando
>>
>> [1]
>> http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#drivers-team
>> [2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
>>
>>
>> __
>> 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
>>
>>
>
>
> --
> Kevin Benton
>
> __
> 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] Neutron Social Meetup in Tokyo

[Sukhdev Kapur]

Hey Akihiro,

Thanks for arranging this. I did not see any link to RSVP.
I would love to attend this event - please add me to the list.

Thanks
-Sukhdev


On Fri, Oct 23, 2015 at 9:23 AM, Akihiro Motoki  wrote:

> Hi Neutron folks,
>
> We are pleased to announce Neutron social meet-up in Tokyo.
> Thanks Takashi and Hirofumi for the big help.
>
> I hope many of you will be there and enjoy the time.
> If you have made RSVP, don't miss it!
> We recommend  to join the beginning, but come and join us even if you
> arrive late.
>
> 
>
> Thursday, Oct 29 19:00-22:00
> Hokkaido (北海道 品川インターシティー店)
>
> Location:
>
> https://www.google.com/maps/d/edit?mid=zBFFkY6dvVno.kOTkyNjZ2oU0=sharing
> 5th floor at the "shop and restaurant building" (between A and B
> buildings).
> It is at the opposite side of JR Shinagawa Station from the Summit side.)
>
> Approximately it costs ~5000 (Japanese) Yen depending on the number of
> folks who join.
> Note that we have no sponsors.
>
> If you have any trouble in reaching there or some question, reach me
> @ritchey98 on Twitter.
>
> 
>
> See you in Tokyo!
> Akihiro
>
> __
> 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][Ironic] Testing Ironic multi-tenancy feature

[Sukhdev Kapur]

Hi Pavlo,

This feature spans three projects; Neutron, Nova, and Ironic. The code for
neutron modification was merged in Liberty, but,
because of the timeline/logistics, we missed the deadline to merge the Nova
and Ironic code in Liberty. Most of the patches are ready and the
functionality is being tested very actively.

We are looking at merging all of this in early part of Mitaka (M1
hopefully).

This feature will be available on all Arista Switches and some HP switches
as well. Arista's ML2 driver will work for both virtual and baremetal
deployments - hence, no special configuration or setup requirements.
If you are looking for Arista HW to test this feature, please ping me
directly (IRC: Sukhdev, sukh...@arista.com), I can put you in touch with
right folks who can provide the HW.
Additionally, We have an early version of Ironic documentation. I will have
Neutron side documentation ready real soon, which will help with the
deployment setup.

Lots of information is available in the links provided by Jim. We meet
every week Monday at 9AM on #openstack-meeting-4. Feel free to stop by with
any specific questions. Team would be happy to help answer any questions.

Hope this helps.

-Sukhdev




On Mon, Oct 12, 2015 at 12:45 AM, Pavlo Shchelokovskyy <
pshchelokovs...@mirantis.com> wrote:

> Hi all,
>
> we would like to start preliminary testing of Ironic multi-tenant network
> setup which is supported by Neutron in Liberty according to [1]. According
> to Neutron design integration with network equipment is done via ML2
> plugins. We are looking for plugins and network equipment that can work
> with such Ironic multi-tenant setup. Could community recommend a pair of
> hardware switch/corresponding Neutron plugin that already supports this
> functionality?
>
> [1]
> https://blueprints.launchpad.net/neutron/+spec/neutron-ironic-integration
>
> Best regards,
> --
> Dr. Pavlo Shchelokovskyy
> Senior Software Engineer
> Mirantis Inc
> www.mirantis.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
>
>
__
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] L2 gateway project

[Sukhdev Kapur]

Hey Kyle,

We are down to couple of patches that are awaiting approval/merge. As soon
as it is done, I will let you know.

Thanks
-Sukhdev


On Fri, Oct 9, 2015 at 9:39 AM, Kyle Mestery  wrote:

> On Fri, Oct 9, 2015 at 10:13 AM, Gary Kotton  wrote:
>
>> Hi,
>> Who will be creating the stable/liberty branch?
>> Thanks
>> Gary
>>
>>
> I'll be doing this once someone from the L2GW team lets me know a commit
> SHA to create it from.
>
> Thanks,
> Kyle
>
>
>> __
>> 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] pypi packages for networking sub-projects

[Sukhdev Kapur]

Hey Kyle,

I am bit confused by this. I just checked networking-arista and see that
the co-owner of the project is openstackci
I also checked the [1] and [2] and the settings for networking-arista are
correct as well.

What else is missing which make you put networking-arista in the second
category?
Please advise.

Thanks
-Sukhdev


[1] - jenkins/jobs/projects.yaml

[2] - zuul/layout.yaml


On Wed, Sep 30, 2015 at 11:55 AM, Kyle Mestery  wrote:

> Folks:
>
> In trying to release some networking sub-projects recently, I ran into an
> issue [1] where I couldn't release some projects due to them not being
> registered on pypi. I have a patch out [2] which adds pypi publishing jobs,
> but before that can merge, we need to make sure all projects have pypi
> registrations in place. The following networking sub-projects do NOT have
> pypi registrations in place and need them created following the guidelines
> here [3]:
>
> networking-calico
> networking-infoblox
> networking-powervm
>
> The following pypi registrations did not follow directions to enable
> openstackci has "Owner" permissions, which allow for the publishing of
> packages to pypi:
>
> networking-ale-omniswitch
> networking-arista
> networking-l2gw
> networking-vsphere
>
> Once these are corrected, we can merge [2] which will then allow the
> neutron-release team the ability to release pypi packages for those
> packages.
>
> Thanks!
> Kyle
>
> [1]
> http://lists.openstack.org/pipermail/openstack-infra/2015-September/003244.html
> [2] https://review.openstack.org/#/c/229564/1
> [3]
> http://docs.openstack.org/infra/manual/creators.html#give-openstack-permission-to-publish-releases
>
> __
> 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] pypi packages for networking sub-projects

[Sukhdev Kapur]

Hey Kyle,

I have updated the ownership of networking-l2gw. I have +1'd your patch. As
soon as it merges the ACLs for the L2GW project will be fine as well.

Thanks for confirming about the networking-arista.

With this both of these packages should be good to go.

Thanks
-Sukhdev


On Wed, Sep 30, 2015 at 11:55 AM, Kyle Mestery  wrote:

> Folks:
>
> In trying to release some networking sub-projects recently, I ran into an
> issue [1] where I couldn't release some projects due to them not being
> registered on pypi. I have a patch out [2] which adds pypi publishing jobs,
> but before that can merge, we need to make sure all projects have pypi
> registrations in place. The following networking sub-projects do NOT have
> pypi registrations in place and need them created following the guidelines
> here [3]:
>
> networking-calico
> networking-infoblox
> networking-powervm
>
> The following pypi registrations did not follow directions to enable
> openstackci has "Owner" permissions, which allow for the publishing of
> packages to pypi:
>
> networking-ale-omniswitch
> networking-arista
> networking-l2gw
> networking-vsphere
>
> Once these are corrected, we can merge [2] which will then allow the
> neutron-release team the ability to release pypi packages for those
> packages.
>
> Thanks!
> Kyle
>
> [1]
> http://lists.openstack.org/pipermail/openstack-infra/2015-September/003244.html
> [2] https://review.openstack.org/#/c/229564/1
> [3]
> http://docs.openstack.org/infra/manual/creators.html#give-openstack-permission-to-publish-releases
>
> __
> 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] PTL Non-Candidacy

[Sukhdev Kapur]

Hi Kyle,

You have done wonders for the Neutron project. I hate to see you go, but,
fully understand your posiiton. We will miss you.

Best of luck
-Sukhdev


On Fri, Sep 11, 2015 at 2: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][ML2] ML2 late/early-cycle sprint announcement

[Sukhdev Kapur]

Hi Gal,

I was hoping you will join us in yesterday's ML2 meeting to discuss
further. Anyhow,  we would love your participation in this activity. Please
check the ether pad and see if you could join us in this sprint? If yes,
please sign up so that host can make appropriate arrangements.
Regardless,  please review the document and provide feedback. Also,  see if
you can join next week's meeting.

Thanks
Sukhdev
On Sep 9, 2015 4:50 AM, "Gal Sagie" <gal.sa...@gmail.com> wrote:

> Hi Sukhdev,
>
> The common sync framework is something i was also thinking about for some
> time now.
> I think its a very good idea and would love if i could participate in the
> talks (and hopefully the implementation as well)
>
> Thanks
> Gal.
>
> On Wed, Sep 9, 2015 at 9:46 AM, Sukhdev Kapur <sukhdevka...@gmail.com>
> wrote:
>
>> Folks,
>>
>> We are planning on having ML2 coding sprint on October 6 through 8, 2015.
>> Some are calling it Liberty late-cycle sprint, others are calling it Mitaka
>> early-cycle sprint.
>>
>> ML2 team has been discussing the issues related to synchronization of the
>> Neutron DB resources with the back-end drivers. Several issues have been
>> reported when multiple ML2 drivers are deployed in scaled HA deployments.
>> The issues surface when either side (Neutron or back-end HW/drivers)
>> restart and resource view gets out of sync. There is no mechanism in
>> Neutron or ML2 plugin which ensures the synchronization of the state
>> between the front-end and back-end. The drivers either end up implementing
>> their own solutions or they dump the issue on the operators to intervene
>> and correct it manually.
>>
>> We plan on utilizing Task Flow to implement the framework in ML2 plugin
>> which can be leveraged by ML2 drivers to achieve synchronization in a
>> simplified manner.
>>
>> There are couple of additional items on the Sprint agenda, which are
>> listed on the etherpad [1]. The details of venue and schedule are listed on
>> the enterpad as well. The sprint is hosted by Yahoo Inc.
>> Whoever is interested in the topics listed on the etherpad, is welcome to
>> sign up for the sprint and join us in making this reality.
>>
>> Additionally, we will utilize this sprint to formalize the design
>> proposal(s) for the fish bowl session at Tokyo summit [2]
>>
>> Any questions/clarifications, please join us in our weekly ML2 meeting on
>> Wednesday at 1600 UTC (9AM pacific time) at #openstack-meeting-alt
>>
>> Thanks
>> -Sukhdev
>>
>> [1] - https://etherpad.openstack.org/p/Neutron_ML2_Mid-Cycle_Sprint
>> [2] - https://etherpad.openstack.org/p/neutron-mitaka-designsummit
>>
>>
>>
>> __
>> 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
>>
>>
>
>
> --
> 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

[openstack-dev] [Neutron][ML2] ML2 late/early-cycle sprint announcement

[Sukhdev Kapur]

Folks,

We are planning on having ML2 coding sprint on October 6 through 8, 2015.
Some are calling it Liberty late-cycle sprint, others are calling it Mitaka
early-cycle sprint.

ML2 team has been discussing the issues related to synchronization of the
Neutron DB resources with the back-end drivers. Several issues have been
reported when multiple ML2 drivers are deployed in scaled HA deployments.
The issues surface when either side (Neutron or back-end HW/drivers)
restart and resource view gets out of sync. There is no mechanism in
Neutron or ML2 plugin which ensures the synchronization of the state
between the front-end and back-end. The drivers either end up implementing
their own solutions or they dump the issue on the operators to intervene
and correct it manually.

We plan on utilizing Task Flow to implement the framework in ML2 plugin
which can be leveraged by ML2 drivers to achieve synchronization in a
simplified manner.

There are couple of additional items on the Sprint agenda, which are listed
on the etherpad [1]. The details of venue and schedule are listed on the
enterpad as well. The sprint is hosted by Yahoo Inc.
Whoever is interested in the topics listed on the etherpad, is welcome to
sign up for the sprint and join us in making this reality.

Additionally, we will utilize this sprint to formalize the design
proposal(s) for the fish bowl session at Tokyo summit [2]

Any questions/clarifications, please join us in our weekly ML2 meeting on
Wednesday at 1600 UTC (9AM pacific time) at #openstack-meeting-alt

Thanks
-Sukhdev

[1] - https://etherpad.openstack.org/p/Neutron_ML2_Mid-Cycle_Sprint
[2] - https://etherpad.openstack.org/p/neutron-mitaka-designsummit
__
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] [Ironic][Neutron] Ironic-Neutron Integration meeting cancelled for Sept 7th

[Sukhdev Kapur]

Folks,

On account of Labor day holiday on Monday (9/7/15) in U.S.A, we will not be
holding Ironic-Neutron integration meeting.

On a separate note, Ironic core team is planning for Liberty-RC1 sometime
in third week of Sept. This means we need to test and complete all our
patches ASAP so that they can be merged in a timely fashion.

I have started to test the published patches. I have noticed an issue in
the newly modified Ironic CLI. I have notified the patch owner so that
issues can be addressed in timely manner.

Even though we are not going to meet next week, we should keep the moment
going. Please use IRC as well emails to reach each other so that we can
quickly address the issues.

Thanks
-Sukhdev
__
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] Common Base class for agents

[Sukhdev Kapur]

Sounds good. As long as proper due-diligence is done and there are is no
duplication of effort, it make sense.

Thanks
-Sukhdev


On Wed, Aug 5, 2015 at 12:42 AM, Andreas Scheuring 
scheu...@linux.vnet.ibm.com wrote:

 Sukhdev,
 last week I spent some time to figure out the current state of modular
 l2 agent design and discussion. I got the impression it's not in a good
 shape! So I personally don't think that it makes any sense to start with
 a modular l2 agent prototype and in the worst case throw it all away, as
 we missed a single detail. I would prefer to get folks with knowledge
 cross all l2 agents together and work on a design first, that everyone
 can agree upon.

 So my initial mail basically was to start a effort for easily sharing
 code. Maybe this will end up in a single agent having multiple drivers
 but that's not the primary goal (which is sharing code).

 I'm more with Carl, to start a code sharing effort and the macvtap agent
 effort in parallel, independent from each other.


 I must admit I have less insights into ovsagent. But I know that it
 diverged a lot from the other agents. Sean Collins is currently
 evaluating an approach to bring linuxbrige closer to ovs [1]. Maybe
 that's the way to got. Do internal refactorings to bring things close to
 each other and then see what might be possible to get a common agent or
 at least common code.


 But any other suggestions are highly welcome!




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



 Andreas
 (IRC: scheuran)


 On Di, 2015-08-04 at 22:42 -0700, Sukhdev Kapur wrote:
  We discussed this in ML2 sub-team meeting last week and felt the best
  approach is to implement this agent in a separate repo.
 
 
  There is already an on-going effort/plan for modular L2 agent. This
  agent would be a perfect candidate to take on that effort and
  implement it for macvtap agent. Once done, this could be moved over
  under neutron tent and other agents could be moved over to utilize
  this framework.
 
 
  Either of option 1 or 2 could be utilized to implement this agent.
  Keeping it in a seperate repo keeps the it from impacting any other
  agents. Once all ready and working, others could be converted over.
  You get the best of both words - i.e. quick implementation of this
  agent and a framework for others to use - and plenty of time to bake
  the framework.
 
 
  thoughts?
 
 
  Sukhdev
 
 
 
  On Mon, Aug 3, 2015 at 3:53 PM, Carl Baldwin c...@ecbaldwin.net
  wrote:
  I see this as two tasks:  1) A refactoring to share common
  code and 2)
  the addition of another agent following the pattern of the
  others.
  I'd prefer that the two tasks not be mixed in the same review
  because
  it makes it more difficult to review as I think Kevin eluded
  to.  For
  me, either could be done first.  I'm sure some reviewers would
  prefer
  that #1 be done first to avoid the proliferation of duplicated
  code.
  However, IMO, it is not necessary to be so strict.  It can
  take some
  time to review common code to get it right.  I'm afraid that
  holding
  up #2 until merging #1 will either motivate us to merge #1 too
  hastily
  and do a poor job or hold up #2 longer than it should be.
 
  If this were me, I would post both as independent reviews
  knowing that
  when one of the two merges, the other will have to be rebased
  to take
  the other in to account.  Sometimes, having the refactor in
  flight can
  help to allay fears about code proliferation.  Actually given
  Kevin's
  mention of the modular agent stuff, maybe it isn't worth
  putting much
  effort in to the refactor patch at all.
 
  My $0.02.
 
  Carl
 
  On Mon, Aug 3, 2015 at 9:46 AM, Andreas Scheuring
  scheu...@linux.vnet.ibm.com wrote:
   Hi,
   I'm planning to add a new ml2 driver and agent to neutron
  supporting
   macvtap attachments [1]. Kyle already decided, that this
  code should
   land in the neutron tree [2]. The normal approach till now
  was to copy
   an existing agent code and modify accordingly, which lead to
  a lot of
   duplicated code.
  
   So my question is, how to proceed with macvtap agent? I
  basically see
   the the 2 options:
  
   1) Do it like in the past, duplicate the code that is needed
  for macvtap
   agent (main loop, mechanism for detecting
  new/changed/deleted devices)
   and just go for it.
  
   2) Extract a new superclass that holds some of the common
  code. This
   would work for linuxridge agent and sriovnic agent - they
  could inherit
   from the new superclass

Re: [openstack-dev] [Neutron] Common Base class for agents

[Sukhdev Kapur]

Hey Kyle,

A concern was raised that this may create issue of breakages/instability in
other agents at the late stage of the release cycle - hence I proposed a
separate repo. But, if a proper due-diligence is done and the core team has
a plan to deal with this, sounds like a good plan to me.

regards.
-Sukhdev


On Wed, Aug 5, 2015 at 6:43 AM, Kyle Mestery mest...@mestery.com wrote:

 I definitely don't think this work should start in a new repository. As
 Sean and Andreas have said, I think the changes should be done in-tree
 rather than creating another repository for this work.

 On Wed, Aug 5, 2015 at 2:42 AM, Andreas Scheuring 
 scheu...@linux.vnet.ibm.com wrote:

 Sukhdev,
 last week I spent some time to figure out the current state of modular
 l2 agent design and discussion. I got the impression it's not in a good
 shape! So I personally don't think that it makes any sense to start with
 a modular l2 agent prototype and in the worst case throw it all away, as
 we missed a single detail. I would prefer to get folks with knowledge
 cross all l2 agents together and work on a design first, that everyone
 can agree upon.

 So my initial mail basically was to start a effort for easily sharing
 code. Maybe this will end up in a single agent having multiple drivers
 but that's not the primary goal (which is sharing code).

 I'm more with Carl, to start a code sharing effort and the macvtap agent
 effort in parallel, independent from each other.


 I must admit I have less insights into ovsagent. But I know that it
 diverged a lot from the other agents. Sean Collins is currently
 evaluating an approach to bring linuxbrige closer to ovs [1]. Maybe
 that's the way to got. Do internal refactorings to bring things close to
 each other and then see what might be possible to get a common agent or
 at least common code.


 But any other suggestions are highly welcome!




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



 Andreas
 (IRC: scheuran)


 On Di, 2015-08-04 at 22:42 -0700, Sukhdev Kapur wrote:
  We discussed this in ML2 sub-team meeting last week and felt the best
  approach is to implement this agent in a separate repo.
 
 
  There is already an on-going effort/plan for modular L2 agent. This
  agent would be a perfect candidate to take on that effort and
  implement it for macvtap agent. Once done, this could be moved over
  under neutron tent and other agents could be moved over to utilize
  this framework.
 
 
  Either of option 1 or 2 could be utilized to implement this agent.
  Keeping it in a seperate repo keeps the it from impacting any other
  agents. Once all ready and working, others could be converted over.
  You get the best of both words - i.e. quick implementation of this
  agent and a framework for others to use - and plenty of time to bake
  the framework.
 
 
  thoughts?
 
 
  Sukhdev
 
 
 
  On Mon, Aug 3, 2015 at 3:53 PM, Carl Baldwin c...@ecbaldwin.net
  wrote:
  I see this as two tasks:  1) A refactoring to share common
  code and 2)
  the addition of another agent following the pattern of the
  others.
  I'd prefer that the two tasks not be mixed in the same review
  because
  it makes it more difficult to review as I think Kevin eluded
  to.  For
  me, either could be done first.  I'm sure some reviewers would
  prefer
  that #1 be done first to avoid the proliferation of duplicated
  code.
  However, IMO, it is not necessary to be so strict.  It can
  take some
  time to review common code to get it right.  I'm afraid that
  holding
  up #2 until merging #1 will either motivate us to merge #1 too
  hastily
  and do a poor job or hold up #2 longer than it should be.
 
  If this were me, I would post both as independent reviews
  knowing that
  when one of the two merges, the other will have to be rebased
  to take
  the other in to account.  Sometimes, having the refactor in
  flight can
  help to allay fears about code proliferation.  Actually given
  Kevin's
  mention of the modular agent stuff, maybe it isn't worth
  putting much
  effort in to the refactor patch at all.
 
  My $0.02.
 
  Carl
 
  On Mon, Aug 3, 2015 at 9:46 AM, Andreas Scheuring
  scheu...@linux.vnet.ibm.com wrote:
   Hi,
   I'm planning to add a new ml2 driver and agent to neutron
  supporting
   macvtap attachments [1]. Kyle already decided, that this
  code should
   land in the neutron tree [2]. The normal approach till now
  was to copy
   an existing agent code and modify accordingly, which lead to
  a lot of
   duplicated code.
  
   So my question is, how to proceed with macvtap agent? I
  basically see
   the the 2 options

Re: [openstack-dev] [Neutron] Common Base class for agents

[Sukhdev Kapur]

We discussed this in ML2 sub-team meeting last week and felt the best
approach is to implement this agent in a separate repo.

There is already an on-going effort/plan for modular L2 agent. This agent
would be a perfect candidate to take on that effort and implement it for
macvtap agent. Once done, this could be moved over under neutron tent and
other agents could be moved over to utilize this framework.

Either of option 1 or 2 could be utilized to implement this agent. Keeping
it in a seperate repo keeps the it from impacting any other agents. Once
all ready and working, others could be converted over. You get the best of
both words - i.e. quick implementation of this agent and a framework for
others to use - and plenty of time to bake the framework.

thoughts?

Sukhdev


On Mon, Aug 3, 2015 at 3:53 PM, Carl Baldwin c...@ecbaldwin.net wrote:

 I see this as two tasks:  1) A refactoring to share common code and 2)
 the addition of another agent following the pattern of the others.
 I'd prefer that the two tasks not be mixed in the same review because
 it makes it more difficult to review as I think Kevin eluded to.  For
 me, either could be done first.  I'm sure some reviewers would prefer
 that #1 be done first to avoid the proliferation of duplicated code.
 However, IMO, it is not necessary to be so strict.  It can take some
 time to review common code to get it right.  I'm afraid that holding
 up #2 until merging #1 will either motivate us to merge #1 too hastily
 and do a poor job or hold up #2 longer than it should be.

 If this were me, I would post both as independent reviews knowing that
 when one of the two merges, the other will have to be rebased to take
 the other in to account.  Sometimes, having the refactor in flight can
 help to allay fears about code proliferation.  Actually given Kevin's
 mention of the modular agent stuff, maybe it isn't worth putting much
 effort in to the refactor patch at all.

 My $0.02.

 Carl

 On Mon, Aug 3, 2015 at 9:46 AM, Andreas Scheuring
 scheu...@linux.vnet.ibm.com wrote:
  Hi,
  I'm planning to add a new ml2 driver and agent to neutron supporting
  macvtap attachments [1]. Kyle already decided, that this code should
  land in the neutron tree [2]. The normal approach till now was to copy
  an existing agent code and modify accordingly, which lead to a lot of
  duplicated code.
 
  So my question is, how to proceed with macvtap agent? I basically see
  the the 2 options:
 
  1) Do it like in the past, duplicate the code that is needed for macvtap
  agent (main loop, mechanism for detecting new/changed/deleted devices)
  and just go for it.
 
  2) Extract a new superclass that holds some of the common code. This
  would work for linuxridge agent and sriovnic agent - they could inherit
  from the new superclass and get rid of some code but they still would
  exist on their own. OVS agent diverged too far to get it done easily.
  (More details below)
 
 
  My personal opinion: If I had the power to decide, I would go along with
  option #1, to get started quickly to still land my code for liberty. But
  I would be willing to implement #2 as well, if folks think this is a
  good idea.
 
 
 
  Any feedback is welcome!
 
 
  The ml2 driver for macvtap will stay separate.
 
 
  ---
 
 
  More details to #2
  A possible plan could be
  Liberty: Base class Stage 1* + macvtap agent using it
  Mitaka: move linuxbridge and sriovnic agent to use new base class
  Base class Stage 2**
  N: Step to a single agent having multiple interface drivers (lb,
  macvtap, sriov)?
 
 
  * Stage 1: with methods that are absolutely equal along the 3 agents or
  only require slight modifications
  e.g. _setup_rpc, _report_state, _device_info_has_changes,
  _process_network_devices
 
  ** Stage 2: methods that are still similar, but have diverged over time
  which is not just copy and paste but require some further thinking.
  e.g. treat_devices_added_updated, scan_devices, daemon_loop
 
 
  Options I laid aside
  3) I also discussed the modular l2 agent idea within the ml2 subgroup
  but the concept is in a bad shape and needs larger discussion. So no
  chance to start the macvtap work together with the modular agent work.
 
  4) Integrating it into the linuxbridge agent. A configuration option
  would distinguish if the agent runs in linuxbridge (default) or macvtap
  mode.
 
 
  [1] https://bugs.launchpad.net/neutron/+bug/1480979
  [2] https://review.openstack.org/#/c/195907/
 
 
  --
  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 

[openstack-dev] [Ironic][Neutron] Ironic/Neutron Integration weekly meeting kick off

[Sukhdev Kapur]

Folks,

Starting next monday (June 1, 2015), we are kicking off weekly meeting to
discuss and track the integration of Ironic and Neutron (ML2).
We are hoping to implement the Networking support within Liberty cycle.
Come join and help us achieve this goal.

Anybody who is interested in this topic, wants to contribute, share their
wisdom with the team, are welcome to join us. Here are the details of the
meeting:

Weekly on Mondays at 1600 UTC (9am Pacific Time)

IRC Channel - #openstack-meeting-4

Meeting Agenda and team charter -
https://wiki.openstack.org/wiki/Meetings/Ironic-neutron

Feel free to add a topic to the agenda for discussion.

Looking forward to meeting you in the channel.

regards..
-Sukhdev
__
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] Stepping down from Neutron core team

[Sukhdev Kapur]

Hey Salvatore,

Best of luck and thanks for all the hard work.


-Sukhdev




On Thu, May 21, 2015 at 8:58 AM, Salvatore Orlando sorla...@nicira.com
wrote:

 After putting the whole OpenStack networking contributors community
 through almost 8 cycles of pedant comments and annoying what if
 questions, it is probably time for me to relieve neutron contributors from
 this burden.

 It has been a pleasure for me serving the Neutron community (or Quantum as
 it was called at the time), and now it feel right - and probably overdue -
 to relinquish my position as a core team member in a spirit of rotation and
 alternation between contributors.

 Note: Before you uncork your champagne bottles, please be aware that I
 will stay in the Neutron community as a contributors and I might still end
 up reviewing patches.

 Thanks for being so understanding with my pedant remarks,
 Salvatore

 __
 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] L2 Gateway API released

[Sukhdev Kapur]

Folks,

L2 Gateway team is pleased to announce the release of L2 Gateway API. This
API can be downloaded from [1]

If you plan on attending OpenStack summit in Vancouver next week, please
attend presentation [2] to find more details about this feature.
If you are not able to attend the summit, be sure to watch the recording
this presentation on openstack.org after the summit.

Be sure check out the L2 Gateway wiki [3] for more information. L2 Gateway
can be deployed by using devstack. Please follow steps described at [4] to
install L2 Gateway using devstack.

L2 Gateway team meets on alternate mondays at 1700 UTC at
#openstack-meeting-4. If you would like to contribute or want to join us to
understand the details, The next meeting is scheduled on June 8th. The
meeting agenda and details are available at [5].

Thanks
-Sukhdev


[1] https://pypi.python.org/pypi/networking-l2gw/2015.1.1
[2]
https://openstacksummitmay2015vancouver.sched.org/event/7ed8f0119a9ad52ae50e32c752bbf9ed#.VVWSX9pVhHw
[3] https://wiki.openstack.org/wiki/Neutron/L2-GW
[4]
https://wiki.openstack.org/wiki/Neutron/L2-GW#L2_gateway_setup_using_devstack
[5] https://wiki.openstack.org/wiki/Meetings/L2Gateway
__
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] [third-party][infra] Third-Party CI Operators: Let's use a common CI Solution!

[Sukhdev Kapur]

Hi Anita,

Thanks for the clarification. I will plan on attending the summit session
on this topic (proposed by Kurt, I believe).
I have to admit that I have to always keep an eye out to ensure nothing is
broken in our CI because of any upgrade of packages, etc. and act
accordingly. If new unified framework can reduce/eliminate this effort, I
would like to at least understand it and discuss with the participants -
and, may join in.

Thanks for the good work.
-Sukhdev



On Tue, Apr 21, 2015 at 11:25 AM, Anita Kuno ante...@anteaya.info wrote:

 On 04/20/2015 04:39 PM, Sukhdev Kapur wrote:
  Hi Ramy,
 
  While I agree, in principal, with this line of thinking and goal, my
  concern will be how much extra work is it going to create for existing CI
  owners?
  Our Ci system has been stable for a long time, and we put in a good
 amount
  of effort to get it to that point. Our CI is not based upon zuul
 framework.
  Zuul was still under discussion at the time when we put together our CI.
 We
  use Jenkins as front end, along with Gerrit triggers, and AWS for
  posting/preserving results/log.  We have dedicated back-end servers for
   testing.
 
  My paranoia at this point will be to learn a new framework, risk breaking
  things and taking a huge effort to get things stabilized - without much
  additional ROI.
  Am I overreacting here or does my argument makes sense?
 
  I wonder how many folks will be in that camp?
 
  Sukhdev
 Hi Sukhdev:

 What is being offered is an opportunity to pool efforts for those who
 wish to participate. There is no pressure to participate if you are
 concerned that you would compromise the integrity of a stable system.
 You and others that have put in so much work are to be lauded for your
 commitment to your goal, thank you. Ramy's efforts in no way are an
 attempt to degrade the stability you have created.

 Part of the exhaustion level folks feel in this space, at all points in
 the spectrum, is the cost of maintenance. In infra we are constantly
 dealing with problems from operators and it would reduce the burden on
 us, as well as reduce the tension on operators, if we had a solution
 that was easier to maintain. The more people running the same structure,
 the easier any one issue is to solve (hopefully).

 The goal is once the structure is in place that OpenStack's Infra would
 also consume it, enabling common bugs to be discovered and fixed upstream.

 Noone is forced to participate nor are they going to be forced to
 operate this structure. This is simply a chance to work together on a
 direction which infra would very much like to see in place.

 Thanks Sukhdev,
 Anita.
 
 
 
 
  On Sun, Apr 19, 2015 at 10:17 PM, Asselin, Ramy ramy.asse...@hp.com
 wrote:
 
   All Third-Party CI operators:
 
 
 
  We’ve got 85 Third Party CI systems registered in the wiki[1], all of
 them
  running a variety of closed  open-source solutions.
 
  Instead of individually maintaining all those similar solutions, let’s
  join together and collectively maintain a single solution.
 
 
 
  If that sounds good to you, there’s an Infra-spec that’s been approved
 [2]
  to refactor much of what the Infrastructure team uses for the upstream
  “Jenkins” CI to be more easily reusable by many of us.
 
 
 
  We’ve got stories defined [3], and a few patches submitted. We’re using
  the gerrit-topic “downstream-puppet” [4].
 
 
 
  For example, we’ve got the first part under review for the “Log Server”,
  which creates your own version of http://logs.openstack.org/
 
 
 
  If anyone is interested in migrating towards a common solution, reply,
 or
  ping me IRC (asselin) on Freenode #openstack-infra, or join some of the
  third party ci meetings [5].
 
 
 
  Thanks!
 
  Ramy
 
 
 
  [1] https://wiki.openstack.org/wiki/ThirdPartySystems
 
  [2]
 
 http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html
 
  [3] https://storyboard.openstack.org/#!/story/2000101
 
  [4] https://review.openstack.org/#/q/topic:downstream-puppet,n,z
 
  [5]
 
 https://wiki.openstack.org/wiki/Meetings/ThirdParty#Weekly_Third_Party_meetings
 
 
 
 
 
 
 __
  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] [third-party][infra] Third-Party CI Operators: Let's use a common CI Solution!

[Sukhdev Kapur]

Hi Ramy,

While I agree, in principal, with this line of thinking and goal, my
concern will be how much extra work is it going to create for existing CI
owners?
Our Ci system has been stable for a long time, and we put in a good amount
of effort to get it to that point. Our CI is not based upon zuul framework.
Zuul was still under discussion at the time when we put together our CI. We
use Jenkins as front end, along with Gerrit triggers, and AWS for
posting/preserving results/log.  We have dedicated back-end servers for
 testing.

My paranoia at this point will be to learn a new framework, risk breaking
things and taking a huge effort to get things stabilized - without much
additional ROI.
Am I overreacting here or does my argument makes sense?

I wonder how many folks will be in that camp?

Sukhdev




On Sun, Apr 19, 2015 at 10:17 PM, Asselin, Ramy ramy.asse...@hp.com wrote:

  All Third-Party CI operators:



 We’ve got 85 Third Party CI systems registered in the wiki[1], all of them
 running a variety of closed  open-source solutions.

 Instead of individually maintaining all those similar solutions, let’s
 join together and collectively maintain a single solution.



 If that sounds good to you, there’s an Infra-spec that’s been approved [2]
 to refactor much of what the Infrastructure team uses for the upstream
 “Jenkins” CI to be more easily reusable by many of us.



 We’ve got stories defined [3], and a few patches submitted. We’re using
 the gerrit-topic “downstream-puppet” [4].



 For example, we’ve got the first part under review for the “Log Server”,
 which creates your own version of http://logs.openstack.org/



 If anyone is interested in migrating towards a common solution, reply, or
 ping me IRC (asselin) on Freenode #openstack-infra, or join some of the
 third party ci meetings [5].



 Thanks!

 Ramy



 [1] https://wiki.openstack.org/wiki/ThirdPartySystems

 [2]
 http://specs.openstack.org/openstack-infra/infra-specs/specs/openstackci.html

 [3] https://storyboard.openstack.org/#!/story/2000101

 [4] https://review.openstack.org/#/q/topic:downstream-puppet,n,z

 [5]
 https://wiki.openstack.org/wiki/Meetings/ThirdParty#Weekly_Third_Party_meetings





 __
 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] ML2 versus core plugin for OVN

[Sukhdev Kapur]

Folks,

A great discussion. I am not expert at OVN, hence, want to ask a question.
The answer may make a  case that it should probably be a ML2 driver as
oppose to monolithic plugin.

Say a customer want to deploy an OVN based solution and use HW devices from
one vendor for L2 and L3 (e.g. Arista or Cisco), and want to use another
vendor for services (e.g. F5 or A10) - how can that be supported?

If OVN goes in as ML2 driver, I can then run ML2 and Service plugin to
achieve above solution. For a monolithic plugin, don't I have an issue?

regards..
-Sukhdev


On Tue, Feb 24, 2015 at 8:58 AM, Salvatore Orlando sorla...@nicira.com
wrote:

 I think we're speculating a lot about what would be best for OVN whereas
 we should probably just expose pro and cons of ML2 drivers vs standalone
 plugin (as I said earlier on indeed it does not necessarily imply
 monolithic *)

 I reckon the job of the Neutron community is to provide a full picture to
 OVN developers - so that they could make a call on the integration strategy
 that best suits them.
 On the other hand, if we're planning to commit to a model where ML2 is not
 anymore a plugin but the interface with the API layer, then any choice
 which is not a ML2 driver does not make any sense. Personally I'm not sure
 we ever want to do that, at least not in the near/medium term, but I'm one
 and hardly representative of the developer/operator communities.

 Salvatore


 * In particular with the advanced service split out the term monolithic
 simply does not mean anything anymore.

 On 24 February 2015 at 17:48, Robert Kukura kuk...@noironetworks.com
 wrote:

  Kyle, What happened to the long-term potential goal of ML2 driver APIs
 becoming neutron's core APIs? Do we really want to encourage new monolithic
 plugins?

 ML2 is not a control plane - its really just an integration point for
 control planes. Although co-existence of multiple mechanism drivers is
 possible, and sometimes very useful, the single-driver case is fully
 supported. Even with hierarchical bindings, its not really ML2 that
 controls what happens - its the drivers within the framework. I don't think
 ML2 really limits what drivers can do, as long as a virtual network can be
 described as a set of static and possibly dynamic network segments. ML2 is
 intended to impose as few constraints on drivers as possible.

 My recommendation would be to implement an ML2 mechanism driver for OVN,
 along with any needed new type drivers or extension drivers. I believe this
 will result in a lot less new code to write and maintain.

 Also, keep in mind that even if multiple driver co-existence doesn't
 sound immediately useful, there are several potential use cases to
 consider. One is that it allows new technology to be introduced into an
 existing cloud alongside what previously existed. Migration from one ML2
 driver to another may be a lot simpler (and/or flexible) than migration
 from one plugin to another. Another is that additional drivers can support
 special cases, such as bare metal, appliances, etc..

 -Bob


 On 2/24/15 11:11 AM, Kyle Mestery wrote:

  On Tue, Feb 24, 2015 at 3:19 AM, Salvatore Orlando sorla...@nicira.com
 wrote:

  On 24 February 2015 at 01:34, Kyle Mestery mest...@mestery.com wrote:

  Russel and I have already merged the initial ML2 skeleton driver [1].

   The thinking is that we can always revert to a non-ML2 driver if
 needed.


  If nothing else an authoritative decision on a design direction saves
 us the hassle of going through iterations and discussions.
 The integration through ML2 is definitely viable. My opinion however is
 that since OVN implements a full control plane, the control plane bits
 provided by ML2 are not necessary, and a plugin which provides only
 management layer capabilities might be the best solution. Note: this does
 not mean it has to be monolithic. We can still do L3 with a service plugin.
  However, since the same kind of approach has been adopted for ODL I
 guess this provides some sort of validation.


 To be honest, after thinking about this last night, I'm now leaning
 towards doing this as a full plugin. I don't really envision OVN running
 with other plugins, as OVN is implementing it's own control plane, as you
 say. So the value of using ML2 is quesitonable.


I'm not sure how useful having using OVN with other drivers will be,
 and that was my initial concern with doing ML2 vs. full plugin. With the HW
 VTEP support in OVN+OVS, you can tie in physical devices this way. Anyways,
 this is where we're at for now. Comments welcome, of course.


  That was also kind of my point regarding the control plane bits
 provided by ML2 which OVN does not need. Still, the fact that we do not use
 a function does not make any harm.
 Also i'm not sure if OVN needs at all a type manager. If not, we can
 always implement a no-op type manager, I guess.

See above. I'd like to propose we move OVN to a full plugin instead
 of an ML2 MechanismDriver.

  

Re: [openstack-dev] [stable][neutron] backports vs. vendor decomposition

[Sukhdev Kapur]

Hi Ihar,

I have added this on the agenda for next neutron core meeting to discuss.

This email gives an excellent context to the issue at hand. Only one thing
I would like to add is that the deadline for stable/juno is only one week
away - hence, it raises the urgency to call for action.

Thanks

-Sukhdev



On Jan 21, 2015 1:43 PM, Ihar Hrachyshka ihrac...@redhat.com wrote:

 Hi all,

 as per:
https://github.com/openstack/neutron-specs/blob/master/specs/kilo/core-vendor-decomposition.rst,
neutron is going to spin off vendor plugins into separate trees outside of
neutron core team control. This raises several questions on how we are
going to handle stable branches that will still include plugin code for
several cycles.

 1) If a plugin is already spinned off and a patch is applicable for
stable branches, there are two cases:
 - patch is not merged into vendor repo;
 - patch is merged into the vendor repo.

 My take is:
 - if it's merged in the vendor repo, then we just cherry-pick from there
(it should just work if vendor repo was created with the whole master
history saved).
 - if it's not merged into the repo, I would recommend the author to
propose and merge it there first. If there are any justifiable issues with
proposing it for vendor repo inclusion, then we can consider stable-only
merge.

 2) If a plugin is in the middle of spinning off and a patch is applicable
for stable branch, then there are two options:
 - require plugin to spin off first and then apply the patch to vendor
repo, or
 - allow some types of patches to be merged into master while vendors are
working on spinning off the code.

 Examples of those patches are:
 - https://review.openstack.org/#/c/147976/
 - https://review.openstack.org/#/c/148369/

 Currently the patches above are blocked for master inclusion assuming the
spin off must take place first, and then bugs should be fixed in vendor
repo. At the same time, we usually avoid backports unless the code is not
in master anymore, but that's not the case here. So the current approach
effectively blocks any bug fixes for plugins in stable branches.

 If we would be sure that a plugin is out of the tree till Kilo, then it
would indeed be a waste of time to review the code for neutron/master since
it would be guaranteed to be released as a separate packagr e anyway. In
that case, it would be ok to forbid any patches for the  plugin code till
its spin off from master, and the patch would go directly to stable
branches.

 That said, it would potentially introduce regressions if we consider
upgrades from Juno to Kilo + vendor repo. We may say that since the
regression would be on vendor plugin side, and neutron team does not have
anything to do with spinned off plugins, that would be fine for us.

 But: we cannot guarantee that a plugin wil leave the neutron tree this
cycle. The spec explicitly gives permission to stay in the tree till
L-cycle, and in that case it will be our responsibility to handle
regressions in Kilo that we may introduce by blocking master fixes.

 I think we should try to set procedure that would avoid potential
regressions even if they will come from vendor repos.

 We allow fixes that are not applicable for final releases for master if
it's to be backported in stable branches. F.e. see
https://review.openstack.org/#/c/127633/ that was merged into master while
pecan migration should make it useless for Kilo.

 It's my belief plugin code bug fixes in stable branches should be treated
the same way.

 That said, we should expect vendors to run third party CI for stable
branches if they want to see backports merged in.

 ***
 I think the correct approach here is:
 - once a plugin is spinned off, consider it is a 'master' for the code,
and backport to stable branches directly from there;
 - before a plugin is spinned off, assume that it's not going to be
spinned off in Kilo, and hence allow bug fixes in neutron/master (but not
new features);
 - once we get to L release that requires all vendor plugin to go out,
forbid any fixes for the code, assuming they will either spin off or will
be dropped anyway.
 ***

 The approach is pretty similar to how oslo project handles new library
spin-offs from oslo-incubator. Yes, there is a difference here: in neutron,
we loose any control on spinned off repos. Though I don't feel it justifies
stable-only fixes while we can easily add value to vendor code by asking
people to consider fixing the bug there first. More importantly, nothing
should justify blocking bug fixing for stable branches.

 Thoughts?

 /Ihar

 __
 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] [neutron][devstack][keystone] Devstack failures due to empty service catalogue

[Sukhdev Kapur]

Hi All,

I noticed that our CI got hit sometime last night. Neutron is unable to
create private network as there is no Tenant ID.

Please see the error log here - http://paste.openstack.org/show/159912/

It appears that keystone is not creating tenant. Keystone screen log did
not show anything obvious.

I wonder if others saw the same issue and if anybody has any idea as to
what could have caused this? I looked at the obvious places and could not
find anything interesting.

Any guidance/help will be appreciated.

Thanks
-Sukhdev
__
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] Devstack failures related to q-vpn service

[Sukhdev Kapur]

Hi All,

I am seeing very frequent failures of devstack on our CI because of q-vpn
service failures. This has happened very recently. Is this a know issue?
I am tempted to disable q-vpn service on our CI to avoid this noise. I
wanted to reach out to see if others are also seeing this issue.

please advise..

-Sukhdev
__
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] Devstack failures related to q-vpn service

[Sukhdev Kapur]

HI Paul,

Here is one of the typical log when this failure hits.

http://arista-ci.arista.com:8000/January-2015/Arista_Tempest_Test/97/146597/5/stack.sh.log.gz

regards..
-Sukhdev


On Wed, Jan 14, 2015 at 1:06 PM, Paul Michali p...@michali.net wrote:

 Can you provide more info on what failures you are seeing?

 Regards,

 PCM

 PCM (Paul Michali)

 IRC pc_m (irc.freenode.com)
 Twitter... @pmichali


 On Wed, Jan 14, 2015 at 12:35 PM, Sukhdev Kapur sukhdevka...@gmail.com
 wrote:

 Hi All,

 I am seeing very frequent failures of devstack on our CI because of q-vpn
 service failures. This has happened very recently. Is this a know issue?
 I am tempted to disable q-vpn service on our CI to avoid this noise. I
 wanted to reach out to see if others are also seeing this issue.

 please advise..

 -Sukhdev


 __
 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] grenade failures

[Sukhdev Kapur]

Hi All,

I noticed that several neutron patches are failing
check-grenade-dsvm-neutron. I pinged it on IRC, did not get any response,
thought I post it here.


-Sukhdev
__
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][L2-Gateway] Meetings announcement

[Sukhdev Kapur]

Hi Ian,

I do not have one definition per se for the L2 gateway. Every use case
tends to define it in differently :-).  The desire (and goal) is to come up
with an API within Kilo cycle, upon which folks can start to build their
use cases, and (hopefully) iteratively come up with an API which covers
most, if not all, use cases.

For past few cycles (going all the way back to Hong Kong summit), we have
been discussing about this API, but, have not been able to converge.

During Paris summit (in the pods), a reasonable number of vendors
participated in the discussion to build upon the proposal made my Maruti
(from HP) to come up with the a starting point for this API. Maruti and
Armando (along with others) have been iterating over the spec proposed by
Maruti ( I posted the link on the wiki).

We felt, it is about time that we get together in a regular meeting form to
discuss as to what we have have so far and see how we can make it reality
for Kilo cycle. I realize that this may not fill all the bills. Once we
have a working version, we can alway build upon it and bring in more and
more use case as we move forward.

Please join us on IRC on this Monday and share your wisdom with other
members.

-Sukhdev


On Jan 4, 2015 2:08 AM, Kevin Benton blak...@gmail.com wrote:

 Weasels

 On Sat, Jan 3, 2015 at 2:57 PM, Ian Wells ijw.ubu...@cack.org.uk wrote:

 Sukhdev,

 Since the term is quite broad and has meant many things in the past, can
 you define what you're thinking of when you say 'L2 gateway'?

 Cheers,
 --
 Ian.

 On 2 January 2015 at 18:28, Sukhdev Kapur sukhdevka...@gmail.com wrote:

 Hi all,

 HAPPY NEW YEAR.

 Starting Monday (Jan 5th, 2015) we will be kicking of bi-weekly meetings
 for L2 Gateway discussions.

 We are hoping to come up with an initial version of L2 Gateway API in
 Kilo cycle. The intent of these bi-weekly meetings is to discuss issues
 related to L2 Gateway API.

 Anybody interested in this topic is invited to join us in these meetings
 and share your wisdom with the similar minded members.

 Here is the details of these meetings:

 https://wiki.openstack.org/wiki/Meetings#Networking_L2_Gateway_meeting

 I have put together a wiki for this project. Next week is the initial
 meeting and the agenda is pretty much open. We will give introduction of
 the members of the team as well the progress made so far on this topic. If
 you would like to add anything to the agenda, feel free to update the
 agenda at the following wiki:

 https://wiki.openstack.org/wiki/Meetings/L2Gateway

 Look forward to on the IRC.

 -Sukhdev



 ___
 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




 --
 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] [Neutron][L2-Gateway] Meetings announcement

[Sukhdev Kapur]

Hi all,

HAPPY NEW YEAR.

Starting Monday (Jan 5th, 2015) we will be kicking of bi-weekly meetings
for L2 Gateway discussions.

We are hoping to come up with an initial version of L2 Gateway API in Kilo
cycle. The intent of these bi-weekly meetings is to discuss issues related
to L2 Gateway API.

Anybody interested in this topic is invited to join us in these meetings
and share your wisdom with the similar minded members.

Here is the details of these meetings:

https://wiki.openstack.org/wiki/Meetings#Networking_L2_Gateway_meeting

I have put together a wiki for this project. Next week is the initial
meeting and the agenda is pretty much open. We will give introduction of
the members of the team as well the progress made so far on this topic. If
you would like to add anything to the agenda, feel free to update the
agenda at the following wiki:

https://wiki.openstack.org/wiki/Meetings/L2Gateway

Look forward to on the IRC.

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

[openstack-dev] [Neutron][ML2] - canceling this week's ML2 meeting

[Sukhdev Kapur]

Dear fellow ML2'ers,

In sprit of holidays, Bob and I decided to cancel this week's ML2 meeting.
We will resume our meetings from January 7th onwards.

Happy New Year to you and your loved ones.

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

Re: [openstack-dev] [neutron] Changes to the core team

[Sukhdev Kapur]

Congratulations Henry and Kevin. It has always been pleasure working with
you guys.


If I may express my opinion, Bob's contribution to ML2 has been quite
substantial. The kind of stability ML2 has achieved makes a statement of
his dedication to this work. I have worked very closely with Bob on several
issues and co-chaired ML2-Subteam with him and have developed tremendous
respect for his dedication.
Reading his email reply makes me believe he wants to continue to contribute
as core developer. Therefore, I would like to take an opportunity to appeal
to the core team to consider granting him his wish - i.e. vote -1 on his
removal.

regards..
-Sukhdev






On Wed, Dec 3, 2014 at 11:48 AM, Edgar Magana edgar.mag...@workday.com
wrote:

 I give +2 to Henry and Kevin. So, Congratulations Folks!
 I have been working with both of them and great quality reviews are always
 coming out from them.

 Many thanks to Nachi and Bob for their hard work!

 Edgar

 On 12/2/14, 7:59 AM, Kyle Mestery mest...@mestery.com wrote:

 Now that we're in the thick of working hard on Kilo deliverables, I'd
 like to make some changes to the neutron core team. Reviews are the
 most important part of being a core reviewer, so we need to ensure
 cores are doing reviews. The stats for the 180 day period [1] indicate
 some changes are needed for cores who are no longer reviewing.
 
 First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
 neutron-core. Bob and Nachi have been core members for a while now.
 They have contributed to Neutron over the years in reviews, code and
 leading sub-teams. I'd like to thank them for all that they have done
 over the years. I'd also like to propose that should they start
 reviewing more going forward the core team looks to fast track them
 back into neutron-core. But for now, their review stats place them
 below the rest of the team for 180 days.
 
 As part of the changes, I'd also like to propose two new members to
 neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin have
 been very active in reviews, meetings, and code for a while now. Henry
 lead the DB team which fixed Neutron DB migrations during Juno. Kevin
 has been actively working across all of Neutron, he's done some great
 work on security fixes and stability fixes in particular. Their
 comments in reviews are insightful and they have helped to onboard new
 reviewers and taken the time to work with people on their patches.
 
 Existing neutron cores, please vote +1/-1 for the addition of Henry
 and Kevin to the core team.
 
 Thanks!
 Kyle
 
 [1] http://stackalytics.com/report/contribution/neutron-group/180
 
 ___
 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] (no subject)

[Sukhdev Kapur]

Folks,

After Maruti's lighting talk on L2 Gateway, bunch of people/vendors
expressed interest in coming up with an API for this service. The goal is
to come up with a basic set of API which can be implemented in Kilo time
frame and build upon it over time in the future.
Armando, Akihiro, and others present in this small discussion decided to
get together tomorrow morning (Friday) in the Pods area (outside Degas
Room) at 9:30am.

If anybody has any interest in this discussion or can add value to this
discussion, this will be a great opportunity to stop by.

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

Re: [openstack-dev] [Neutron] L2 Gateway discussion

[Sukhdev Kapur]

resending with with the correct subject

On Thu, Nov 6, 2014 at 12:22 PM, Sukhdev Kapur sukhdevka...@gmail.com
wrote:

 Folks,

 After Maruti's lighting talk on L2 Gateway, bunch of people/vendors
 expressed interest in coming up with an API for this service. The goal is
 to come up with a basic set of API which can be implemented in Kilo time
 frame and build upon it over time in the future.
 Armando, Akihiro, and others present in this small discussion decided to
 get together tomorrow morning (Friday) in the Pods area (outside Degas
 Room) at 9:30am.

 If anybody has any interest in this discussion or can add value to this
 discussion, this will be a great opportunity to stop by.

 Thanks
 Sukhdev


 ___
 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] L2 Gateway discussion

[Sukhdev Kapur]

Can we put together all the references that might be relevant to this
effort on this mail thread? This is what I got so far:

https://review.openstack.org/#/c/93613/
https://review.openstack.org/#/c/100278/

Cheers,
Armando
resending with with the correct subject

On Thu, Nov 6, 2014 at 12:22 PM, Sukhdev Kapur sukhdevka...@gmail.com
wrote:

 Folks,

 After Maruti's lighting talk on L2 Gateway, bunch of people/vendors
 expressed interest in coming up with an API for this service. The goal is
 to come up with a basic set of API which can be implemented in Kilo time
 frame and build upon it over time in the future.
 Armando, Akihiro, and others present in this small discussion decided to
 get together tomorrow morning (Friday) in the Pods area (outside Degas
 Room) at 9:30am.

 If anybody has any interest in this discussion or can add value to this
 discussion, this will be a great opportunity to stop by.

 Thanks
 Sukhdev


 ___
 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] [OpenStack-Infra] VMWare NSX CI - recheck info

[Sukhdev Kapur]

Hi Kurt,

We (Arista) were one of the early adapters of the CI systems. We built our
system based upon the Neutron requirements as of late last year/early this
year. Our CI has been up and operational since January of this year. This
is before (or in parallel to Jay Pipes effort of Zuul based CIs).

We have invested a lot of effort in getting this done. In fact, I helped
many vendors setting up their Jenkin master/slaves, etc.
Additionally, we put an effort in coming up with a patch to support
recheck matching - as it was not supported in Gerritt Plugin.
Please see our wiki [1] which has a link to the Google doc describing the
recheck patch.

At the time the requirement was to support recheck no bug/bug#. Our
system is built to support this syntax.
The current Neutron Third party test systems are described in [2] and if
you look at the requirements described in [3], it states that a single
recheck should trigger all test systems.

Having said that, I understand the rationale of your argument. on this
thread, and actually agree with your point.
I have seen similar comments on various ML threads.

My suggestion is that this should be done in a coordinated manner so that
everybody understands the requirements, rather than simply throwing it on
the mailing list and assuming it is accepted by everybody. This is what
leads to the confusion. Some people will take it as a marching orders,
others may miss the thread and completely miss the communication.

Kyle Mestry (Neutron PTL) and Edgar Magana (Neutron Core) are proposing a
session at Kilo Summit in Paris to cover third party CI systems.
I would propose that you please coordinate with them and get your point of
view incorporated into this session. I have copied them both on this email
so that they can share their wisdom on the subject as well.

Thanks for all the good work by you and the infra team - making things
easier for us.

regards..
-Sukhdev

[1] https://wiki.openstack.org/wiki/Arista-third-party-testing
[2] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
[3] http://ci.openstack.org/third_party.html




On Wed, Sep 3, 2014 at 4:59 AM, Kurt Taylor krtay...@us.ibm.com wrote:

 Weidong Shao weidongs...@gmail.com wrote on 09/02/2014 09:35:30 PM:

  From:
 
  Weidong Shao weidongs...@gmail.com
 

  Subject:
 
  [OpenStack-Infra] VMWare NSX CI - recheck info

 
  Hi,
 
  I have a CL (https://review.openstack.org/#/c/116094/) that fails in
  VMWare NSX CI. I could not figure out the proper way to do a recheck
  on that.  On the error log page, there is a link to the team's wiki,
  from which this instruction is given:
  To issue a recheck, submit a comment with the following text:
  vmware-recheck
 
  I did that but it did not trigger a recheck.
  Could someone help me on this?

 As of today, all systems, project and third-party, should restart
 test jobs with just recheck comment. Including information after
 recheck doesn't break anything upstream.

 See: https://review.openstack.org/#/c/108724/  and
 the discussion at: https://review.openstack.org/#/c/100133/  and
 https://review.openstack.org/#/c/109565/

 Since most third-party systems are actually supporting some form of
 recheck-system name I am proposing a new change to the comment
 syntax to accommodate the need for triggering specific third-party
 system rechecks.

 Kurt Taylor (krtaylor)


 
  A related note on NSX CI:
 
  Apparently, the VMWare CI does not follow the guideline from http://
  ci.openstack.org/third_party.html to include contacts, recheck
  instruction etc. Some other CIs provide better messages on failure. e.g,
 
  A10
  Contact: a10-openstack...@a10networks.com
  Additional information: https://wiki.openstack.org/wiki/
  ThirdPartySystems/A10_Networks_CI
  Or from RYU CI
  Build failed. Leave a comment with 'recheck-ryu' to rerun a check.
  ('recheck' will be ignored.)
  Could someone from the NSX/Openstack team make the necessary changes?
 
  Thanks,
  Wei___


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


___
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] collecting recheck command to re-trigger third party CI

[Sukhdev Kapur]

Incidentally, I replied to Kurt's email this morning on this subject -
below is what I wrote.
There are several threads with such information. While it is great to
express opinions on the MLs, converting them into decisions/conclusions
should be done in a formal fashion. I suggested that this be addressed in a
session in Kilo - hosted by Kyle/Edgar.

-Sukhdev
---

Hi Kurt,

We (Arista) were one of the early adapters of the CI systems. We built our
system based upon the Neutron requirements as of late last year/early this
year. Our CI has been up and operational since January of this year. This
is before (or in parallel to Jay Pipes effort of Zuul based CIs).

We have invested a lot of effort in getting this done. In fact, I helped
many vendors setting up their Jenkin master/slaves, etc.
Additionally, we put an effort in coming up with a patch to support
recheck matching - as it was not supported in Gerritt Plugin.
Please see our wiki [1] which has a link to the Google doc describing the
recheck patch.

At the time the requirement was to support recheck no bug/bug#. Our
system is built to support this syntax.
The current Neutron Third party test systems are described in [2] and if
you look at the requirements described in [3], it states that a single
recheck should trigger all test systems.

Having said that, I understand the rationale of your argument. on this
thread, and actually agree with your point.
I have seen similar comments on various ML threads.

My suggestion is that this should be done in a coordinated manner so that
everybody understands the requirements, rather than simply throwing it on
the mailing list and assuming it is accepted by everybody. This is what
leads to the confusion. Some people will take it as a marching orders,
others may miss the thread and completely miss the communication.

Kyle Mestry (Neutron PTL) and Edgar Magana (Neutron Core) are proposing a
session at Kilo Summit in Paris to cover third party CI systems.
I would propose that you please coordinate with them and get your point of
view incorporated into this session. I have copied them both on this email
so that they can share their wisdom on the subject as well.

Thanks for all the good work by you and the infra team - making things
easier for us.

regards..
-Sukhdev

[1] https://wiki.openstack.org/wiki/Arista-third-party-testing
[2] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
[3] http://ci.openstack.org/third_party.html


On Wed, Sep 3, 2014 at 2:34 PM, Anita Kuno ante...@anteaya.info wrote:

 On 09/03/2014 02:03 PM, Akihiro Motoki wrote:
  Hi Neutron team,
 
  There are many third party CI in Neutron and we sometimes/usually
  want to retrigger third party CI to confirm results.
  A comment syntax varies across third party CI, so I think it is useful
  to gather recheck command in one place. I struggled to know how to
  rerun a specific CI.
 
  I added to recheck command column in the list of Neutron plugins and
  drivers [1].
  Could you add recheck command of your CI in the table?
  If it is not available, please add N/A.
 
  Note that supporting recheck is one of the requirements of third party
  testing. [2]
  I understand not all CIs support it due to various reasons, but
  collecting it is useful for developers and reviewers.
 
  A syntax of recheck command is under discussion in infra review [3].
  I believe the column of recheck command is still useful even after
  the official syntax is defined because it is not an easy thing to know
  each CI system name.
 
  [1]
 https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugin_and_Drivers
  [2] http://ci.openstack.org/third_party.html#requirements
  [3] https://review.openstack.org/#/c/118623/
 
  Thanks,
  Akihiro
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 Let's add the infra meeting log where this was discussed as reference
 material as well.


 http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-08-19-19.02.log.html
 timestamp: 19:48:38

 Thanks,
 Anita.

 ___
 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] New meeting rotation starting next week

[Sukhdev Kapur]

+1

It will be very useful to have neutron specific meetings on iCal -
considering that they will be moving around...

-Sukhdev



On Mon, Sep 1, 2014 at 6:58 PM, Kevin Benton blak...@gmail.com wrote:

 Unfortunately the master ICAL has so many meetings that it's not useful to
 have displaying as part of a normal calendar.
 I was hoping for a Neutron-specific one similar to Tripleo's.


 On Mon, Sep 1, 2014 at 6:52 PM, Anne Gentle a...@openstack.org wrote:

 Look on https://wiki.openstack.org/wiki/Meetings for a link to an iCal
 feed of all OpenStack meetings.


 https://www.google.com/calendar/ical/bj05mroquq28jhud58esggq...@group.calendar.google.com/public/basic.ics





 On Mon, Sep 1, 2014 at 8:26 PM, Kevin Benton blak...@gmail.com wrote:

 Is it possible to put an iCal on the wiki so we can automatically see
 when meetings are updated/cancelled/moved?
  On Sep 1, 2014 6:23 PM, Kyle Mestery mest...@mestery.com wrote:

 Per discussion again today in the Neutron meeting, next week we'll
 start rotating the meeting. This will mean next week we'll meet on
 Tuesday (9-9-2014) at 1400 UTC in #openstack-meeting-alt.

 I've updated the Neutron meeting page [1] as well as the meeting wiki
 page [2] with the new details on the meeting page.

 Please add any agenda items to the page.

 Looking forward to seeing some new faces who can't normally join us at
 the 2100UTC slot!

 Thanks,
 Kyle

 [1] https://wiki.openstack.org/wiki/Network/Meetings
 [2] https://wiki.openstack.org/wiki/Meetings#Neutron_team_meeting

 ___
 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




 --
 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] [Neutron][third-party] Arista CI hits 10, 000 runs this morning

[Sukhdev Kapur]

Folks,

Just wanted to share with you that Arista CI has been up and running 24x7
since the beginning of this year with no down time.

This morning it posted a vote on 10,000th Neutron patch

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

Re: [openstack-dev] [OpenStack-Infra] [Neutron][third-party] Arista CI hits 10, 000 runs this morning

[Sukhdev Kapur]

Thanks Salvatore.

I originally started with all tests and then started to back off to come up
with a set of tests which gave good stable results. Otherwise I was getting
65% - 80% pass rates. And, when a test fails, I will go back and triage it
only to realize that running that test did not really test the Arista ML2
driver, so, I filtered those tests. This is how I came up with the present
set of tests.

I am looking into the scenario tests. Having some issues with them. Will
soon be adding a few to the test suite.

Thanks for the feedback.

regards..
-Sukhdev



On Wed, Aug 6, 2014 at 4:19 PM, Salvatore Orlando sorla...@nicira.com
wrote:

 Congratulations!
 And to celebrate this milestone, I would consider running something more
 than ~280 api tests... perhaps also a few scenario tests?

 Salvatore


 On 7 August 2014 01:09, Sukhdev Kapur sukhdevka...@gmail.com wrote:

 Folks,

 Just wanted to share with you that Arista CI has been up and running 24x7
 since the beginning of this year with no down time.

 This morning it posted a vote on 10,000th Neutron patch

 cheers..
 -Sukhdev


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



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


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

[openstack-dev] [neutron][third-party] Updated Gerrit plugin for Third party CIs

[Sukhdev Kapur]

The upgrade of Gerrit in the upstream had impacted the gerrit triggers for
recheck no bug and recheck bug  in the downstream CI's that use
Gerrit plugin with Jenkins.

We have fixed the issue and have uploaded patch for the fix.
The following wiki has updated links to the correct patch, along with
updated steps to use Gerrit plugin along with Jenkins.

https://wiki.openstack.org/wiki/Arista-third-party-testing

Hope this helps.

Any questions/issues, please let us know.

regards..
Sukhdev
___
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] Neutron 3rd Party CI status dashboard

[Sukhdev Kapur]

Well, Luke, this is collaborative effort by everybody. By having these CI
systems in place ensures that one person's code does not break other
person's code and vice versa. Therefore, having these CI systems
operational and voting 24x7 is a critical step in achieving this goal.

However, the details as to how and what should be tested is definitely
debatable and the team has done excellent job in converging on that.

Now, as to the issue at hand which Anita is describing, I attended the
meeting this morning and was very pleased with the debate that took place
and the definition as to Sucess


On Mon, Jun 30, 2014 at 12:27 PM, Luke Gorrie l...@tail-f.com wrote:

 On 30 June 2014 21:08, Anita Kuno ante...@anteaya.info wrote:

 I am disappointed to realize that Ilya (or stackalytics, I don't know
 where this is coming from) is unwilling to cease making up definitions
 of success for third party ci systems to allow the openstack community
 to arrive at its own definition.


 There is indeed a risk that the new dashboards won't give a meaningful
 view of whether a 3rd party CI is voting correctly or not.

 However, there is an elephant in the room and a much more important
 problem:

 To measure how accurately a CI is voting says much more about a driver
 author's Gerrit-fu ability to operate a CI system than it does about
 whether the code they have contributed to OpenStack actually works, and the
 latter is what is actually important.

 To my mind the whole 3rd party testing discussion should refocus on
 helping developers maintain good working code and less on waving you will
 be kicked out of OpenStack if you don't keep your swarm of nebulous daemons
 running 24/7.



 ___
 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] [third-party] Neutron 3rd Party CI status dashboard

[Sukhdev Kapur]

Sorry, accidentally hit the wrong key and message went out.

Was making a mention about the definition of Success. I thought the debate
in the meeting was very productive - when a CI posts a +1 that is success,
and when a CI posts a -1 (or no vote with comment) is also a success - as
this reflects that the CI is doing what it is suppose to do.

So, when it comes to stackalytics, it is more critical to show if a given
CI is operational or not - and for how long?
Another thing we can debate is how to present the +1/-1 votes by a given CI
- unless we have some benchmark, it will be hard to consider
success/failure.

So, I am of the  opinion that, initially, we only report on the operational
status and duration of the CIs, and a counter of +1 and -1 votes over a
period of time. For example, looking at Arista CI, it has casted 7,958
votes so far and it has been operational for past 6 months. This
information is not available anywhere - hence, presenting this kind of
information on a dashboard created by Ilya would be very useful to the
community as well to the vendors..

thoughts?

-Sukhdev





On Mon, Jun 30, 2014 at 12:49 PM, Sukhdev Kapur sukhdevka...@gmail.com
wrote:

 Well, Luke, this is collaborative effort by everybody. By having these CI
 systems in place ensures that one person's code does not break other
 person's code and vice versa. Therefore, having these CI systems
 operational and voting 24x7 is a critical step in achieving this goal.

 However, the details as to how and what should be tested is definitely
 debatable and the team has done excellent job in converging on that.

 Now, as to the issue at hand which Anita is describing, I attended the
 meeting this morning and was very pleased with the debate that took place
 and the definition as to Sucess


 On Mon, Jun 30, 2014 at 12:27 PM, Luke Gorrie l...@tail-f.com wrote:

 On 30 June 2014 21:08, Anita Kuno ante...@anteaya.info wrote:

 I am disappointed to realize that Ilya (or stackalytics, I don't know
 where this is coming from) is unwilling to cease making up definitions
 of success for third party ci systems to allow the openstack community
 to arrive at its own definition.


 There is indeed a risk that the new dashboards won't give a meaningful
 view of whether a 3rd party CI is voting correctly or not.

  However, there is an elephant in the room and a much more important
 problem:

 To measure how accurately a CI is voting says much more about a driver
 author's Gerrit-fu ability to operate a CI system than it does about
 whether the code they have contributed to OpenStack actually works, and the
 latter is what is actually important.

 To my mind the whole 3rd party testing discussion should refocus on
 helping developers maintain good working code and less on waving you will
 be kicked out of OpenStack if you don't keep your swarm of nebulous daemons
 running 24/7.



 ___
 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][Swift][third-party] Most Third Party CI's failing

[Sukhdev Kapur]

I noticed this afternoon (Saturday PST 1:18pm) that most of the Third Party
test systems started to fail because of the seuptools bug because of
dependency in python-swiftclient. I further noticed that some of the CI's
are voting +1, but, when I look through the logs, they seem to be hitting
this issue as well.

I have been on #openstack-infra most of the afternoon discussing various
options suggested by folks. Infra folks have confirmed this issue and are
looking for solution.  I tried fixes suggested in [1] and [2] below and
removed the setuptools and reinstalled version 3.8. This did not help. I
have opened the bug[3] to track this issue.

I thought I send out this message in case other CI maintainers are
investigating this issue.

Please share ideas/thoughts so that we can get the CIs fixed as soon as
possible.

Thanks
-Sukhdev


[1] https://bugs.launchpad.net/python-swiftclient/+bug/1326972
[2] https://mail.python.org/pipermail/distutils-sig/2014-June/024478.html
[3] https://bugs.launchpad.net/python-swiftclient/+bug/1330140
___
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] Current status of Neutron 3rd Party CI and how to move forward

[Sukhdev Kapur]

Hi Kyle,

Arista CI has been voting +1 for success and comments in case of Failures.
Are the CI's now allowed to post -1 for failures? I have to make a minor
change to start voting -1.

Please advise.
-Sukhdev



On Fri, Jun 13, 2014 at 10:07 AM, Kyle Mestery mest...@noironetworks.com
wrote:

 I've spent some time doing some initial analysis of 3rd Party CI in
 Neutron. The tl;dr is that it's a mess, and it needs fixing. And I'm
 setting a deadline of Juno-2 for people to address their CI systems
 and get them in shape or we will remove plugins and drivers in Juno-3
 which do not meet the expectations set out below.

 My initial analysis of Neutron 3rd Party CI is here [1]. This was
 somewhat correlated with information from DriverLog [2], which was
 helpful to put this together.

 As you can see from the list, there are a lot of CI systems which are
 broken right now. Some have just recently started working again.
 Others are working great, and some are in the middle somewhere. The
 overall state isn't that great. I'm sending this email to
 openstack-dev and BCC;ing CI owners to raise awareness of this issue.
 If I have incorrectly labeled your CI, please update the etherpad and
 include links to the latest voting/comments your CI system has done
 upstream and reply to this thread.

 I have documented the 3rd Party CI requirements for Neutron here [3].
 I expect people to be following these guidelines for their CI systems.
 If there are questions on the guidelines or expectations, please reply
 to this thread or reach out to myself in #openstack-neutron on
 Freenode. There is also a third-party meeting [4] which is a great
 place to ask questions and share your experience setting up a 3rd
 party CI system. The infra team has done a great job sponsoring and
 running this meeting (thanks Anita!), so please both take advantage of
 it and also contribute to it so we can all share knowledge and help
 each other.

 Owners of plugins/drivers should ensure their CI is matching the
 requirements set forth by both infra and Neutron when running tests
 and posting results. Like I indicated earlier, we will look at
 removing code for drivers which are not meeting these requirements as
 set forth in the wiki pages.

 The goal of this effort is to ensure consistency across testing
 platforms, making it easier for developers to diagnose issues when
 third party CI systems fail, and to ensure these drivers are tested
 since they are part of the integrated releases we perform. We used to
 require a core team member to sponsor a plugin/driver, but we moved to
 the 3rd party CI system in Icehouse instead. Ensuring these systems
 are running and properly working is the only way we can ensure code is
 working when it's part of the integrated release.

 Thanks,
 Kyle

 [1] https://etherpad.openstack.org/p/ZLp9Ow3tNq
 [2]
 http://www.stackalytics.com/driverlog/?project_id=openstack%2Fneutronvendor=release_id=
 [3] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
 [4] https://wiki.openstack.org/wiki/Meetings/ThirdParty

 ___
 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][Swift][third-party] Most Third Party CI's failing

[Sukhdev Kapur]

Fellow Stackers,

I have an update on the issue.
Kudos to the Infra folks, a huge thanks to Monty for coming up with patch
for this setuptools issue, and Anita for for being on top of this. Please
follow the steps in http://paste.openstack.org/show/84076/ to pull this
patch on your local systems to get past the issue - until the fix in the
upstream is merged.

Note that you have to install mercurial to pull this patch.

Hope this helps.

regards..
-Sukhdev




On Sat, Jun 14, 2014 at 5:45 PM, Sukhdev Kapur sukhdevka...@gmail.com
wrote:

 I noticed this afternoon (Saturday PST 1:18pm) that most of the Third
 Party test systems started to fail because of the seuptools bug because of
 dependency in python-swiftclient. I further noticed that some of the CI's
 are voting +1, but, when I look through the logs, they seem to be hitting
 this issue as well.

 I have been on #openstack-infra most of the afternoon discussing various
 options suggested by folks. Infra folks have confirmed this issue and are
 looking for solution.  I tried fixes suggested in [1] and [2] below and
 removed the setuptools and reinstalled version 3.8. This did not help. I
 have opened the bug[3] to track this issue.

 I thought I send out this message in case other CI maintainers are
 investigating this issue.

 Please share ideas/thoughts so that we can get the CIs fixed as soon as
 possible.

 Thanks
 -Sukhdev


 [1] https://bugs.launchpad.net/python-swiftclient/+bug/1326972
 [2] https://mail.python.org/pipermail/distutils-sig/2014-June/024478.html
 [3] https://bugs.launchpad.net/python-swiftclient/+bug/1330140

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

Re: [openstack-dev] [Neutron][Swift][third-party] Most Third Party CI's failing

[Sukhdev Kapur]

Oppss...sorry wrong link... please use this
http://paste.openstack.org/show/84073/.


If anybody needs help, please ping me or go to #openstack-infra.

regards..
-Sukhdev



On Sat, Jun 14, 2014 at 9:34 PM, Sukhdev Kapur sukhdevka...@gmail.com
wrote:

 Fellow Stackers,

 I have an update on the issue.
 Kudos to the Infra folks, a huge thanks to Monty for coming up with patch
 for this setuptools issue, and Anita for for being on top of this. Please
 follow the steps in http://paste.openstack.org/show/84076/ to pull this
 patch on your local systems to get past the issue - until the fix in the
 upstream is merged.

 Note that you have to install mercurial to pull this patch.

 Hope this helps.

 regards..
 -Sukhdev




 On Sat, Jun 14, 2014 at 5:45 PM, Sukhdev Kapur sukhdevka...@gmail.com
 wrote:

 I noticed this afternoon (Saturday PST 1:18pm) that most of the Third
 Party test systems started to fail because of the seuptools bug because of
 dependency in python-swiftclient. I further noticed that some of the CI's
 are voting +1, but, when I look through the logs, they seem to be hitting
 this issue as well.

 I have been on #openstack-infra most of the afternoon discussing various
 options suggested by folks. Infra folks have confirmed this issue and are
 looking for solution.  I tried fixes suggested in [1] and [2] below and
 removed the setuptools and reinstalled version 3.8. This did not help. I
 have opened the bug[3] to track this issue.

 I thought I send out this message in case other CI maintainers are
 investigating this issue.

 Please share ideas/thoughts so that we can get the CIs fixed as soon as
 possible.

 Thanks
 -Sukhdev


 [1] https://bugs.launchpad.net/python-swiftclient/+bug/1326972
 [2] https://mail.python.org/pipermail/distutils-sig/2014-June/024478.html
 [3] https://bugs.launchpad.net/python-swiftclient/+bug/1330140



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

Re: [openstack-dev] [OpenStack-Infra] tgt restart fails in Cinder startup start: job failed to start

[Sukhdev Kapur]

Hi Roey,

I made this change and have been running this fix on 4 different servers. I
believe this fix works.  Things are working very smoothly.

I think we need to incorporate this change into devstack scripts or capture
it in the documentation so that it saves some grief to the next person.

Thanks
-Sukhdev




On Tue, Mar 11, 2014 at 3:06 AM, Roey Chen ro...@mellanox.com wrote:

  Forwarding the answer to the relevant mailing lists:



 ---



 Hi,



 Hope this could help,



 I've encountered this issue myself not to long ago on Ubuntu 12.04 host,

 it didn't happen again after messing with the Kernel Semaphore Limits
 parameters [1]:



 Adding this [2] line to `/etc/sysctl.conf` seems to do the trick.





 - Roey





 [1] http://paste.openstack.org/show/73086/

 [2] http://paste.openstack.org/show/73082/





 *From:* Sukhdev Kapur [mailto:sukhdevka...@gmail.com]
 *Sent:* Monday, March 10, 2014 5:56 PM
 *To:* Dane Leblanc (leblancd)
 *Cc:* OpenStack Development Mailing List (not for usage questions);
 openstack-in...@lists.openstack.org; openstack...@lists.openstack.org

 *Subject:* Re: [OpenStack-Infra] tgt restart fails in Cinder startup
 start: job failed to start



 I see the same issue. This issue has crept in during the latest flurry of
 check-ins. I started noticing this issue a day or two before the Icehouse
 Feature Freeze deadline.



 I tried restarting tgt as well, but, it does not help.



 However, rebooting the VM helps clear it up.



 Has anybody else seen it as well? Does anybody have a solution for it?



 Thanks

 -Sukhdev









 On Mon, Mar 10, 2014 at 8:37 AM, Dane Leblanc (leblancd) 
 lebla...@cisco.com wrote:

 I don't know if anyone can give me some troubleshooting advice with this
 issue.

 I'm seeing an occasional problem whereby after several DevStack
 unstack.sh/stack.sh cycles, the tgt daemon (tgtd) fails to start during
 Cinder startup.  Here's a snippet from the stack.sh log:

 2014-03-10 07:09:45.214 | Starting Cinder
 2014-03-10 07:09:45.215 | + return 0
 2014-03-10 07:09:45.216 | + sudo rm -f /etc/tgt/conf.d/stack.conf
 2014-03-10 07:09:45.217 | + _configure_tgt_for_config_d
 2014-03-10 07:09:45.218 | + [[ ! -d /etc/tgt/stack.d/ ]]
 2014-03-10 07:09:45.219 | + is_ubuntu
 2014-03-10 07:09:45.220 | + [[ -z deb ]]
 2014-03-10 07:09:45.221 | + '[' deb = deb ']'
 2014-03-10 07:09:45.222 | + sudo service tgt restart
 2014-03-10 07:09:45.223 | stop: Unknown instance:
 2014-03-10 07:09:45.619 | start: Job failed to start
 jenkins@neutronpluginsci:~/devstack$ 2014-03-10 07:09:45.621 | + exit_trap
 2014-03-10 07:09:45.622 | + local r=1
 2014-03-10 07:09:45.623 | ++ jobs -p
 2014-03-10 07:09:45.624 | + jobs=
 2014-03-10 07:09:45.625 | + [[ -n '' ]]
 2014-03-10 07:09:45.626 | + exit 1

 If I try to restart tgt manually without success:

 jenkins@neutronpluginsci:~$ sudo service tgt restart
 stop: Unknown instance:
 start: Job failed to start
 jenkins@neutronpluginsci:~$ sudo tgtd
 librdmacm: couldn't read ABI version.
 librdmacm: assuming: 4
 CMA: unable to get RDMA device list
 (null): iser_ib_init(3263) Failed to initialize RDMA; load kernel modules?
 (null): fcoe_init(214) (null)
 (null): fcoe_create_interface(171) no interface specified.
 jenkins@neutronpluginsci:~$

 The config in /etc/tgt is:

 jenkins@neutronpluginsci:/etc/tgt$ ls -l
 total 8
 drwxr-xr-x 2 root root 4096 Mar 10 07:03 conf.d
 lrwxrwxrwx 1 root root   30 Mar 10 06:50 stack.d -
 /opt/stack/data/cinder/volumes
 -rw-r--r-- 1 root root   58 Mar 10 07:07 targets.conf
 jenkins@neutronpluginsci:/etc/tgt$ cat targets.conf
 include /etc/tgt/conf.d/*.conf
 include /etc/tgt/stack.d/*
 jenkins@neutronpluginsci:/etc/tgt$ ls conf.d
 jenkins@neutronpluginsci:/etc/tgt$ ls /opt/stack/data/cinder/volumes
 jenkins@neutronpluginsci:/etc/tgt$

 I don't know if there's any missing Cinder config in my DevStack localrc
 files. Here's one that I'm using:

 MYSQL_PASSWORD=nova
 RABBIT_PASSWORD=nova
 SERVICE_TOKEN=nova
 SERVICE_PASSWORD=nova
 ADMIN_PASSWORD=nova

 ENABLED_SERVICES=g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-cond,cinder,c-sch,c-api,c-vol,n-sch,n-novnc,n-xvnc,n-cauth,horizon,rabbit
 enable_service mysql
 disable_service n-net
 enable_service q-svc
 enable_service q-agt
 enable_service q-l3
 enable_service q-dhcp
 enable_service q-meta
 enable_service q-lbaas
 enable_service neutron
 enable_service tempest
 VOLUME_BACKING_FILE_SIZE=2052M
 Q_PLUGIN=cisco
 declare -a Q_CISCO_PLUGIN_SUBPLUGINS=(openvswitch nexus)
 declare -A
 Q_CISCO_PLUGIN_SWITCH_INFO=([10.0.100.243]=admin:Cisco12345:22:neutronpluginsci:1/9)
 NCCLIENT_REPO=git://github.com/CiscoSystems/ncclient.git
 PHYSICAL_NETWORK=physnet1
 OVS_PHYSICAL_BRIDGE=br-eth1
 TENANT_VLAN_RANGE=810:819
 ENABLE_TENANT_VLANS=True
 API_RATE_LIMIT=False
 VERBOSE=True
 DEBUG=True
 LOGFILE=/opt/stack/logs/stack.sh.log
 USE_SCREEN=True
 SCREEN_LOGDIR=/opt/stack/logs

 Here are links to a log showing another localrc file that I use, and the
 corresponding stack.sh log:

 http

Re: [openstack-dev] [OpenStack-Infra] Intermittent failures cloning noVNC from github.com/kanaka

[Sukhdev Kapur]

I have noticed that even clone of devstack has failed few times within last
couple of hours - it was running fairly smooth so far.

-Sukhdev



On Tue, Mar 11, 2014 at 5:05 PM, Sukhdev Kapur sukhdevka...@gmail.comwrote:

 [adding openstack-dev list as well ]

 I have noticed that this has stated hitting my builds within last few
 hours. I have noticed exact same failures on almost 10 builds.
 Looks like something has happened within last few hours - perhaps the
 load?

 -Sukhdev



 On Tue, Mar 11, 2014 at 4:28 PM, Dane Leblanc (leblancd) 
 lebla...@cisco.com wrote:

  Apologies if this is the wrong audience for this question…



 I’m seeing intermittent failures running stack.sh whereby ‘git clone
 https://github.com/kanaka/noVNC.git /opt/stack/noVNC’ is returning
 various errors.  Below are 2 examples.



 Is this a known issue? Are there any localrc settings which might help
 here?



 Example 1:



 2014-03-11 15:00:33.779 | + is_service_enabled n-novnc

 2014-03-11 15:00:33.780 | + return 0

 2014-03-11 15:00:33.781 | ++ trueorfalse False

 2014-03-11 15:00:33.782 | + NOVNC_FROM_PACKAGE=False

 2014-03-11 15:00:33.783 | + '[' False = True ']'

 2014-03-11 15:00:33.784 | + NOVNC_WEB_DIR=/opt/stack/noVNC

 2014-03-11 15:00:33.785 | + git_clone 
 https://github.com/kanaka/noVNC.git/opt/stack/noVNC master

 2014-03-11 15:00:33.786 | + GIT_REMOTE=
 https://github.com/kanaka/noVNC.git

 2014-03-11 15:00:33.788 | + GIT_DEST=/opt/stack/noVNC

 2014-03-11 15:00:33.789 | + GIT_REF=master

 2014-03-11 15:00:33.790 | ++ trueorfalse False False

 2014-03-11 15:00:33.791 | + RECLONE=False

 2014-03-11 15:00:33.792 | + [[ False = \T\r\u\e ]]

 2014-03-11 15:00:33.793 | + echo master

 2014-03-11 15:00:33.794 | + egrep -q '^refs'

 2014-03-11 15:00:33.795 | + [[ ! -d /opt/stack/noVNC ]]

 2014-03-11 15:00:33.796 | + [[ False = \T\r\u\e ]]

 2014-03-11 15:00:33.797 | + git_timed clone
 https://github.com/kanaka/noVNC.git /opt/stack/noVNC

 2014-03-11 15:00:33.798 | + local count=0

 2014-03-11 15:00:33.799 | + local timeout=0

 2014-03-11 15:00:33.801 | + [[ -n 0 ]]

 2014-03-11 15:00:33.802 | + timeout=0

 2014-03-11 15:00:33.803 | + timeout -s SIGINT 0 git clone
 https://github.com/kanaka/noVNC.git /opt/stack/noVNC

 2014-03-11 15:00:33.804 | Cloning into '/opt/stack/noVNC'...

 2014-03-11 15:03:13.694 | error: RPC failed; result=56, HTTP code = 200

 2014-03-11 15:03:13.695 | fatal: The remote end hung up unexpectedly

 2014-03-11 15:03:13.697 | fatal: early EOF

 2014-03-11 15:03:13.698 | fatal: index-pack failed

 2014-03-11 15:03:13.699 | + [[ 128 -ne 124 ]]

 2014-03-11 15:03:13.700 | + die 596 'git call failed: [git clone'
 https://github.com/kanaka/noVNC.git '/opt/stack/noVNC]'

 2014-03-11 15:03:13.701 | + local exitcode=0

 2014-03-11 15:03:13.702 | [Call Trace]

 2014-03-11 15:03:13.703 | ./stack.sh:736:install_nova

 2014-03-11 15:03:13.705 | /var/lib/jenkins/devstack/lib/nova:618:git_clone

 2014-03-11 15:03:13.706 |
 /var/lib/jenkins/devstack/functions-common:543:git_timed

 2014-03-11 15:03:13.707 |
 /var/lib/jenkins/devstack/functions-common:596:die

 2014-03-11 15:03:13.708 | [ERROR]
 /var/lib/jenkins/devstack/functions-common:596 git call failed: [git clone
 https://github.com/kanaka/noVNC.git /opt/stack/noVNC]





 Example 2:



 2014-03-11 14:12:58.472 | + is_service_enabled n-novnc

 2014-03-11 14:12:58.473 | + return 0

 2014-03-11 14:12:58.474 | ++ trueorfalse False

 2014-03-11 14:12:58.475 | + NOVNC_FROM_PACKAGE=False

 2014-03-11 14:12:58.476 | + '[' False = True ']'

 2014-03-11 14:12:58.477 | + NOVNC_WEB_DIR=/opt/stack/noVNC

 2014-03-11 14:12:58.478 | + git_clone https://github.com/kanaka/noVNC.git 
 /opt/stack/noVNC master

 2014-03-11 14:12:58.479 | + GIT_REMOTE=https://github.com/kanaka/noVNC.git

 2014-03-11 14:12:58.480 | + GIT_DEST=/opt/stack/noVNC

 2014-03-11 14:12:58.481 | + GIT_REF=master

 2014-03-11 14:12:58.482 | ++ trueorfalse False False

 2014-03-11 14:12:58.483 | + RECLONE=False

 2014-03-11 14:12:58.484 | + [[ False = \T\r\u\e ]]

 2014-03-11 14:12:58.485 | + echo master

 2014-03-11 14:12:58.486 | + egrep -q '^refs'

 2014-03-11 14:12:58.487 | + [[ ! -d /opt/stack/noVNC ]]

 2014-03-11 14:12:58.488 | + [[ False = \T\r\u\e ]]

 2014-03-11 14:12:58.489 | + git_timed clone 
 https://github.com/kanaka/noVNC.git /opt/stack/noVNC

 2014-03-11 14:12:58.490 | + local count=0

 2014-03-11 14:12:58.491 | + local timeout=0

 2014-03-11 14:12:58.492 | + [[ -n 0 ]]

 2014-03-11 14:12:58.493 | + timeout=0

 2014-03-11 14:12:58.494 | + timeout -s SIGINT 0 git clone 
 https://github.com/kanaka/noVNC.git /opt/stack/noVNC

 2014-03-11 14:12:58.495 | Cloning into '/opt/stack/noVNC'...

 2014-03-11 14:14:02.315 | error: The requested URL returned error: 403 while 
 accessing https://github.com/kanaka/noVNC.git/info/refs

 2014-03-11 14:14:02.316 | fatal: HTTP request failed

 2014-03-11 14:14:02.317 | + [[ 128 -ne 124 ]]

 2014-03-11 14:14:02.318 | + die 596 'git call failed: [git clone

Re: [openstack-dev] [OpenStack-Infra] Intermittent failures cloning noVNC from github.com/kanaka

[Sukhdev Kapur]

Hey Monty,

The issue is when we are using stack.sh, how do we use cache dir as oppose
to going at git?
Is there any option which can be set to utilize this feature?

-Sukhdev



On Tue, Mar 11, 2014 at 4:42 PM, Monty Taylor mord...@inaugust.com wrote:

 Honestly not being snarky here ... The reason is that github if quite
 flaky. We try very hard to never touch it in infra. And by try, I mean we
 NEVER clone from it live, and if we absoluely can't avoid it for some
 reason, we are clone into a cache dir.

 On Mar 11, 2014 4:28 PM, Dane Leblanc (leblancd) lebla...@cisco.com
 wrote:
 
  Apologies if this is the wrong audience for this question…
 
 
 
  I’m seeing intermittent failures running stack.sh whereby ‘git clone
 https://github.com/kanaka/noVNC.git /opt/stack/noVNC’ is returning
 various errors.  Below are 2 examples.
 
 
 
  Is this a known issue? Are there any localrc settings which might help
 here?
 
 
 
  Example 1:
 
 
 
  2014-03-11 15:00:33.779 | + is_service_enabled n-novnc
 
  2014-03-11 15:00:33.780 | + return 0
 
  2014-03-11 15:00:33.781 | ++ trueorfalse False
 
  2014-03-11 15:00:33.782 | + NOVNC_FROM_PACKAGE=False
 
  2014-03-11 15:00:33.783 | + '[' False = True ']'
 
  2014-03-11 15:00:33.784 | + NOVNC_WEB_DIR=/opt/stack/noVNC
 
  2014-03-11 15:00:33.785 | + git_clone
 https://github.com/kanaka/noVNC.git /opt/stack/noVNC master
 
  2014-03-11 15:00:33.786 | + GIT_REMOTE=
 https://github.com/kanaka/noVNC.git
 
  2014-03-11 15:00:33.788 | + GIT_DEST=/opt/stack/noVNC
 
  2014-03-11 15:00:33.789 | + GIT_REF=master
 
  2014-03-11 15:00:33.790 | ++ trueorfalse False False
 
  2014-03-11 15:00:33.791 | + RECLONE=False
 
  2014-03-11 15:00:33.792 | + [[ False = \T\r\u\e ]]
 
  2014-03-11 15:00:33.793 | + echo master
 
  2014-03-11 15:00:33.794 | + egrep -q '^refs'
 
  2014-03-11 15:00:33.795 | + [[ ! -d /opt/stack/noVNC ]]
 
  2014-03-11 15:00:33.796 | + [[ False = \T\r\u\e ]]
 
  2014-03-11 15:00:33.797 | + git_timed clone
 https://github.com/kanaka/noVNC.git /opt/stack/noVNC
 
  2014-03-11 15:00:33.798 | + local count=0
 
  2014-03-11 15:00:33.799 | + local timeout=0
 
  2014-03-11 15:00:33.801 | + [[ -n 0 ]]
 
  2014-03-11 15:00:33.802 | + timeout=0
 
  2014-03-11 15:00:33.803 | + timeout -s SIGINT 0 git clone
 https://github.com/kanaka/noVNC.git /opt/stack/noVNC
 
  2014-03-11 15:00:33.804 | Cloning into '/opt/stack/noVNC'...
 
  2014-03-11 15:03:13.694 | error: RPC failed; result=56, HTTP code = 200
 
  2014-03-11 15:03:13.695 | fatal: The remote end hung up unexpectedly
 
  2014-03-11 15:03:13.697 | fatal: early EOF
 
  2014-03-11 15:03:13.698 | fatal: index-pack failed
 
  2014-03-11 15:03:13.699 | + [[ 128 -ne 124 ]]
 
  2014-03-11 15:03:13.700 | + die 596 'git call failed: [git clone'
 https://github.com/kanaka/noVNC.git '/opt/stack/noVNC]'
 
  2014-03-11 15:03:13.701 | + local exitcode=0
 
  2014-03-11 15:03:13.702 | [Call Trace]
 
  2014-03-11 15:03:13.703 | ./stack.sh:736:install_nova
 
  2014-03-11 15:03:13.705 |
 /var/lib/jenkins/devstack/lib/nova:618:git_clone
 
  2014-03-11 15:03:13.706 |
 /var/lib/jenkins/devstack/functions-common:543:git_timed
 
  2014-03-11 15:03:13.707 |
 /var/lib/jenkins/devstack/functions-common:596:die
 
  2014-03-11 15:03:13.708 | [ERROR]
 /var/lib/jenkins/devstack/functions-common:596 git call failed: [git clone
 https://github.com/kanaka/noVNC.git /opt/stack/noVNC]
 
 
 
 
 
  Example 2:
 
 
 
  2014-03-11 14:12:58.472 | + is_service_enabled n-novnc
 
  2014-03-11 14:12:58.473 | + return 0
 
  2014-03-11 14:12:58.474 | ++ trueorfalse False
 
  2014-03-11 14:12:58.475 | + NOVNC_FROM_PACKAGE=False
 
  2014-03-11 14:12:58.476 | + '[' False = True ']'
 
  2014-03-11 14:12:58.477 | + NOVNC_WEB_DIR=/opt/stack/noVNC
 
  2014-03-11 14:12:58.478 | + git_clone
 https://github.com/kanaka/noVNC.git /opt/stack/noVNC master
 
  2014-03-11 14:12:58.479 | + GIT_REMOTE=
 https://github.com/kanaka/noVNC.git
 
  2014-03-11 14:12:58.480 | + GIT_DEST=/opt/stack/noVNC
 
  2014-03-11 14:12:58.481 | + GIT_REF=master
 
  2014-03-11 14:12:58.482 | ++ trueorfalse False False
 
  2014-03-11 14:12:58.483 | + RECLONE=False
 
  2014-03-11 14:12:58.484 | + [[ False = \T\r\u\e ]]
 
  2014-03-11 14:12:58.485 | + echo master
 
  2014-03-11 14:12:58.486 | + egrep -q '^refs'
 
  2014-03-11 14:12:58.487 | + [[ ! -d /opt/stack/noVNC ]]
 
  2014-03-11 14:12:58.488 | + [[ False = \T\r\u\e ]]
 
  2014-03-11 14:12:58.489 | + git_timed clone
 https://github.com/kanaka/noVNC.git /opt/stack/noVNC
 
  2014-03-11 14:12:58.490 | + local count=0
 
  2014-03-11 14:12:58.491 | + local timeout=0
 
  2014-03-11 14:12:58.492 | + [[ -n 0 ]]
 
  2014-03-11 14:12:58.493 | + timeout=0
 
  2014-03-11 14:12:58.494 | + timeout -s SIGINT 0 git clone
 https://github.com/kanaka/noVNC.git /opt/stack/noVNC
 
  2014-03-11 14:12:58.495 | Cloning into '/opt/stack/noVNC'...
 
  2014-03-11 14:14:02.315 | error: The requested URL returned error: 403
 while accessing https://github.com/kanaka/noVNC.git/info/refs
 
  

Re: [openstack-dev] [OpenStack-Infra] Intermittent failures cloning noVNC from github.com/kanaka

[Sukhdev Kapur]

[adding openstack-dev list as well ]

I have noticed that this has stated hitting my builds within last few
hours. I have noticed exact same failures on almost 10 builds.
Looks like something has happened within last few hours - perhaps the load?

-Sukhdev



On Tue, Mar 11, 2014 at 4:28 PM, Dane Leblanc (leblancd) lebla...@cisco.com
 wrote:

  Apologies if this is the wrong audience for this question…



 I’m seeing intermittent failures running stack.sh whereby ‘git clone
 https://github.com/kanaka/noVNC.git /opt/stack/noVNC’ is returning
 various errors.  Below are 2 examples.



 Is this a known issue? Are there any localrc settings which might help
 here?



 Example 1:



 2014-03-11 15:00:33.779 | + is_service_enabled n-novnc

 2014-03-11 15:00:33.780 | + return 0

 2014-03-11 15:00:33.781 | ++ trueorfalse False

 2014-03-11 15:00:33.782 | + NOVNC_FROM_PACKAGE=False

 2014-03-11 15:00:33.783 | + '[' False = True ']'

 2014-03-11 15:00:33.784 | + NOVNC_WEB_DIR=/opt/stack/noVNC

 2014-03-11 15:00:33.785 | + git_clone 
 https://github.com/kanaka/noVNC.git/opt/stack/noVNC master

 2014-03-11 15:00:33.786 | + GIT_REMOTE=https://github.com/kanaka/noVNC.git

 2014-03-11 15:00:33.788 | + GIT_DEST=/opt/stack/noVNC

 2014-03-11 15:00:33.789 | + GIT_REF=master

 2014-03-11 15:00:33.790 | ++ trueorfalse False False

 2014-03-11 15:00:33.791 | + RECLONE=False

 2014-03-11 15:00:33.792 | + [[ False = \T\r\u\e ]]

 2014-03-11 15:00:33.793 | + echo master

 2014-03-11 15:00:33.794 | + egrep -q '^refs'

 2014-03-11 15:00:33.795 | + [[ ! -d /opt/stack/noVNC ]]

 2014-03-11 15:00:33.796 | + [[ False = \T\r\u\e ]]

 2014-03-11 15:00:33.797 | + git_timed clone
 https://github.com/kanaka/noVNC.git /opt/stack/noVNC

 2014-03-11 15:00:33.798 | + local count=0

 2014-03-11 15:00:33.799 | + local timeout=0

 2014-03-11 15:00:33.801 | + [[ -n 0 ]]

 2014-03-11 15:00:33.802 | + timeout=0

 2014-03-11 15:00:33.803 | + timeout -s SIGINT 0 git clone
 https://github.com/kanaka/noVNC.git /opt/stack/noVNC

 2014-03-11 15:00:33.804 | Cloning into '/opt/stack/noVNC'...

 2014-03-11 15:03:13.694 | error: RPC failed; result=56, HTTP code = 200

 2014-03-11 15:03:13.695 | fatal: The remote end hung up unexpectedly

 2014-03-11 15:03:13.697 | fatal: early EOF

 2014-03-11 15:03:13.698 | fatal: index-pack failed

 2014-03-11 15:03:13.699 | + [[ 128 -ne 124 ]]

 2014-03-11 15:03:13.700 | + die 596 'git call failed: [git clone'
 https://github.com/kanaka/noVNC.git '/opt/stack/noVNC]'

 2014-03-11 15:03:13.701 | + local exitcode=0

 2014-03-11 15:03:13.702 | [Call Trace]

 2014-03-11 15:03:13.703 | ./stack.sh:736:install_nova

 2014-03-11 15:03:13.705 | /var/lib/jenkins/devstack/lib/nova:618:git_clone

 2014-03-11 15:03:13.706 |
 /var/lib/jenkins/devstack/functions-common:543:git_timed

 2014-03-11 15:03:13.707 |
 /var/lib/jenkins/devstack/functions-common:596:die

 2014-03-11 15:03:13.708 | [ERROR]
 /var/lib/jenkins/devstack/functions-common:596 git call failed: [git clone
 https://github.com/kanaka/noVNC.git /opt/stack/noVNC]





 Example 2:



 2014-03-11 14:12:58.472 | + is_service_enabled n-novnc

 2014-03-11 14:12:58.473 | + return 0

 2014-03-11 14:12:58.474 | ++ trueorfalse False

 2014-03-11 14:12:58.475 | + NOVNC_FROM_PACKAGE=False

 2014-03-11 14:12:58.476 | + '[' False = True ']'

 2014-03-11 14:12:58.477 | + NOVNC_WEB_DIR=/opt/stack/noVNC

 2014-03-11 14:12:58.478 | + git_clone https://github.com/kanaka/noVNC.git 
 /opt/stack/noVNC master

 2014-03-11 14:12:58.479 | + GIT_REMOTE=https://github.com/kanaka/noVNC.git

 2014-03-11 14:12:58.480 | + GIT_DEST=/opt/stack/noVNC

 2014-03-11 14:12:58.481 | + GIT_REF=master

 2014-03-11 14:12:58.482 | ++ trueorfalse False False

 2014-03-11 14:12:58.483 | + RECLONE=False

 2014-03-11 14:12:58.484 | + [[ False = \T\r\u\e ]]

 2014-03-11 14:12:58.485 | + echo master

 2014-03-11 14:12:58.486 | + egrep -q '^refs'

 2014-03-11 14:12:58.487 | + [[ ! -d /opt/stack/noVNC ]]

 2014-03-11 14:12:58.488 | + [[ False = \T\r\u\e ]]

 2014-03-11 14:12:58.489 | + git_timed clone 
 https://github.com/kanaka/noVNC.git /opt/stack/noVNC

 2014-03-11 14:12:58.490 | + local count=0

 2014-03-11 14:12:58.491 | + local timeout=0

 2014-03-11 14:12:58.492 | + [[ -n 0 ]]

 2014-03-11 14:12:58.493 | + timeout=0

 2014-03-11 14:12:58.494 | + timeout -s SIGINT 0 git clone 
 https://github.com/kanaka/noVNC.git /opt/stack/noVNC

 2014-03-11 14:12:58.495 | Cloning into '/opt/stack/noVNC'...

 2014-03-11 14:14:02.315 | error: The requested URL returned error: 403 while 
 accessing https://github.com/kanaka/noVNC.git/info/refs

 2014-03-11 14:14:02.316 | fatal: HTTP request failed

 2014-03-11 14:14:02.317 | + [[ 128 -ne 124 ]]

 2014-03-11 14:14:02.318 | + die 596 'git call failed: [git clone' 
 https://github.com/kanaka/noVNC.git '/opt/stack/noVNC]'

 2014-03-11 14:14:02.319 | + local exitcode=0

 2014-03-11 14:14:02.321 | [Call Trace]

 2014-03-11 14:14:02.322 | ./stack.sh:736:install_nova

 2014-03-11 14:14:02.323 | 

Re: [openstack-dev] [OpenStack-Infra] tgt restart fails in Cinder startup start: job failed to start

[Sukhdev Kapur]

I see the same issue. This issue has crept in during the latest flurry of
check-ins. I started noticing this issue a day or two before the Icehouse
Feature Freeze deadline.

I tried restarting tgt as well, but, it does not help.

However, rebooting the VM helps clear it up.

Has anybody else seen it as well? Does anybody have a solution for it?

Thanks
-Sukhdev





On Mon, Mar 10, 2014 at 8:37 AM, Dane Leblanc (leblancd) lebla...@cisco.com
 wrote:

 I don't know if anyone can give me some troubleshooting advice with this
 issue.

 I'm seeing an occasional problem whereby after several DevStack
 unstack.sh/stack.sh cycles, the tgt daemon (tgtd) fails to start during
 Cinder startup.  Here's a snippet from the stack.sh log:

 2014-03-10 07:09:45.214 | Starting Cinder
 2014-03-10 07:09:45.215 | + return 0
 2014-03-10 07:09:45.216 | + sudo rm -f /etc/tgt/conf.d/stack.conf
 2014-03-10 07:09:45.217 | + _configure_tgt_for_config_d
 2014-03-10 07:09:45.218 | + [[ ! -d /etc/tgt/stack.d/ ]]
 2014-03-10 07:09:45.219 | + is_ubuntu
 2014-03-10 07:09:45.220 | + [[ -z deb ]]
 2014-03-10 07:09:45.221 | + '[' deb = deb ']'
 2014-03-10 07:09:45.222 | + sudo service tgt restart
 2014-03-10 07:09:45.223 | stop: Unknown instance:
 2014-03-10 07:09:45.619 | start: Job failed to start
 jenkins@neutronpluginsci:~/devstack$ 2014-03-10 07:09:45.621 | + exit_trap
 2014-03-10 07:09:45.622 | + local r=1
 2014-03-10 07:09:45.623 | ++ jobs -p
 2014-03-10 07:09:45.624 | + jobs=
 2014-03-10 07:09:45.625 | + [[ -n '' ]]
 2014-03-10 07:09:45.626 | + exit 1

 If I try to restart tgt manually without success:

 jenkins@neutronpluginsci:~$ sudo service tgt restart
 stop: Unknown instance:
 start: Job failed to start
 jenkins@neutronpluginsci:~$ sudo tgtd
 librdmacm: couldn't read ABI version.
 librdmacm: assuming: 4
 CMA: unable to get RDMA device list
 (null): iser_ib_init(3263) Failed to initialize RDMA; load kernel modules?
 (null): fcoe_init(214) (null)
 (null): fcoe_create_interface(171) no interface specified.
 jenkins@neutronpluginsci:~$

 The config in /etc/tgt is:

 jenkins@neutronpluginsci:/etc/tgt$ ls -l
 total 8
 drwxr-xr-x 2 root root 4096 Mar 10 07:03 conf.d
 lrwxrwxrwx 1 root root   30 Mar 10 06:50 stack.d -
 /opt/stack/data/cinder/volumes
 -rw-r--r-- 1 root root   58 Mar 10 07:07 targets.conf
 jenkins@neutronpluginsci:/etc/tgt$ cat targets.conf
 include /etc/tgt/conf.d/*.conf
 include /etc/tgt/stack.d/*
 jenkins@neutronpluginsci:/etc/tgt$ ls conf.d
 jenkins@neutronpluginsci:/etc/tgt$ ls /opt/stack/data/cinder/volumes
 jenkins@neutronpluginsci:/etc/tgt$

 I don't know if there's any missing Cinder config in my DevStack localrc
 files. Here's one that I'm using:

 MYSQL_PASSWORD=nova
 RABBIT_PASSWORD=nova
 SERVICE_TOKEN=nova
 SERVICE_PASSWORD=nova
 ADMIN_PASSWORD=nova

 ENABLED_SERVICES=g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-cond,cinder,c-sch,c-api,c-vol,n-sch,n-novnc,n-xvnc,n-cauth,horizon,rabbit
 enable_service mysql
 disable_service n-net
 enable_service q-svc
 enable_service q-agt
 enable_service q-l3
 enable_service q-dhcp
 enable_service q-meta
 enable_service q-lbaas
 enable_service neutron
 enable_service tempest
 VOLUME_BACKING_FILE_SIZE=2052M
 Q_PLUGIN=cisco
 declare -a Q_CISCO_PLUGIN_SUBPLUGINS=(openvswitch nexus)
 declare -A
 Q_CISCO_PLUGIN_SWITCH_INFO=([10.0.100.243]=admin:Cisco12345:22:neutronpluginsci:1/9)
 NCCLIENT_REPO=git://github.com/CiscoSystems/ncclient.git
 PHYSICAL_NETWORK=physnet1
 OVS_PHYSICAL_BRIDGE=br-eth1
 TENANT_VLAN_RANGE=810:819
 ENABLE_TENANT_VLANS=True
 API_RATE_LIMIT=False
 VERBOSE=True
 DEBUG=True
 LOGFILE=/opt/stack/logs/stack.sh.log
 USE_SCREEN=True
 SCREEN_LOGDIR=/opt/stack/logs

 Here are links to a log showing another localrc file that I use, and the
 corresponding stack.sh log:

 http://128.107.233.28:8080/job/neutron/1390/artifact/vpnaas_console_log.txt

 http://128.107.233.28:8080/job/neutron/1390/artifact/vpnaas_stack_sh_log.txt

 Does anyone have any advice on how to debug this, or recover from this
 (beyond rebooting the node)? Or am I missing any Cinder config?

 Thanks in advance for any help on this!!!
 Dane



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

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

Re: [openstack-dev] [OpenStack-Infra] tgt restart fails in Cinder startup start: job failed to start

[Sukhdev Kapur]

Hey Rafael,

If it helps any, I have noticed that this issue generally occurs after
several runs of tempest tests. I run all smoke tests. I have been always
suspicious that some new test got added which is not cleaning up
afterwards.  Can you point me to which tempest test corresponds to
test_boot_pattern? I can do some investigation as well.

Thanks
-Sukhdev



On Mon, Mar 10, 2014 at 10:10 AM, Rafael Folco rafaelfo...@gmail.comwrote:

 This looks very familiar
 https://bugzilla.redhat.com/show_bug.cgi?id=848942
 I'm not sure this is exactly the same bahavior, try turning debug messages
 on by adding -d to the tgtd start.
 I'm investigating a similar issue with tgt on test_boot_pattern test. It
 turns out that the file written to the volume in the first instance is not
 found by the second instance. But that's a separate issue.

 -rfolco


 On Mon, Mar 10, 2014 at 12:54 PM, Sukhdev Kapur sukhdevka...@gmail.comwrote:

 I see the same issue. This issue has crept in during the latest flurry of
 check-ins. I started noticing this issue a day or two before the Icehouse
 Feature Freeze deadline.

 I tried restarting tgt as well, but, it does not help.

 However, rebooting the VM helps clear it up.

 Has anybody else seen it as well? Does anybody have a solution for it?

 Thanks
 -Sukhdev





 On Mon, Mar 10, 2014 at 8:37 AM, Dane Leblanc (leblancd) 
 lebla...@cisco.com wrote:

 I don't know if anyone can give me some troubleshooting advice with this
 issue.

 I'm seeing an occasional problem whereby after several DevStack
 unstack.sh/stack.sh cycles, the tgt daemon (tgtd) fails to start during
 Cinder startup.  Here's a snippet from the stack.sh log:

 2014-03-10 07:09:45.214 | Starting Cinder
 2014-03-10 07:09:45.215 | + return 0
 2014-03-10 07:09:45.216 | + sudo rm -f /etc/tgt/conf.d/stack.conf
 2014-03-10 07:09:45.217 | + _configure_tgt_for_config_d
 2014-03-10 07:09:45.218 | + [[ ! -d /etc/tgt/stack.d/ ]]
 2014-03-10 07:09:45.219 | + is_ubuntu
 2014-03-10 07:09:45.220 | + [[ -z deb ]]
 2014-03-10 07:09:45.221 | + '[' deb = deb ']'
 2014-03-10 07:09:45.222 | + sudo service tgt restart
 2014-03-10 07:09:45.223 | stop: Unknown instance:
 2014-03-10 07:09:45.619 | start: Job failed to start
 jenkins@neutronpluginsci:~/devstack$ 2014-03-10 07:09:45.621 | +
 exit_trap
 2014-03-10 07:09:45.622 | + local r=1
 2014-03-10 07:09:45.623 | ++ jobs -p
 2014-03-10 07:09:45.624 | + jobs=
 2014-03-10 07:09:45.625 | + [[ -n '' ]]
 2014-03-10 07:09:45.626 | + exit 1

 If I try to restart tgt manually without success:

 jenkins@neutronpluginsci:~$ sudo service tgt restart
 stop: Unknown instance:
 start: Job failed to start
 jenkins@neutronpluginsci:~$ sudo tgtd
 librdmacm: couldn't read ABI version.
 librdmacm: assuming: 4
 CMA: unable to get RDMA device list
 (null): iser_ib_init(3263) Failed to initialize RDMA; load kernel
 modules?
 (null): fcoe_init(214) (null)
 (null): fcoe_create_interface(171) no interface specified.
 jenkins@neutronpluginsci:~$

 The config in /etc/tgt is:

 jenkins@neutronpluginsci:/etc/tgt$ ls -l
 total 8
 drwxr-xr-x 2 root root 4096 Mar 10 07:03 conf.d
 lrwxrwxrwx 1 root root   30 Mar 10 06:50 stack.d -
 /opt/stack/data/cinder/volumes
 -rw-r--r-- 1 root root   58 Mar 10 07:07 targets.conf
 jenkins@neutronpluginsci:/etc/tgt$ cat targets.conf
 include /etc/tgt/conf.d/*.conf
 include /etc/tgt/stack.d/*
 jenkins@neutronpluginsci:/etc/tgt$ ls conf.d
 jenkins@neutronpluginsci:/etc/tgt$ ls /opt/stack/data/cinder/volumes
 jenkins@neutronpluginsci:/etc/tgt$

 I don't know if there's any missing Cinder config in my DevStack localrc
 files. Here's one that I'm using:

 MYSQL_PASSWORD=nova
 RABBIT_PASSWORD=nova
 SERVICE_TOKEN=nova
 SERVICE_PASSWORD=nova
 ADMIN_PASSWORD=nova

 ENABLED_SERVICES=g-api,g-reg,key,n-api,n-crt,n-obj,n-cpu,n-cond,cinder,c-sch,c-api,c-vol,n-sch,n-novnc,n-xvnc,n-cauth,horizon,rabbit
 enable_service mysql
 disable_service n-net
 enable_service q-svc
 enable_service q-agt
 enable_service q-l3
 enable_service q-dhcp
 enable_service q-meta
 enable_service q-lbaas
 enable_service neutron
 enable_service tempest
 VOLUME_BACKING_FILE_SIZE=2052M
 Q_PLUGIN=cisco
 declare -a Q_CISCO_PLUGIN_SUBPLUGINS=(openvswitch nexus)
 declare -A
 Q_CISCO_PLUGIN_SWITCH_INFO=([10.0.100.243]=admin:Cisco12345:22:neutronpluginsci:1/9)
 NCCLIENT_REPO=git://github.com/CiscoSystems/ncclient.git
 PHYSICAL_NETWORK=physnet1
 OVS_PHYSICAL_BRIDGE=br-eth1
 TENANT_VLAN_RANGE=810:819
 ENABLE_TENANT_VLANS=True
 API_RATE_LIMIT=False
 VERBOSE=True
 DEBUG=True
 LOGFILE=/opt/stack/logs/stack.sh.log
 USE_SCREEN=True
 SCREEN_LOGDIR=/opt/stack/logs

 Here are links to a log showing another localrc file that I use, and the
 corresponding stack.sh log:


 http://128.107.233.28:8080/job/neutron/1390/artifact/vpnaas_console_log.txt

 http://128.107.233.28:8080/job/neutron/1390/artifact/vpnaas_stack_sh_log.txt

 Does anyone have any advice on how to debug this, or recover from this
 (beyond rebooting the node)? Or am I missing any

Re: [openstack-dev] [OpenStack-Infra] [Neutron][third-party-testing] Third Party Test setup and details

[Sukhdev Kapur]

On Wed, Feb 26, 2014 at 4:12 AM, trinath.soman...@freescale.com 
trinath.soman...@freescale.com wrote:

  Hi Sukhdev-



 Really a good document to go with.



 In the ‘System flow’ section of the document, where do this testRunner
 script come from ??


This is a very simple python script that we wrote - all it does it executes
the steps/actions described in the system flow.
As an example, here is one of the functions that it invokes to prepare for
testing.

def sanitize( nodeType, repoDict, branchDict, aristaConfig=None ):

   unstack()
   cleanstack()
   removeDevstack()
   downloadDevstack( branchDict )

   print Devstack downloaded
   serviceHost = 'localhost'
   if nodeType != TEMPEST_CONTROLLER:
  serviceHost = determineServiceHost( socket.gethostname() )

   if aristaConfig:
  generateAristaConfig( aristaConfig )

   generateLocalrc( nodeType, serviceHost, repoDict, branchDict,
aristaConfig )
   generateLocalConf()
   return stack()





 And the below actions are specified to be run with the testRunner script.



 Can you elaborate that part.



 Also, I’m looking into the document in a way to setup a CI. Will this help
 me in this regard.


Follow the steps on the link provided in the document to install Jenkin's
Gerrit plugin. Once you install Jenkins, just follow the configuration
steps I describe, including installing the modified gerrit plugin.. If you
have any issue, post it here, this will help me modify the document to make
it more useful for others to follow.

best of luck




 --

 Trinath Somanchi - B39208

 trinath.soman...@freescale.com | extn: 4048



 *From:* Sukhdev Kapur [mailto:sukhdevka...@gmail.com]
 *Sent:* Wednesday, February 26, 2014 3:39 AM

 *To:* openstack-in...@lists.openstack.org; OpenStack Development Mailing
 List (not for usage questions)
 *Subject:* [OpenStack-Infra] [Neutron][third-party-testing] Third Party
 Test setup and details



 Fellow developers,



 I just put together a wiki describing the Arista Third Party Setup.

 In the attached document we provide a link to the modified Gerrit Plugin
 to handle the regex matching for the Comment Added event so that
 recheck/reverify no bug/ can be handled.



 https://wiki.openstack.org/wiki/Arista-third-party-testing



 Have a look. Your feedback/comments will be appreciated.



 regards..

 -Sukhdev



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

[openstack-dev] [Neutron][third-party-testing] Third Party Test setup and details

[Sukhdev Kapur]

Fellow developers,

I just put together a wiki describing the Arista Third Party Setup.
In the attached document we provide a link to the modified Gerrit Plugin to
handle the regex matching for the Comment Added event so that
recheck/reverify no bug/ can be handled.

https://wiki.openstack.org/wiki/Arista-third-party-testing

Have a look. Your feedback/comments will be appreciated.

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

Re: [openstack-dev] [cinder][neutron][nova][3rd party testing] Gerrit Jenkins plugin will not fulfill requirements of 3rd party testing

[Sukhdev Kapur]

Folks,

I just sent out another email.

Here is the link to the wiki which has details about this patch.

https://wiki.openstack.org/wiki/Arista-third-party-testing

Hope this helps.

-Sukhdev




On Fri, Feb 14, 2014 at 6:01 PM, Sukhdev Kapur
sukh...@aristanetworks.comwrote:




 On Thu, Feb 13, 2014 at 12:39 PM, Jay Pipes jaypi...@gmail.com wrote:

 On Thu, 2014-02-13 at 12:34 -0800, Sukhdev Kapur wrote:
  Jay,
 
  Just an FYI. We have modified the Gerrit plugin it accept/match regex
  to generate notifications of for receck no bug/bug ###. It turned
  out to be very simple fix and we (Arista Testing) is now triggering on
  recheck comments as well.

 Thanks for the update, Sukhdev! Is this updated Gerrit plugin somewhere
 where other folks can use it?



 Yes the patch is ready.  I am documenting it as a part of overall
 description of Arista Testing Setup and will be releasing soon as part of
 the document that I am writing.
 Hopefully next week.

 regards..
 -Sukhdev





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

Re: [openstack-dev] [cinder][neutron][nova][3rd party testing] Gerrit Jenkins plugin will not fulfill requirements of 3rd party testing

[Sukhdev Kapur]

On Thu, Feb 13, 2014 at 12:39 PM, Jay Pipes jaypi...@gmail.com wrote:

 On Thu, 2014-02-13 at 12:34 -0800, Sukhdev Kapur wrote:
  Jay,
 
  Just an FYI. We have modified the Gerrit plugin it accept/match regex
  to generate notifications of for receck no bug/bug ###. It turned
  out to be very simple fix and we (Arista Testing) is now triggering on
  recheck comments as well.

 Thanks for the update, Sukhdev! Is this updated Gerrit plugin somewhere
 where other folks can use it?



Yes the patch is ready.  I am documenting it as a part of overall
description of Arista Testing Setup and will be releasing soon as part of
the document that I am writing.
Hopefully next week.

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

Re: [openstack-dev] [cinder][neutron][nova][3rd party testing] Gerrit Jenkins plugin will not fulfill requirements of 3rd party testing

[Sukhdev Kapur]

Jay,

Just an FYI. We have modified the Gerrit plugin it accept/match regex to
generate notifications of for receck no bug/bug ###. It turned out to be
very simple fix and we (Arista Testing) is now triggering on recheck
comments as well.

regards..
-Sukhdev



On Thu, Feb 6, 2014 at 4:16 PM, Sukhdev Kapur sukh...@aristanetworks.comwrote:

 Hi Jay,

 Thanks for bringing this up. I have been trying to make the recheck work
 and have not had much success. Therefore, I agree that we should go with
 option a) for the short term until b) or c) becomes available.
 I would prefer b) because we have already invested a lot in our solution
 and it is fully operational.

 Thanks
 -Sukhdev




 On Tue, Feb 4, 2014 at 3:55 PM, Jay Pipes jaypi...@gmail.com wrote:

 Sorry for cross-posting to both mailing lists, but there's lots of folks
 working on setting up third-party testing platforms that are not members
 of the openstack-infra ML...

 tl;dr
 -

 The third party testing documentation [1] has requirements [2] that
 include the ability to trigger a recheck based on a gerrit comment.

 Unfortunately, the Gerrit Jenkins Trigger plugin [3] does not have the
 ability to trigger job runs based on a regex-filtered comment (only on
 the existence of any new comment to the code review).

 Therefore, we either should:

 a) Relax the requirement that the third party system trigger test
 re-runs when a comment including the word recheck appears in the
 Gerrit event stream

 b) Modify the Jenkins Gerrit plugin to support regex filtering on the
 comment text (in the same way that it currently supports regex filtering
 on the project name)

 or

 c) Add documentation to the third party testing pages that explains how
 to use Zuul as a replacement for the Jenkins Gerrit plugin.

 I propose we do a) for the short term, and I'll work on c) long term.
 However, I'm throwing this out there just in case there are some Java
 and Jenkins whizzes out there that could get b) done in a jiffy.

 details
 ---

 OK, so I've been putting together documentation on how to set up an
 external Jenkins platform that is linked [4] with the upstream
 OpenStack CI system.

 Recently, I wrote an article detailing how the upstream CI system
 worked, including a lot of the gory details from the
 openstack-infra/config project's files. [5]

 I've been working on a follow-up article that goes through how to set up
 a Jenkins system, and in writing that article, I created a source
 repository [6] that contains scripts, instructions and Puppet modules
 that set up a Jenkins system, the Jenkins Job Builder tool, and
 installs/configures the Jenkins Gerrit plugin [7].

 I planned to use the Jenkins Gerrit plugin as the mechanism that
 triggers Jenkins jobs on the external system based on gerrit events
 published by the OpenStack review.openstack.org Gerrit service. In
 addition to being mentioned in the third party documentation, Jenkins
 Job Builder has the ability to construct Jenkins jobs that are triggered
 by the Jenkins Gerrit plugin [8].

 Unforunately, I've run into a bit of a snag.

 The third party testing documentation has requirements that include the
 ability to trigger a recheck based on a gerrit comment:

 quote
 Support recheck to request re-running a test.
  * Support the following syntaxes recheck no bug and recheck bug ###.
  * Recheck means recheck everything. A single recheck comment should
 re-trigger all testing systems.
 /quote

 The documentation has a section on using the Gerrit Jenkins Trigger
 plugin [3] to accept notifications from the upstream OpenStack Gerrit
 instance.

 But unfortunately, the Jenkins Gerrit plugin does not support the
 ability to trigger a re-run of a job given a regex match of the word
 recheck. :(

 So, we either need to a) change the requirements of third party testers,
 b) enhance the Jenkins Gerrit plugin with the missing functionality, or
 c) add documentation on how to set up Zuul as the triggering system
 instead of the Jenkins Gerrit plugin.

 I'm happy to work on c), but I think relaxing the restriction (a) is
 probably needed short-term.

 Best,
 -jay

 [1] http://ci.openstack.org/third_party.html
 [2] http://ci.openstack.org/third_party.html#requirements
 [3]

 http://ci.openstack.org/third_party.html#the-jenkins-gerrit-trigger-plugin-way
 [4] By linked I mean it both reads from the OpenStack Gerrit system
 and writes (adds comments) to it
 [5] http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/
 [6] http://github.com/jaypipes/os-ext-testing
 [7] https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger
 [8]

 https://github.com/openstack-infra/jenkins-job-builder/blob/master/jenkins_jobs/modules/triggers.py#L121




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

Re: [openstack-dev] [cinder][neutron][nova][3rd party testing] Gerrit Jenkins plugin will not fulfill requirements of 3rd party testing

[Sukhdev Kapur]

Hi Jay,

Thanks for bringing this up. I have been trying to make the recheck work
and have not had much success. Therefore, I agree that we should go with
option a) for the short term until b) or c) becomes available.
I would prefer b) because we have already invested a lot in our solution
and it is fully operational.

Thanks
-Sukhdev




On Tue, Feb 4, 2014 at 3:55 PM, Jay Pipes jaypi...@gmail.com wrote:

 Sorry for cross-posting to both mailing lists, but there's lots of folks
 working on setting up third-party testing platforms that are not members
 of the openstack-infra ML...

 tl;dr
 -

 The third party testing documentation [1] has requirements [2] that
 include the ability to trigger a recheck based on a gerrit comment.

 Unfortunately, the Gerrit Jenkins Trigger plugin [3] does not have the
 ability to trigger job runs based on a regex-filtered comment (only on
 the existence of any new comment to the code review).

 Therefore, we either should:

 a) Relax the requirement that the third party system trigger test
 re-runs when a comment including the word recheck appears in the
 Gerrit event stream

 b) Modify the Jenkins Gerrit plugin to support regex filtering on the
 comment text (in the same way that it currently supports regex filtering
 on the project name)

 or

 c) Add documentation to the third party testing pages that explains how
 to use Zuul as a replacement for the Jenkins Gerrit plugin.

 I propose we do a) for the short term, and I'll work on c) long term.
 However, I'm throwing this out there just in case there are some Java
 and Jenkins whizzes out there that could get b) done in a jiffy.

 details
 ---

 OK, so I've been putting together documentation on how to set up an
 external Jenkins platform that is linked [4] with the upstream
 OpenStack CI system.

 Recently, I wrote an article detailing how the upstream CI system
 worked, including a lot of the gory details from the
 openstack-infra/config project's files. [5]

 I've been working on a follow-up article that goes through how to set up
 a Jenkins system, and in writing that article, I created a source
 repository [6] that contains scripts, instructions and Puppet modules
 that set up a Jenkins system, the Jenkins Job Builder tool, and
 installs/configures the Jenkins Gerrit plugin [7].

 I planned to use the Jenkins Gerrit plugin as the mechanism that
 triggers Jenkins jobs on the external system based on gerrit events
 published by the OpenStack review.openstack.org Gerrit service. In
 addition to being mentioned in the third party documentation, Jenkins
 Job Builder has the ability to construct Jenkins jobs that are triggered
 by the Jenkins Gerrit plugin [8].

 Unforunately, I've run into a bit of a snag.

 The third party testing documentation has requirements that include the
 ability to trigger a recheck based on a gerrit comment:

 quote
 Support recheck to request re-running a test.
  * Support the following syntaxes recheck no bug and recheck bug ###.
  * Recheck means recheck everything. A single recheck comment should
 re-trigger all testing systems.
 /quote

 The documentation has a section on using the Gerrit Jenkins Trigger
 plugin [3] to accept notifications from the upstream OpenStack Gerrit
 instance.

 But unfortunately, the Jenkins Gerrit plugin does not support the
 ability to trigger a re-run of a job given a regex match of the word
 recheck. :(

 So, we either need to a) change the requirements of third party testers,
 b) enhance the Jenkins Gerrit plugin with the missing functionality, or
 c) add documentation on how to set up Zuul as the triggering system
 instead of the Jenkins Gerrit plugin.

 I'm happy to work on c), but I think relaxing the restriction (a) is
 probably needed short-term.

 Best,
 -jay

 [1] http://ci.openstack.org/third_party.html
 [2] http://ci.openstack.org/third_party.html#requirements
 [3]

 http://ci.openstack.org/third_party.html#the-jenkins-gerrit-trigger-plugin-way
 [4] By linked I mean it both reads from the OpenStack Gerrit system
 and writes (adds comments) to it
 [5] http://www.joinfu.com/2014/01/understanding-the-openstack-ci-system/
 [6] http://github.com/jaypipes/os-ext-testing
 [7] https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger
 [8]

 https://github.com/openstack-infra/jenkins-job-builder/blob/master/jenkins_jobs/modules/triggers.py#L121



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

[openstack-dev] [oepnstack-dev][Neutron] Neutron API behavior

[Sukhdev Kapur]

Hi All,

During tempest sprint in Montreal, as we were writing API tests, we noticed
a behavior which we believed is an issue with the Neutron API (or perhaps
documentation or both)

Let me start with a question:

If one executes an api to create/delete/update a neutron resource, what is
the API's contract with the user? In other words, if a user gets a response
code 204 for a delete operation or 201 for create operation - should they
assume that the operation is successfully completed?

Based upon the API document, the answer seems to be YES.
Based upon the behavior answer seems to be MAYBE - what does this mean?
It simply means that Neutron DB has been updated, but, the back-ends may
not have completed the operation.

This means, as an example, if a create operation is performed on a same
resource immediately after it has been successfully deleted (i.e. 204
returned), there is a possibility that create operation may fail.

If the tests (or real life applications) are not written carefully, there
is a possibility of intermittent failures, and they will become very
apparent in a stress type situations.

We discussed this with some of Neutron core developers who were present in
the room and they shared their wisdom on the subject. We decided that we
put this out on the mailing list for the benefit of wider audience - and,
hence the motivation of this email.

Are there any plans to address or document this?

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

Re: [openstack-dev] [Neutron][qa]API testing update

[Sukhdev Kapur]

Sounds good.
Thanks for clarification.

-Sukhdev



On Fri, Jan 10, 2014 at 7:24 AM, Miguel Lavalle mig...@mlavalle.com wrote:

 Sukhdev,

 Thanks for your comment. Eugene summarized very well the reason I didin't
 specify any testing dealing with the ml2 plugin. It

 Cheers


 On Thu, Jan 9, 2014 at 11:50 PM, Eugene Nikanorov enikano...@mirantis.com
  wrote:

 Sukhdev,

 API tests are really not for end-to-end testing; also, tempest tests
 (both API and scenario) should not make any
 assumptions about neutron configuration (e.g. ml2 mechanism drivers).
 End-to-end testing for particular ml2 drivers seems to fit in 3rd party
 testing
 where you can run additional tests which are configuration-specific.

 Thanks,
 Eugene.


 On Wed, Jan 8, 2014 at 4:36 AM, Sukhdev Kapur sukhdevka...@gmail.comwrote:

 Hi Miguel,

 As I am using neutron API tempest tests, I notice that in the
 create_port tests, the port context is set partially - i.e. only network Id
 is available.
 ML2 drivers expect more in formation in the port context in order to
 test the API on the back-ends.

 I noticed such an enhancement is not listed in the etherpad.
 This is really not a new test, but, enhancement of the test coverage to
 allow third party ML2 drivers to perform end-to-end API testing.

 If you like, I will be happy to update the ehterpad to include this
 information.

 regards..
 -Sukhdev




 On Mon, Jan 6, 2014 at 10:37 AM, Miguel Lavalle mig...@mlavalle.comwrote:

 As described in a previous message, the community is focusing efforts
 in developing a comprehensive set of API tests in Tempest for Neutron. We
 are keeping track of this effort in the API tests gap analysis section at
 https://etherpad.openstack.org/p/icehouse-summit-qa-neutron

 These are recent developments in this regard:

 1) The gap analysis is complete as of January 5th. The analysis takes
 into consideration what already exists in Tempest and what is in the Gerrit
 review process
 2) Soon there is going to be a generative (i.e. non manual) tool to
 create negative tests in Tempest. As a consequence, all negative tests
 specifications were removed from the gap analysis described in the previous
 point

 If you are interested in helping in this effort, please go to the
 etherpad indicated above and select from the API tests gap analysis
 section the tests you want to contribute. Please put your name and email
 address next to the selected tests. Also, when your code merges, please
 come back to the etherpad and update it indicating that your test is done.

 If your are new to OpenStack, Neutron or Tempest, implementing tests is
 an excellent way to learn an API. We have put together the following guide
 to help you get started
 https://wiki.openstack.org/wiki/Neutron/TempestAPITests



 ___
 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


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

Re: [openstack-dev] [Neutron][qa] Intermittent failure of tempest test test_network_basic_ops

[Sukhdev Kapur]

Thanks Salvatore and Jay for sharing your experiences on this issue.

I will look through the references you have provided to understand further
as well.
If I  latch onto something, I will share back.

BTW, before posting the question here, I did suspect some race conditions
and tried to play around with the timings of some of events - nothing
really helped :-(


regards..
-Sukhdev



On Thu, Jan 9, 2014 at 10:38 AM, Salvatore Orlando sorla...@nicira.comwrote:

 Hi Jay,

 replies inline.
 I have probably have found one more cause for this issue in the logs, and
 I have added a comment to the bug report.

 Salvatore


 On 9 January 2014 19:10, Jay Pipes jaypi...@gmail.com wrote:

 On Thu, 2014-01-09 at 09:09 +0100, Salvatore Orlando wrote:
  I am afraid I need to correct you Jay!

 I always welcome corrections to things I've gotten wrong, so no worries
 at all!

  This actually appears to be bug 1253896 [1]

 Ah, the infamous SSH bug :) Yeah, so last night I spent a few hours
 digging through log files and running a variety of e-r queries trying to
 find some patterns for the bugs that Joe G had sent an ML post about.

 I went round in circles, unfortunately :( When I thought I'd found a
 pattern, invariably I would doubt my initial findings and wander into
 new areas in a wild goose chase.


 that's pretty much what I do all the time.


 At various times, I thought something was up with the DHCP agent, as
 there were lots of No DHCP Agent found errors in the q-dhcp screen
 logs. But I could not correlate any relationship with the failures in
 the 4 bugs.


 I've seen those warning as well. They are pretty common, and I think they
 are actually benign, as the DHCP for the network is configured
 asynchronously, it is probably normal to see that message.
 78


 Then I started thinking that there was a timing/race condition where a
 security group was being added to the Nova-side servers cache before it
 had actually been constructed fully on the Neutron-side. But I was not
 able to fully track down the many, many debug messages that are involved
 in the full sequence of VM launch :( At around 4am, I gave up and went
 to bed...


 I have not investigated how this could impact connectivity. However, one
 thing that it's not ok in my opinion is that we have no way to know whether
 a security group is enforced or not; I think it needs an 'operational
 status'.
 Note: we're working on a patch for the nicira plugin to add this concept;
 it's currently being developed as a plugin-specific extension, but if there
 is interest to support the concept also in the ml2 plugin I think we can
 just make it part of the 'core' security group API.


  Technically, what we call 'bug' here is actually a failure
  manifestation.
  So far, we have removed several bugs causing this failure. The last
  patch was pushed to devstack around Christmas.
  Nevertheless, if you look at recent comments and Joe's email, we still
  have a non-negligible failure rate on the gate.

 Understood. I suspect actually that some of the various performance
 improvements from Phil Day and others around optimizing certain server
 and secgroup list calls have made the underlying race conditions show up
 more often -- since the list calls are completing much faster, which
 ironically gives Neutron less time to complete setup operations!


 That might be one explanation. The other might be the fact that we added
 another scenario test for neutron which creates more vms with floating ips
 and stuff, thus increasing the chances of hitting the timeout failure.


 So, a performance patch on the Nova side ends up putting more pressure
 on the Neutron side, which causes the rate of occurrence for these
 sticky bugs (with potentially many root causes) to spike.

 Such is life I guess :)

  It is also worth mentioning that if you are running your tests with
  parallelism enabled (ie: you're running tempest with tox -esmoke
  rather than tox -esmokeserial) you will end up with a higher
  occurrence of this failure due to more bugs causing it. These bugs are
  due to some weakness in the OVS agent that we are addressing with
  patches for blueprint neutron-tempest-parallel [2].

 Interesting. If you wouldn't mind, what makes you think this is a
 weakness in the OVS agent? I would certainly appreciate your expertise
 in this area, since it would help me in my own bug-searching endeavors.


 Basically those are all the patches addressing the linked blueprint; I
 have added more info in the commit messages for the patches.
 Also some of those patches target this bug as well:
 https://bugs.launchpad.net/neutron/+bug/1253993


 All the best,
 -jay

  Regards,
  Salvatore
 
 
 
 
  [1] https://bugs.launchpad.net/neutron/+bug/1253896
  [2]
 https://blueprints.launchpad.net/neutron/+spec/neutron-tempest-parallel
 
 
  On 9 January 2014 05:38, Jay Pipes jaypi...@gmail.com wrote:
  On Wed, 2014-01-08 at 18:46 -0800, Sukhdev Kapur wrote:
   Dear fellow