[openstack-dev] [neutron] [third-party] Cisco NXOS is not tested anymore

[Edgar Magana]

Cisco Folks,

I don't see the CI for Cisco NX-OS anymore. Is this being deprecated?

Edgar
___
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] Cisco NXOS is not tested anymore

[Edgar Magana]

If this plugin will be deprecated in Juno it means that the code will be
there for this release, I will expect to have the CI still running for
until the code is completely removed from the Neutron tree.

Anyway, Infra guys will have the last word here!

Edgar

On 8/11/14, 5:38 PM, "Anita Kuno"  wrote:

>On 08/11/2014 06:31 PM, Henry Gessau wrote:
>> On 8/11/2014 7:56 PM, Anita Kuno wrote:
>>> On 08/11/2014 05:46 PM, Henry Gessau wrote:
>>>> Anita Kuno  wrote:
>>>>> On 08/11/2014 05:05 PM, Edgar Magana wrote:
>>>>>> Cisco Folks,
>>>>>>
>>>>>> I don't see the CI for Cisco NX-OS anymore. Is this being
>>>>>>deprecated?
>>>>>>
>>>>> I don't ever recall seeing that as a name of a third party gerrit
>>>>> account in my list[0], Edgar.
>>>>>
>>>>> Do you happen to have a link to a patchset that has that name
>>>>>attached
>>>>> to a comment?
>>>>
>>>> The "Cisco Neutron CI" tests at least five different configurations.
>>>>By
>>>> "NX-OS" Edgar is referring to the Cisco Nexus switch configurations.
>>>>The CI
>>>> used to run both the "monolithic_nexus" and "ml2_nexus"
>>>>configurations, but
>>>> the monolithic cisco plugin for nexus is being deprecated for juno
>>>>and its
>>>> configuration has already been removed from testing.
>>>>
>>> Thanks Henry:
>>>
>>> Do we have a url for patch in gerrit for this or was this an internal
>>> code change?
>> 
>> This was a change only in the internal 3rd party Jenkins/Zuul settings.
>> 
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> 
>Okay.
>
>Perhaps going forward this could be an item for the third party meeting
>under the topic of Deadlines & Deprecations:
>https://wiki.openstack.org/wiki/Meetings/ThirdParty Then at the very
>least if someone missed the announcement we could have a log of it and
>point someone to the conversation.
>
>Thanks Henry,
>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] [third-party] Cisco NXOS is not tested anymore

[Edgar Magana]

Henry,

That makes a lot of sense to me.
If the code will be remove in Juno, then there is nothing else to discuss.

Thank you so much for providing detailed information and sorry for
bothering you with this issue.

Edgar

On 8/12/14, 11:49 AM, "Henry Gessau"  wrote:

>On 8/12/2014 2:04 PM, Jeremy Stanley wrote:
>> On 2014-08-12 16:35:18 +0000 (+), Edgar Magana wrote:
>>> If this plugin will be deprecated in Juno it means that the code
>>> will be there for this release, I will expect to have the CI still
>>> running for until the code is completely removed from the Neutron
>>> tree.
>>>
>>> Anyway, Infra guys will have the last word here!
>> 
>> It's really not up to the Project Infrastructure Team to decide
>> this (we merely provide guidance, assistance and, sometimes,
>> arbitration for such matters). It's ultimately the Neutron developer
>> community who needs to determine whether they're willing to support
>> an untested feature through deprecation or insist on continued
>> testing until its full removal can be realized.
>
>The Cisco Nexus sub-plugin is broken because the OVS plugin that is
>depends on
>is broken. The Neutron Project switched from the OVS plugin to ML2 for
>testing
>a long time ago, and the OVS plugin will be removed from the tree in Juno.
>There are no plans to fix the OVS plugin, so the Cisco Nexus sub-plugin
>will
>not be fixed either.
>
>There are bugs[1,2] open to remove the deprecated plugins from the tree.
>
>[1] https://bugs.launchpad.net/neutron/+bug/1323729
>[2] https://bugs.launchpad.net/neutron/+bug/1350387
>
>
>___
>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] Rotating the weekly Neutron meeting

[Edgar Magana]

Go for it commander!

Edgar

On 8/13/14, 7:05 AM, "Kyle Mestery"  wrote:

>Per this week's Neutron meeting [1], it was decided that offering a
>rotating meeting slot for the weekly Neutron meeting would be a good
>thing. This will allow for a much easier time for people in
>Asia/Pacific timezones, as well as for people in Europe.
>
>So, I'd like to propose we rotate the weekly as follows:
>
>Monday 2100UTC
>Tuesday 1400UTC
>
>If people are ok with these time slots, I'll set this up and we'll
>likely start with this new schedule in September, after the FPF.
>
>Thanks!
>Kyle
>
>[1] 
>http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-08
>-11-21.00.html
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

[Edgar Magana]

Team,

I did a quick audit on the Neutron CI. Very sad results. Only few plugins
and drivers are running properly and testing all Neutron commits.
I created a report here:
https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugin
_and_Drivers


We will discuss the actions to take on the next Neutron IRC meeting. So
please, reach me out to clarify what is the status of your CI.
I had two commits to quickly verify the CI reliability:

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

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


I would expect all plugins and drivers passing on the first one and
failing for the second but I got so many surprises.

Neutron code quality and reliability is a top priority, if you ignore this
report that plugin/driver will be candidate to be remove from Neutron tree.

Cheers,

Edgar

P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty job!


On 8/14/14, 8:30 AM, "Kyle Mestery"  wrote:

>Folks, I'm not sure if all CI accounts are running sufficient tests.
>Per the requirements wiki page here [1], everyone needs to be running
>more than just Tempest API tests, which I still see most neutron
>third-party CI setups doing. I'd like to ask everyone who operates a
>third-party CI account for Neutron to please look at the link below
>and make sure you are running appropriate tests. If you have
>questions, the weekly third-party meeting [2] is a great place to ask
>questions.
>
>Thanks,
>Kyle
>
>[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
>[2] 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] [third-party] What tests are required to be run

[Edgar Magana]

Correction

The right links are:

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

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


Not this one:
https://review.openstack.org/#/c/40296/


Edgar

On 8/15/14, 3:35 PM, "Edgar Magana"  wrote:

>Team,
>
>I did a quick audit on the Neutron CI. Very sad results. Only few plugins
>and drivers are running properly and testing all Neutron commits.
>I created a report here:
>https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugi
>n
>_and_Drivers
>
>
>We will discuss the actions to take on the next Neutron IRC meeting. So
>please, reach me out to clarify what is the status of your CI.
>I had two commits to quickly verify the CI reliability:
>
>https://review.openstack.org/#/c/114393/
>
>https://review.openstack.org/#/c/40296/
>
>
>I would expect all plugins and drivers passing on the first one and
>failing for the second but I got so many surprises.
>
>Neutron code quality and reliability is a top priority, if you ignore this
>report that plugin/driver will be candidate to be remove from Neutron
>tree.
>
>Cheers,
>
>Edgar
>
>P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty
>job!
>
>
>On 8/14/14, 8:30 AM, "Kyle Mestery"  wrote:
>
>>Folks, I'm not sure if all CI accounts are running sufficient tests.
>>Per the requirements wiki page here [1], everyone needs to be running
>>more than just Tempest API tests, which I still see most neutron
>>third-party CI setups doing. I'd like to ask everyone who operates a
>>third-party CI account for Neutron to please look at the link below
>>and make sure you are running appropriate tests. If you have
>>questions, the weekly third-party meeting [2] is a great place to ask
>>questions.
>>
>>Thanks,
>>Kyle
>>
>>[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
>>[2] 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] [third-party] What tests are required to be run

[Edgar Magana]

Ivar,

Very valid point. This is why I need clarification from those CI owner.
I will run a new test with a basic change in the Neutron DB code. That should 
be covered by almost all CI systems.

Edgar

From: Ivar Lazzaro mailto:ivarlazz...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, August 15, 2014 at 3:47 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

Hi Edgar,

Nice shot, to be the inquisitor is not necessarily a bad thing :)

I know some CIs are 'stuck' waiting for bugs to be fixed or certain patches to 
be merged, but I was wondering if it is a requirement that CIs vote *ALL* the 
Neutron patches. Some may have missed your call just because of their filters 
(see [0] section 'what changes to run against').

Cheers,
Ivar.

[0] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting




On Sat, Aug 16, 2014 at 12:35 AM, Edgar Magana 
mailto:edgar.mag...@workday.com>> wrote:
Team,

I did a quick audit on the Neutron CI. Very sad results. Only few plugins
and drivers are running properly and testing all Neutron commits.
I created a report here:
https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugin
_and_Drivers


We will discuss the actions to take on the next Neutron IRC meeting. So
please, reach me out to clarify what is the status of your CI.
I had two commits to quickly verify the CI reliability:

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

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


I would expect all plugins and drivers passing on the first one and
failing for the second but I got so many surprises.

Neutron code quality and reliability is a top priority, if you ignore this
report that plugin/driver will be candidate to be remove from Neutron tree.

Cheers,

Edgar

P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty job!


On 8/14/14, 8:30 AM, "Kyle Mestery" 
mailto:mest...@mestery.com>> wrote:

>Folks, I'm not sure if all CI accounts are running sufficient tests.
>Per the requirements wiki page here [1], everyone needs to be running
>more than just Tempest API tests, which I still see most neutron
>third-party CI setups doing. I'd like to ask everyone who operates a
>third-party CI account for Neutron to please look at the link below
>and make sure you are running appropriate tests. If you have
>questions, the weekly third-party meeting [2] is a great place to ask
>questions.
>
>Thanks,
>Kyle
>
>[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
>[2] https://wiki.openstack.org/wiki/Meetings/ThirdParty
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto: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] What tests are required to be run

[Edgar Magana]

Neutron Ci Folks,

I have received answers from almost all the CI contacts and I want to
thank you all.
Every case is different and I will review each one of your answer and
questions.

I do understand that every CI is different and this is why I would suggest
two things:

1) Today's Neutron IRC meeting we can discuss the current status and what
we want to achieve by the end of Juno release.
2) Have a short session during the Kilo summit to have an agreement on the
requirements for the plugins and drivers under Neutron tree.

I will answer each one of you and again I thank you all for your responses.

Thanks,

Edgar


On 8/15/14, 3:35 PM, "Edgar Magana"  wrote:

>Team,
>
>I did a quick audit on the Neutron CI. Very sad results. Only few plugins
>and drivers are running properly and testing all Neutron commits.
>I created a report here:
>https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugi
>n
>_and_Drivers
>
>
>We will discuss the actions to take on the next Neutron IRC meeting. So
>please, reach me out to clarify what is the status of your CI.
>I had two commits to quickly verify the CI reliability:
>
>https://review.openstack.org/#/c/114393/
>
>https://review.openstack.org/#/c/40296/
>
>
>I would expect all plugins and drivers passing on the first one and
>failing for the second but I got so many surprises.
>
>Neutron code quality and reliability is a top priority, if you ignore this
>report that plugin/driver will be candidate to be remove from Neutron
>tree.
>
>Cheers,
>
>Edgar
>
>P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty
>job!
>
>
>On 8/14/14, 8:30 AM, "Kyle Mestery"  wrote:
>
>>Folks, I'm not sure if all CI accounts are running sufficient tests.
>>Per the requirements wiki page here [1], everyone needs to be running
>>more than just Tempest API tests, which I still see most neutron
>>third-party CI setups doing. I'd like to ask everyone who operates a
>>third-party CI account for Neutron to please look at the link below
>>and make sure you are running appropriate tests. If you have
>>questions, the weekly third-party meeting [2] is a great place to ask
>>questions.
>>
>>Thanks,
>>Kyle
>>
>>[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
>>[2] 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] [third-party] What tests are required to be run

[Edgar Magana]

Thank you Akihiro.

I will propose a better organization for this section. Stay tune!

Edgar

On 8/17/14, 10:53 PM, "Akihiro Motoki"  wrote:

>
>On 2014/08/18 0:12, Kyle Mestery wrote:
>> On Fri, Aug 15, 2014 at 5:35 PM, Edgar Magana
>> wrote:
>>> Team,
>>>
>>> I did a quick audit on the Neutron CI. Very sad results. Only few
>>>plugins
>>> and drivers are running properly and testing all Neutron commits.
>>> I created a report here:
>>> 
>>>https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plu
>>>gin
>>> _and_Drivers
>>>
>> Can you link this and/or move it to this page:
>>
>> https://wiki.openstack.org/wiki/NeutronPlugins
>>
>> This is under the "NeutronPolicies" wiki page which I did at the start
>> of Juno. This tracks all policies and procedures for Neutron, and
>> there's a Plugins page (which I linked to above) where this should
>> land.
>
>I just added the link Neutron_Plugins_and_Drivers#Existing_Plugin
>to NeutronPlugins wiki.
>
>The wiki pages NeutronPlugins and Neutron_Plugins_and_Drivers
>cover the similar contents. According to the history of the page,
>the latter one was created by Mark at Nov 2013 (beginning of Icehouse
>cycle).
>It seems better to merge these two pages to avoid the confusion.
>
>Akihiro
>
>>
>>>
>>> We will discuss the actions to take on the next Neutron IRC meeting. So
>>> please, reach me out to clarify what is the status of your CI.
>>> I had two commits to quickly verify the CI reliability:
>>>
>>> https://review.openstack.org/#/c/114393/
>>>
>>> https://review.openstack.org/#/c/40296/
>>>
>>>
>>> I would expect all plugins and drivers passing on the first one and
>>> failing for the second but I got so many surprises.
>>>
>>> Neutron code quality and reliability is a top priority, if you ignore
>>>this
>>> report that plugin/driver will be candidate to be remove from Neutron
>>>tree.
>>>
>>> Cheers,
>>>
>>> Edgar
>>>
>>> P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty
>>>job!
>>>
>> Thanks for sending this out Edgar and doing this analysis! Can you
>> please put an agenda item on Monday's meeting to discuss this? I won't
>> be at the meeting as I'm on PTO (Mark is running the meeting in my
>> absence), but I'd like the team to discuss this and allow all
>> third-party people a chance to be there and share their feelings here.
>>
>> Thanks,
>> Kyle
>>
>>>
>>> On 8/14/14, 8:30 AM, "Kyle Mestery"  wrote:
>>>
>>>> Folks, I'm not sure if all CI accounts are running sufficient tests.
>>>> Per the requirements wiki page here [1], everyone needs to be running
>>>> more than just Tempest API tests, which I still see most neutron
>>>> third-party CI setups doing. I'd like to ask everyone who operates a
>>>> third-party CI account for Neutron to please look at the link below
>>>> and make sure you are running appropriate tests. If you have
>>>> questions, the weekly third-party meeting [2] is a great place to ask
>>>> questions.
>>>>
>>>> Thanks,
>>>> Kyle
>>>>
>>>> [1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
>>>> [2] 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
>>
>> ___
>> 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] [third-party] What tests are required to be run

[Edgar Magana]

Hello Folks,

Based on today’s Neutron IRC meeting. I have modified the following wiki: 
https://wiki.openstack.org/wiki/NeutronThirdPartyTesting

You will find a new suction with the minimal requirements for Juno. If you have 
still some questions, please contact me directly.

I will start contacting each one of the owner directly and will update the 
table with the current Plugins and Drivers:
https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers

Kind Regards,

Edgar

From: Hemanth Ravi mailto:hemanthrav...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, August 18, 2014 at 12:24 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>, 
Kedar K 
mailto:kedar.kulka...@oneconvergence.com>>, 
Deepak Gupta 
mailto:deepak.gu...@oneconvergence.com>>
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

Edgar,

Our CI is running the tests (non voting), but don't see it listed on the review 
for any patch. Is this due to missing logs? I would like to confirm this is the 
issue, will resolve this.

Thanks,
-hemanth


On Mon, Aug 18, 2014 at 8:35 AM, Edgar Magana 
mailto:edgar.mag...@workday.com>> wrote:
Thank you Akihiro.

I will propose a better organization for this section. Stay tune!

Edgar

On 8/17/14, 10:53 PM, "Akihiro Motoki" 
mailto:mot...@da.jp.nec.com>> wrote:

>
>On 2014/08/18 0:12, Kyle Mestery wrote:
>> On Fri, Aug 15, 2014 at 5:35 PM, Edgar Magana
>>mailto:edgar.mag...@workday.com>> wrote:
>>> Team,
>>>
>>> I did a quick audit on the Neutron CI. Very sad results. Only few
>>>plugins
>>> and drivers are running properly and testing all Neutron commits.
>>> I created a report here:
>>>
>>>https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plu
>>>gin
>>> _and_Drivers
>>>
>> Can you link this and/or move it to this page:
>>
>> https://wiki.openstack.org/wiki/NeutronPlugins
>>
>> This is under the "NeutronPolicies" wiki page which I did at the start
>> of Juno. This tracks all policies and procedures for Neutron, and
>> there's a Plugins page (which I linked to above) where this should
>> land.
>
>I just added the link Neutron_Plugins_and_Drivers#Existing_Plugin
>to NeutronPlugins wiki.
>
>The wiki pages NeutronPlugins and Neutron_Plugins_and_Drivers
>cover the similar contents. According to the history of the page,
>the latter one was created by Mark at Nov 2013 (beginning of Icehouse
>cycle).
>It seems better to merge these two pages to avoid the confusion.
>
>Akihiro
>
>>
>>>
>>> We will discuss the actions to take on the next Neutron IRC meeting. So
>>> please, reach me out to clarify what is the status of your CI.
>>> I had two commits to quickly verify the CI reliability:
>>>
>>> https://review.openstack.org/#/c/114393/
>>>
>>> https://review.openstack.org/#/c/40296/
>>>
>>>
>>> I would expect all plugins and drivers passing on the first one and
>>> failing for the second but I got so many surprises.
>>>
>>> Neutron code quality and reliability is a top priority, if you ignore
>>>this
>>> report that plugin/driver will be candidate to be remove from Neutron
>>>tree.
>>>
>>> Cheers,
>>>
>>> Edgar
>>>
>>> P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty
>>>job!
>>>
>> Thanks for sending this out Edgar and doing this analysis! Can you
>> please put an agenda item on Monday's meeting to discuss this? I won't
>> be at the meeting as I'm on PTO (Mark is running the meeting in my
>> absence), but I'd like the team to discuss this and allow all
>> third-party people a chance to be there and share their feelings here.
>>
>> Thanks,
>> Kyle
>>
>>>
>>> On 8/14/14, 8:30 AM, "Kyle Mestery" 
>>> mailto:mest...@mestery.com>> wrote:
>>>
>>>> Folks, I'm not sure if all CI accounts are running sufficient tests.
>>>> Per the requirements wiki page here [1], everyone needs to be running
>>>> more than just Tempest API tests, which I still see most neutron
>>>> third-party CI setups doing. I'd like to ask everyone who operates a
>>>> third-party CI account for Neutron to please look at the link below
>>>> and make sure you are running appropriate tests. If you 

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

[Edgar Magana]

Salvatore,

Thank you for your input. I actually took your suggestion about the area to 
cover for the CI systems and I updated the wiki page for the third party 
testing in Neutron.
https://wiki.openstack.org/wiki/NeutronThirdPartyTesting

Cheers,

Edgar

From: Salvatore Orlando mailto:sorla...@nicira.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, August 15, 2014 at 4:11 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

VMware minesweeper has filters which have been designed to cover the largest 
possible subset of submissions without add unnecessary load to our scarce 
resources for CI validation. This is probably why the analysis reveals not all 
patches are covered.

Therefore our filters exclude neutral changes such as those in README.rst 
(they're unlikely to crash neutron are they?), or changes in wsgi.py. The 
latter is because the wsgi framework is shared with all plugins, and when it 
breaks the NSX plugin it's very likely upstream tests will break too.

I think the areas which are important to cover are:
- neutron/agents/.* (or at least the agents you use)
- neutron/openstack/common/.*
- neutron/notifiers/.* (if your drivers report vif plugging events to nova)
- neutron/db/.*
- neutron/services/${thepluginsyouruninyourci_eveniftheyrenotyours}
- your plugin patch

Salvatore

PS: Openstack proposal bot submission's checks have been suspended for vmware 
minesweeper about 2 days ago. They will resume soon.


On 16 August 2014 01:02, Edgar Magana 
mailto:edgar.mag...@workday.com>> wrote:
Ivar,

Very valid point. This is why I need clarification from those CI owner.
I will run a new test with a basic change in the Neutron DB code. That should 
be covered by almost all CI systems.

Edgar

From: Ivar Lazzaro mailto:ivarlazz...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, August 15, 2014 at 3:47 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

Hi Edgar,

Nice shot, to be the inquisitor is not necessarily a bad thing :)

I know some CIs are 'stuck' waiting for bugs to be fixed or certain patches to 
be merged, but I was wondering if it is a requirement that CIs vote *ALL* the 
Neutron patches. Some may have missed your call just because of their filters 
(see [0] section 'what changes to run against').

Cheers,
Ivar.

[0] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting




On Sat, Aug 16, 2014 at 12:35 AM, Edgar Magana 
mailto:edgar.mag...@workday.com>> wrote:
Team,

I did a quick audit on the Neutron CI. Very sad results. Only few plugins
and drivers are running properly and testing all Neutron commits.
I created a report here:
https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugin
_and_Drivers


We will discuss the actions to take on the next Neutron IRC meeting. So
please, reach me out to clarify what is the status of your CI.
I had two commits to quickly verify the CI reliability:

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

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


I would expect all plugins and drivers passing on the first one and
failing for the second but I got so many surprises.

Neutron code quality and reliability is a top priority, if you ignore this
report that plugin/driver will be candidate to be remove from Neutron tree.

Cheers,

Edgar

P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty job!


On 8/14/14, 8:30 AM, "Kyle Mestery" 
mailto:mest...@mestery.com>> wrote:

>Folks, I'm not sure if all CI accounts are running sufficient tests.
>Per the requirements wiki page here [1], everyone needs to be running
>more than just Tempest API tests, which I still see most neutron
>third-party CI setups doing. I'd like to ask everyone who operates a
>third-party CI account for Neutron to please look at the link below
>and make sure you are running appropriate tests. If you have
>questions, the weekly third-party meeting [2] is a great place to ask
>questions.
>
>Thanks,
>Kyle
>
>[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
>[2] https://wiki.openstack.org/wiki/Meetings/ThirdParty
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

[Edgar Magana]

Parikshit,

I will add your information right now.

Thanks,

Edgar

On 8/19/14, 4:11 AM, "Parikshit Manur"  wrote:

>Hi Edgar,
>   NetScaler CI is not listed in the report. NetScaler CI up and running
>and it is voting for patchsets which contains LBaaS changes, that's why
>you did not see it voting for the test change ref.
>   Also, you can add me as a contact person and alias
>networking-cloudinteg...@citrix.com as email contact point for the
>NetScaler CI.  
>
> Please let me know if you have any questions.
>
>Thanks,
>Parikshit Manur
>
>-Original Message-
>From: Edgar Magana [mailto:edgar.mag...@workday.com]
>Sent: Saturday, 16 August 2014 4:06 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>required to be run
>Importance: High
>
>Team,
>
>I did a quick audit on the Neutron CI. Very sad results. Only few plugins
>and drivers are running properly and testing all Neutron commits.
>I created a report here:
>https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugi
>n
>_and_Drivers
>
>
>We will discuss the actions to take on the next Neutron IRC meeting. So
>please, reach me out to clarify what is the status of your CI.
>I had two commits to quickly verify the CI reliability:
>
>https://review.openstack.org/#/c/114393/
>
>https://review.openstack.org/#/c/40296/
>
>
>I would expect all plugins and drivers passing on the first one and
>failing for the second but I got so many surprises.
>
>Neutron code quality and reliability is a top priority, if you ignore
>this report that plugin/driver will be candidate to be remove from
>Neutron tree.
>
>Cheers,
>
>Edgar
>
>P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty
>job!
>
>
>On 8/14/14, 8:30 AM, "Kyle Mestery"  wrote:
>
>>Folks, I'm not sure if all CI accounts are running sufficient tests.
>>Per the requirements wiki page here [1], everyone needs to be running
>>more than just Tempest API tests, which I still see most neutron
>>third-party CI setups doing. I'd like to ask everyone who operates a
>>third-party CI account for Neutron to please look at the link below and
>>make sure you are running appropriate tests. If you have questions, the
>>weekly third-party meeting [2] is a great place to ask questions.
>>
>>Thanks,
>>Kyle
>>
>>[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
>>[2] 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
>
>___
>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] What tests are required to be run

[Edgar Magana]

Hemanth,

What is your system reference name?
Please, provide me a link to the latest tempest logs.

Thanks,

Edgar

From: Hemanth Ravi mailto:hemanthrav...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, August 18, 2014 at 12:24 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>, 
Kedar K 
mailto:kedar.kulka...@oneconvergence.com>>, 
Deepak Gupta 
mailto:deepak.gu...@oneconvergence.com>>
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

Edgar,

Our CI is running the tests (non voting), but don't see it listed on the review 
for any patch. Is this due to missing logs? I would like to confirm this is the 
issue, will resolve this.

Thanks,
-hemanth


On Mon, Aug 18, 2014 at 8:35 AM, Edgar Magana 
mailto:edgar.mag...@workday.com>> wrote:
Thank you Akihiro.

I will propose a better organization for this section. Stay tune!

Edgar

On 8/17/14, 10:53 PM, "Akihiro Motoki" 
mailto:mot...@da.jp.nec.com>> wrote:

>
>On 2014/08/18 0:12, Kyle Mestery wrote:
>> On Fri, Aug 15, 2014 at 5:35 PM, Edgar Magana
>>mailto:edgar.mag...@workday.com>> wrote:
>>> Team,
>>>
>>> I did a quick audit on the Neutron CI. Very sad results. Only few
>>>plugins
>>> and drivers are running properly and testing all Neutron commits.
>>> I created a report here:
>>>
>>>https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plu
>>>gin
>>> _and_Drivers
>>>
>> Can you link this and/or move it to this page:
>>
>> https://wiki.openstack.org/wiki/NeutronPlugins
>>
>> This is under the "NeutronPolicies" wiki page which I did at the start
>> of Juno. This tracks all policies and procedures for Neutron, and
>> there's a Plugins page (which I linked to above) where this should
>> land.
>
>I just added the link Neutron_Plugins_and_Drivers#Existing_Plugin
>to NeutronPlugins wiki.
>
>The wiki pages NeutronPlugins and Neutron_Plugins_and_Drivers
>cover the similar contents. According to the history of the page,
>the latter one was created by Mark at Nov 2013 (beginning of Icehouse
>cycle).
>It seems better to merge these two pages to avoid the confusion.
>
>Akihiro
>
>>
>>>
>>> We will discuss the actions to take on the next Neutron IRC meeting. So
>>> please, reach me out to clarify what is the status of your CI.
>>> I had two commits to quickly verify the CI reliability:
>>>
>>> https://review.openstack.org/#/c/114393/
>>>
>>> https://review.openstack.org/#/c/40296/
>>>
>>>
>>> I would expect all plugins and drivers passing on the first one and
>>> failing for the second but I got so many surprises.
>>>
>>> Neutron code quality and reliability is a top priority, if you ignore
>>>this
>>> report that plugin/driver will be candidate to be remove from Neutron
>>>tree.
>>>
>>> Cheers,
>>>
>>> Edgar
>>>
>>> P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty
>>>job!
>>>
>> Thanks for sending this out Edgar and doing this analysis! Can you
>> please put an agenda item on Monday's meeting to discuss this? I won't
>> be at the meeting as I'm on PTO (Mark is running the meeting in my
>> absence), but I'd like the team to discuss this and allow all
>> third-party people a chance to be there and share their feelings here.
>>
>> Thanks,
>> Kyle
>>
>>>
>>> On 8/14/14, 8:30 AM, "Kyle Mestery" 
>>> mailto:mest...@mestery.com>> wrote:
>>>
>>>> Folks, I'm not sure if all CI accounts are running sufficient tests.
>>>> Per the requirements wiki page here [1], everyone needs to be running
>>>> more than just Tempest API tests, which I still see most neutron
>>>> third-party CI setups doing. I'd like to ask everyone who operates a
>>>> third-party CI account for Neutron to please look at the link below
>>>> and make sure you are running appropriate tests. If you have
>>>> questions, the weekly third-party meeting [2] is a great place to ask
>>>> questions.
>>>>
>>>> Thanks,
>>>> Kyle
>>>>
>>>> [1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
>>>> [2] https://wiki.openstack.org/wiki/Meetings/ThirdParty
>>>>

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

[Edgar Magana]

I just added it to the wiki page.

Thanks,

Edgar

On 8/17/14, 8:49 PM, "balaj...@freescale.com" 
wrote:

>Hi Edgar,
>
>Freescale CI is not listed in the below report:
>
>https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Pl
>
>We are following all the requirements of CI setup and as well
>participating in the IRC Meeting. Can you please let us know if we are
>missing any other requirements of CI Setup.
>
>Regards,
>Balaji.P
>
>
>
>> -Original Message-
>> From: trinath.soman...@freescale.com
>> [mailto:trinath.soman...@freescale.com]
>> Sent: Sunday, August 17, 2014 12:04 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>> required to be run
>> 
>> Hi Edgar,
>> 
>> Freescale CI is reporting the results for ML2 Mechanism driver (J-1) and
>> FWaaS Plugin (to be approved for J-3).
>> I'm the owner for this CI.
>> 
>> The Wiki page for this CI is
>> https://wiki.openstack.org/wiki/ThirdPartySystems/Freescale_CI.
>> 
>> --
>> Trinath Somanchi - B39208
>> trinath.soman...@freescale.com | extn: 4048
>> 
>> -Original Message-
>> From: Edgar Magana [mailto:edgar.mag...@workday.com]
>> Sent: Saturday, August 16, 2014 4:06 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>> required to be run
>> Importance: High
>> 
>> Team,
>> 
>> I did a quick audit on the Neutron CI. Very sad results. Only few
>>plugins
>> and drivers are running properly and testing all Neutron commits.
>> I created a report here:
>> 
>>https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plug
>> in
>> _and_Drivers
>> 
>> 
>> We will discuss the actions to take on the next Neutron IRC meeting. So
>> please, reach me out to clarify what is the status of your CI.
>> I had two commits to quickly verify the CI reliability:
>> 
>> https://review.openstack.org/#/c/114393/
>> 
>> https://review.openstack.org/#/c/40296/
>> 
>> 
>> I would expect all plugins and drivers passing on the first one and
>> failing for the second but I got so many surprises.
>> 
>> Neutron code quality and reliability is a top priority, if you ignore
>> this report that plugin/driver will be candidate to be remove from
>> Neutron tree.
>> 
>> Cheers,
>> 
>> Edgar
>> 
>> P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty
>> job!
>> 
>> 
>> On 8/14/14, 8:30 AM, "Kyle Mestery"  wrote:
>> 
>> >Folks, I'm not sure if all CI accounts are running sufficient tests.
>> >Per the requirements wiki page here [1], everyone needs to be running
>> >more than just Tempest API tests, which I still see most neutron
>> >third-party CI setups doing. I'd like to ask everyone who operates a
>> >third-party CI account for Neutron to please look at the link below and
>> >make sure you are running appropriate tests. If you have questions, the
>> >weekly third-party meeting [2] is a great place to ask questions.
>> >
>> >Thanks,
>> >Kyle
>> >
>> >[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
>> >[2] 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
>> 
>> ___
>> 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] [third-party] What tests are required to be run

[Edgar Magana]

Dane,

Are you sure about it?
I just went to this commit and I could not find the APIC tests.

Thanks,

Edgar

On 8/17/14, 8:47 PM, "Dane Leblanc (leblancd)"  wrote:

>Edgar:
>
>The Cisco APIC should be reporting results for both APIC-related and
>non-APIC related changes now.
>(See http://cisco-neutron-ci.cisco.com/logs/apic/1738/).
>
>Will you be updating the wiki page?
>
>-Dane
>
>-Original Message-
>From: Dane Leblanc (leblancd)
>Sent: Friday, August 15, 2014 8:18 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>required to be run
>
>Also, you can add me as a contact person for the Cisco VPNaaS driver.
>
>-Original Message-
>From: Dane Leblanc (leblancd)
>Sent: Friday, August 15, 2014 8:14 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: RE: [openstack-dev] [neutron] [third-party] What tests are
>required to be run
>
>Edgar:
>
>For the Notes for the Cisco APIC, can you change the comment "results are
>fake" to something like "results are only valid for APIC-related
>commits"? I think this more accurately represents our current results
>(for reasons we chatted about on another thread).
>
>Thanks,
>Dane
>
>-Original Message-
>From: Edgar Magana [mailto:edgar.mag...@workday.com]
>Sent: Friday, August 15, 2014 6:36 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>required to be run
>Importance: High
>
>Team,
>
>I did a quick audit on the Neutron CI. Very sad results. Only few plugins
>and drivers are running properly and testing all Neutron commits.
>I created a report here:
>https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugi
>n
>_and_Drivers
>
>
>We will discuss the actions to take on the next Neutron IRC meeting. So
>please, reach me out to clarify what is the status of your CI.
>I had two commits to quickly verify the CI reliability:
>
>https://review.openstack.org/#/c/114393/
>
>https://review.openstack.org/#/c/40296/
>
>
>I would expect all plugins and drivers passing on the first one and
>failing for the second but I got so many surprises.
>
>Neutron code quality and reliability is a top priority, if you ignore
>this report that plugin/driver will be candidate to be remove from
>Neutron tree.
>
>Cheers,
>
>Edgar
>
>P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty
>job!
>
>
>On 8/14/14, 8:30 AM, "Kyle Mestery"  wrote:
>
>>Folks, I'm not sure if all CI accounts are running sufficient tests.
>>Per the requirements wiki page here [1], everyone needs to be running
>>more than just Tempest API tests, which I still see most neutron
>>third-party CI setups doing. I'd like to ask everyone who operates a
>>third-party CI account for Neutron to please look at the link below and
>>make sure you are running appropriate tests. If you have questions, the
>>weekly third-party meeting [2] is a great place to ask questions.
>>
>>Thanks,
>>Kyle
>>
>>[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
>>[2] 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
>
>___
>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] What tests are required to be run

[Edgar Magana]

I just updated the wiki, I will run a verification by end of the day.

Thanks,

Edgar

On 8/16/14, 11:34 PM, "trinath.soman...@freescale.com"
 wrote:

>Hi Edgar,
>
>Freescale CI is reporting the results for ML2 Mechanism driver (J-1) and
>FWaaS Plugin (to be approved for J-3).
>I'm the owner for this CI.
>
>The Wiki page for this CI is
>https://wiki.openstack.org/wiki/ThirdPartySystems/Freescale_CI.
>
>--
>Trinath Somanchi - B39208
>trinath.soman...@freescale.com | extn: 4048
>
>-Original Message-
>From: Edgar Magana [mailto:edgar.mag...@workday.com]
>Sent: Saturday, August 16, 2014 4:06 AM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>required to be run
>Importance: High
>
>Team,
>
>I did a quick audit on the Neutron CI. Very sad results. Only few plugins
>and drivers are running properly and testing all Neutron commits.
>I created a report here:
>https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugi
>n
>_and_Drivers
>
>
>We will discuss the actions to take on the next Neutron IRC meeting. So
>please, reach me out to clarify what is the status of your CI.
>I had two commits to quickly verify the CI reliability:
>
>https://review.openstack.org/#/c/114393/
>
>https://review.openstack.org/#/c/40296/
>
>
>I would expect all plugins and drivers passing on the first one and
>failing for the second but I got so many surprises.
>
>Neutron code quality and reliability is a top priority, if you ignore
>this report that plugin/driver will be candidate to be remove from
>Neutron tree.
>
>Cheers,
>
>Edgar
>
>P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty
>job!
>
>
>On 8/14/14, 8:30 AM, "Kyle Mestery"  wrote:
>
>>Folks, I'm not sure if all CI accounts are running sufficient tests.
>>Per the requirements wiki page here [1], everyone needs to be running
>>more than just Tempest API tests, which I still see most neutron
>>third-party CI setups doing. I'd like to ask everyone who operates a
>>third-party CI account for Neutron to please look at the link below and
>>make sure you are running appropriate tests. If you have questions, the
>>weekly third-party meeting [2] is a great place to ask questions.
>>
>>Thanks,
>>Kyle
>>
>>[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
>>[2] 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
>
>___
>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] What tests are required to be run

[Edgar Magana]

Thanks a lot, Brocade CI is looking good.

Cheers,

Edgar

On 8/15/14, 6:22 PM, "Karthik Natarajan"  wrote:

>Hi Edgar,
>
>Brocade Vyatta CI is reporting the results and providing log links.
>For Brocade Vyatta Plugin, I have updated my name as the owner.
>For Brocade VDX Plugin, Shiv Haris is the owner.
>Please let me know if you have any questions.
>
>Thanks,
>Karthik
>
>-----Original Message-
>From: Edgar Magana [mailto:edgar.mag...@workday.com]
>Sent: Friday, August 15, 2014 3:59 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>required to be run
>Importance: High
>
>Correction
>
>The right links are:
>
>https://review.openstack.org/#/c/114629/
>
>https://review.openstack.org/#/c/114393/
>
>
>Not this one:
>https://review.openstack.org/#/c/40296/
>
>
>Edgar
>
>On 8/15/14, 3:35 PM, "Edgar Magana"  wrote:
>
>>Team,
>>
>>I did a quick audit on the Neutron CI. Very sad results. Only few
>>plugins and drivers are running properly and testing all Neutron commits.
>>I created a report here:
>>https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Pl
>>ugi
>>n
>>_and_Drivers
>>
>>
>>We will discuss the actions to take on the next Neutron IRC meeting. So
>>please, reach me out to clarify what is the status of your CI.
>>I had two commits to quickly verify the CI reliability:
>>
>>https://review.openstack.org/#/c/114393/
>>
>>https://review.openstack.org/#/c/40296/
>>
>>
>>I would expect all plugins and drivers passing on the first one and
>>failing for the second but I got so many surprises.
>>
>>Neutron code quality and reliability is a top priority, if you ignore
>>this report that plugin/driver will be candidate to be remove from
>>Neutron tree.
>>
>>Cheers,
>>
>>Edgar
>>
>>P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty
>>job!
>>
>>
>>On 8/14/14, 8:30 AM, "Kyle Mestery"  wrote:
>>
>>>Folks, I'm not sure if all CI accounts are running sufficient tests.
>>>Per the requirements wiki page here [1], everyone needs to be running
>>>more than just Tempest API tests, which I still see most neutron
>>>third-party CI setups doing. I'd like to ask everyone who operates a
>>>third-party CI account for Neutron to please look at the link below
>>>and make sure you are running appropriate tests. If you have
>>>questions, the weekly third-party meeting [2] is a great place to ask
>>>questions.
>>>
>>>Thanks,
>>>Kyle
>>>
>>>[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
>>>[2] 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
>
>___
>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] What tests are required to be run

[Edgar Magana]

Great!

I will run another test later today.

Thanks,

Edgar

From: Ichihara Hirofumi 
mailto:ichihara.hirof...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, August 15, 2014 at 5:33 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

Hi, Edgar

MetapluginCI didn't run for document changes.
I changed filter so that CI run for ALL changes include documents.

Thanks,
Hirofumi


2014-08-16 7:35 GMT+09:00 Edgar Magana 
mailto:edgar.mag...@workday.com>>:
Team,

I did a quick audit on the Neutron CI. Very sad results. Only few plugins
and drivers are running properly and testing all Neutron commits.
I created a report here:
https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugin
_and_Drivers


We will discuss the actions to take on the next Neutron IRC meeting. So
please, reach me out to clarify what is the status of your CI.
I had two commits to quickly verify the CI reliability:

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

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


I would expect all plugins and drivers passing on the first one and
failing for the second but I got so many surprises.

Neutron code quality and reliability is a top priority, if you ignore this
report that plugin/driver will be candidate to be remove from Neutron tree.

Cheers,

Edgar

P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty job!


On 8/14/14, 8:30 AM, "Kyle Mestery" 
mailto:mest...@mestery.com>> wrote:

>Folks, I'm not sure if all CI accounts are running sufficient tests.
>Per the requirements wiki page here [1], everyone needs to be running
>more than just Tempest API tests, which I still see most neutron
>third-party CI setups doing. I'd like to ask everyone who operates a
>third-party CI account for Neutron to please look at the link below
>and make sure you are running appropriate tests. If you have
>questions, the weekly third-party meeting [2] is a great place to ask
>questions.
>
>Thanks,
>Kyle
>
>[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
>[2] https://wiki.openstack.org/wiki/Meetings/ThirdParty
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto: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] What tests are required to be run

[Edgar Magana]

Dane,

It is not my intention to damage anyone's image or work. I ran a test and
I noticed that APIC CI was giving a PASSED result when it was not even
running anything, for me that means "fake".
I just responded to your other email, I adopt see APIC CI running and I
can't change the wiki until I verify it.

I am online and you can contact me on IRC.

Thanks,

Edgar

On 8/15/14, 5:13 PM, "Dane Leblanc (leblancd)"  wrote:

>Edgar:
>
>For the Notes for the Cisco APIC, can you change the comment "results are
>fake" to something like "results are only valid for APIC-related
>commits"? I think this more accurately represents our current results
>(for reasons we chatted about on another thread).
>
>Thanks,
>Dane
>
>-Original Message-
>From: Edgar Magana [mailto:edgar.mag...@workday.com]
>Sent: Friday, August 15, 2014 6:36 PM
>To: OpenStack Development Mailing List (not for usage questions)
>Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>required to be run
>Importance: High
>
>Team,
>
>I did a quick audit on the Neutron CI. Very sad results. Only few plugins
>and drivers are running properly and testing all Neutron commits.
>I created a report here:
>https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugi
>n
>_and_Drivers
>
>
>We will discuss the actions to take on the next Neutron IRC meeting. So
>please, reach me out to clarify what is the status of your CI.
>I had two commits to quickly verify the CI reliability:
>
>https://review.openstack.org/#/c/114393/
>
>https://review.openstack.org/#/c/40296/
>
>
>I would expect all plugins and drivers passing on the first one and
>failing for the second but I got so many surprises.
>
>Neutron code quality and reliability is a top priority, if you ignore
>this report that plugin/driver will be candidate to be remove from
>Neutron tree.
>
>Cheers,
>
>Edgar
>
>P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty
>job!
>
>
>On 8/14/14, 8:30 AM, "Kyle Mestery"  wrote:
>
>>Folks, I'm not sure if all CI accounts are running sufficient tests.
>>Per the requirements wiki page here [1], everyone needs to be running
>>more than just Tempest API tests, which I still see most neutron
>>third-party CI setups doing. I'd like to ask everyone who operates a
>>third-party CI account for Neutron to please look at the link below and
>>make sure you are running appropriate tests. If you have questions, the
>>weekly third-party meeting [2] is a great place to ask questions.
>>
>>Thanks,
>>Kyle
>>
>>[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
>>[2] 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
>
>___
>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] What tests are required to be run

[Edgar Magana]

Kevin,

I just verified, Thanks a lot.

Edgar

From: Kevin Benton mailto:blak...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, August 15, 2014 at 4:56 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

You didn't wait long enough for the Big Switch CI to reach your negative test. 
:-)
 Currently the CI system is backed by about 100 patches to push responses out 
~22 hours.

This does bring up an old discussion that was never resolved.
What is the minimum expected response time for CI systems?


On Fri, Aug 15, 2014 at 3:35 PM, Edgar Magana 
mailto:edgar.mag...@workday.com>> wrote:
Team,

I did a quick audit on the Neutron CI. Very sad results. Only few plugins
and drivers are running properly and testing all Neutron commits.
I created a report here:
https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugin
_and_Drivers


We will discuss the actions to take on the next Neutron IRC meeting. So
please, reach me out to clarify what is the status of your CI.
I had two commits to quickly verify the CI reliability:

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

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


I would expect all plugins and drivers passing on the first one and
failing for the second but I got so many surprises.

Neutron code quality and reliability is a top priority, if you ignore this
report that plugin/driver will be candidate to be remove from Neutron tree.

Cheers,

Edgar

P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty job!


On 8/14/14, 8:30 AM, "Kyle Mestery" 
mailto:mest...@mestery.com>> wrote:

>Folks, I'm not sure if all CI accounts are running sufficient tests.
>Per the requirements wiki page here [1], everyone needs to be running
>more than just Tempest API tests, which I still see most neutron
>third-party CI setups doing. I'd like to ask everyone who operates a
>third-party CI account for Neutron to please look at the link below
>and make sure you are running appropriate tests. If you have
>questions, the weekly third-party meeting [2] is a great place to ask
>questions.
>
>Thanks,
>Kyle
>
>[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
>[2] https://wiki.openstack.org/wiki/Meetings/ThirdParty
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto: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

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

[Edgar Magana]

I was looking to one of the most recent Neutron commits:
https://review.openstack.org/#/c/115175/


I could not find the APIC report.

Edgar

On 8/19/14, 9:48 AM, "Dane Leblanc (leblancd)"  wrote:

>From which commit is it missing?
>https://review.openstack.org/#/c/114629/
>https://review.openstack.org/#/c/114393/
>
>-Original Message-
>From: Edgar Magana [mailto:edgar.mag...@workday.com]
>Sent: Tuesday, August 19, 2014 12:28 PM
>To: Dane Leblanc (leblancd); OpenStack Development Mailing List (not for
>usage questions)
>Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>required to be run
>
>Dane,
>
>Are you sure about it?
>I just went to this commit and I could not find the APIC tests.
>
>Thanks,
>
>Edgar
>
>On 8/17/14, 8:47 PM, "Dane Leblanc (leblancd)"  wrote:
>
>>Edgar:
>>
>>The Cisco APIC should be reporting results for both APIC-related and
>>non-APIC related changes now.
>>(See http://cisco-neutron-ci.cisco.com/logs/apic/1738/).
>>
>>Will you be updating the wiki page?
>>
>>-Dane
>>
>>-Original Message-
>>From: Dane Leblanc (leblancd)
>>Sent: Friday, August 15, 2014 8:18 PM
>>To: OpenStack Development Mailing List (not for usage questions)
>>Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>>required to be run
>>
>>Also, you can add me as a contact person for the Cisco VPNaaS driver.
>>
>>-Original Message-
>>From: Dane Leblanc (leblancd)
>>Sent: Friday, August 15, 2014 8:14 PM
>>To: OpenStack Development Mailing List (not for usage questions)
>>Subject: RE: [openstack-dev] [neutron] [third-party] What tests are
>>required to be run
>>
>>Edgar:
>>
>>For the Notes for the Cisco APIC, can you change the comment "results
>>are fake" to something like "results are only valid for APIC-related
>>commits"? I think this more accurately represents our current results
>>(for reasons we chatted about on another thread).
>>
>>Thanks,
>>Dane
>>
>>-Original Message-
>>From: Edgar Magana [mailto:edgar.mag...@workday.com]
>>Sent: Friday, August 15, 2014 6:36 PM
>>To: OpenStack Development Mailing List (not for usage questions)
>>Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>>required to be run
>>Importance: High
>>
>>Team,
>>
>>I did a quick audit on the Neutron CI. Very sad results. Only few
>>plugins and drivers are running properly and testing all Neutron commits.
>>I created a report here:
>>https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Pl
>>ugi
>>n
>>_and_Drivers
>>
>>
>>We will discuss the actions to take on the next Neutron IRC meeting. So
>>please, reach me out to clarify what is the status of your CI.
>>I had two commits to quickly verify the CI reliability:
>>
>>https://review.openstack.org/#/c/114393/
>>
>>https://review.openstack.org/#/c/40296/
>>
>>
>>I would expect all plugins and drivers passing on the first one and
>>failing for the second but I got so many surprises.
>>
>>Neutron code quality and reliability is a top priority, if you ignore
>>this report that plugin/driver will be candidate to be remove from
>>Neutron tree.
>>
>>Cheers,
>>
>>Edgar
>>
>>P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty
>>job!
>>
>>
>>On 8/14/14, 8:30 AM, "Kyle Mestery"  wrote:
>>
>>>Folks, I'm not sure if all CI accounts are running sufficient tests.
>>>Per the requirements wiki page here [1], everyone needs to be running
>>>more than just Tempest API tests, which I still see most neutron
>>>third-party CI setups doing. I'd like to ask everyone who operates a
>>>third-party CI account for Neutron to please look at the link below
>>>and make sure you are running appropriate tests. If you have
>>>questions, the weekly third-party meeting [2] is a great place to ask
>>>questions.
>>>
>>>Thanks,
>>>Kyle
>>>
>>>[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
>>>[2] 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
>>
>>___
>>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] What tests are required to be run

[Edgar Magana]

Dane,

Wiki has been updated.

Thanks,

Edgar

On 8/21/14, 7:57 AM, "Dane Leblanc (leblancd)"  wrote:

>Edgar:
>
>The status on the wiki page says "Results are not accurate. Needs
>clarification from Cisco".
>Can you please tell me what we are missing?
>
>-Dane
>
>-Original Message-
>From: Dane Leblanc (leblancd)
>Sent: Tuesday, August 19, 2014 3:05 PM
>To: 'Edgar Magana'; OpenStack Development Mailing List (not for usage
>questions)
>Subject: RE: [openstack-dev] [neutron] [third-party] What tests are
>required to be run
>
>The APIC CI did run tests against that commit (after some queue latency):
>
>http://128.107.233.28:8080/job/apic/1860/
>http://cisco-neutron-ci.cisco.com/logs/apic/1860/
>
>But the review comments never showed up on Gerrit. This seems to be an
>intermittent quirk of Jenkins/Gerrit: We have 3 CIs triggered from this
>Jenkins/Gerrit server. Whenever we disable another one of our other
>Jenkins jobs (in this case, we disabled DFA for some rework), the review
>comments sometimes stop showing up on Gerrit.
>
>-Original Message-
>From: Edgar Magana [mailto:edgar.mag...@workday.com]
>Sent: Tuesday, August 19, 2014 1:33 PM
>To: Dane Leblanc (leblancd); OpenStack Development Mailing List (not for
>usage questions)
>Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>required to be run
>
>I was looking to one of the most recent Neutron commits:
>https://review.openstack.org/#/c/115175/
>
>
>I could not find the APIC report.
>
>Edgar
>
>On 8/19/14, 9:48 AM, "Dane Leblanc (leblancd)"  wrote:
>
>>From which commit is it missing?
>>https://review.openstack.org/#/c/114629/
>>https://review.openstack.org/#/c/114393/
>>
>>-Original Message-
>>From: Edgar Magana [mailto:edgar.mag...@workday.com]
>>Sent: Tuesday, August 19, 2014 12:28 PM
>>To: Dane Leblanc (leblancd); OpenStack Development Mailing List (not
>>for usage questions)
>>Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>>required to be run
>>
>>Dane,
>>
>>Are you sure about it?
>>I just went to this commit and I could not find the APIC tests.
>>
>>Thanks,
>>
>>Edgar
>>
>>On 8/17/14, 8:47 PM, "Dane Leblanc (leblancd)" 
>>wrote:
>>
>>>Edgar:
>>>
>>>The Cisco APIC should be reporting results for both APIC-related and
>>>non-APIC related changes now.
>>>(See http://cisco-neutron-ci.cisco.com/logs/apic/1738/).
>>>
>>>Will you be updating the wiki page?
>>>
>>>-Dane
>>>
>>>-Original Message-
>>>From: Dane Leblanc (leblancd)
>>>Sent: Friday, August 15, 2014 8:18 PM
>>>To: OpenStack Development Mailing List (not for usage questions)
>>>Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>>>required to be run
>>>
>>>Also, you can add me as a contact person for the Cisco VPNaaS driver.
>>>
>>>-Original Message-
>>>From: Dane Leblanc (leblancd)
>>>Sent: Friday, August 15, 2014 8:14 PM
>>>To: OpenStack Development Mailing List (not for usage questions)
>>>Subject: RE: [openstack-dev] [neutron] [third-party] What tests are
>>>required to be run
>>>
>>>Edgar:
>>>
>>>For the Notes for the Cisco APIC, can you change the comment "results
>>>are fake" to something like "results are only valid for APIC-related
>>>commits"? I think this more accurately represents our current results
>>>(for reasons we chatted about on another thread).
>>>
>>>Thanks,
>>>Dane
>>>
>>>-Original Message-
>>>From: Edgar Magana [mailto:edgar.mag...@workday.com]
>>>Sent: Friday, August 15, 2014 6:36 PM
>>>To: OpenStack Development Mailing List (not for usage questions)
>>>Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>>>required to be run
>>>Importance: High
>>>
>>>Team,
>>>
>>>I did a quick audit on the Neutron CI. Very sad results. Only few
>>>plugins and drivers are running properly and testing all Neutron
>>>commits.
>>>I created a report here:
>>>https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_P
>>>l
>>>ugi
>>>n
>>>_and_Drivers
>>>
>>>
>>>We will discuss the actions to take on the next Neutron IRC meeting.
>>>So please, reach me out to clarify what is the status of your CI.
>&

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

[Edgar Magana]

Maximum time to vote, can you clarify?

Edgar

From: Kevin Benton mailto:blak...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, August 19, 2014 at 1:11 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run


I also added a two more nodes to our cluster to reduce the delay. Can we 
establish a maximum time to vote on the wiki?

On Aug 19, 2014 9:39 AM, "Edgar Magana" 
mailto:edgar.mag...@workday.com>> wrote:
Kevin,

I just verified, Thanks a lot.

Edgar

From: Kevin Benton mailto:blak...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, August 15, 2014 at 4:56 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

You didn't wait long enough for the Big Switch CI to reach your negative test. 
:-)
 Currently the CI system is backed by about 100 patches to push responses out 
~22 hours.

This does bring up an old discussion that was never resolved.
What is the minimum expected response time for CI systems?


On Fri, Aug 15, 2014 at 3:35 PM, Edgar Magana 
mailto:edgar.mag...@workday.com>> wrote:
Team,

I did a quick audit on the Neutron CI. Very sad results. Only few plugins
and drivers are running properly and testing all Neutron commits.
I created a report here:
https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugin
_and_Drivers


We will discuss the actions to take on the next Neutron IRC meeting. So
please, reach me out to clarify what is the status of your CI.
I had two commits to quickly verify the CI reliability:

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

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


I would expect all plugins and drivers passing on the first one and
failing for the second but I got so many surprises.

Neutron code quality and reliability is a top priority, if you ignore this
report that plugin/driver will be candidate to be remove from Neutron tree.

Cheers,

Edgar

P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty job!


On 8/14/14, 8:30 AM, "Kyle Mestery" 
mailto:mest...@mestery.com>> wrote:

>Folks, I'm not sure if all CI accounts are running sufficient tests.
>Per the requirements wiki page here [1], everyone needs to be running
>more than just Tempest API tests, which I still see most neutron
>third-party CI setups doing. I'd like to ask everyone who operates a
>third-party CI account for Neutron to please look at the link below
>and make sure you are running appropriate tests. If you have
>questions, the weekly third-party meeting [2] is a great place to ask
>questions.
>
>Thanks,
>Kyle
>
>[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
>[2] https://wiki.openstack.org/wiki/Meetings/ThirdParty
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto: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<mailto: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] What tests are required to be run

[Edgar Magana]

Excellent Job!

Thanks a lot, I have updated the wiki.

Edgar

From: Hemanth Ravi mailto:hemanthrav...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, August 21, 2014 at 1:37 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

Edgar,

CI name: One Convergence CI

The logs issue has been fixed and earlier tests were failing due to  
https://review.openstack.org/#/c/114146

For reference:

1. Please take a look at the vote on patchset 7 in 
https://review.openstack.org/#/c/114968/
2. Logs at https://www.dropbox.com/sh/czydzz5bn2rc2lp/AABZByV8UQUIqWaZSSrZvzvDa

Thanks,
-hemanth



On Thu, Aug 21, 2014 at 12:41 PM, Kevin Benton 
mailto:blak...@gmail.com>> wrote:
Our system would get backed up with patches and sometimes take up to 10 hours 
to respond with results for a change.
We should establish some maximum acceptable time to get the results for a patch.


On Thu, Aug 21, 2014 at 11:59 AM, Edgar Magana 
mailto:edgar.mag...@workday.com>> wrote:
Maximum time to vote, can you clarify?

Edgar

From: Kevin Benton mailto:blak...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, August 19, 2014 at 1:11 PM

To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run


I also added a two more nodes to our cluster to reduce the delay. Can we 
establish a maximum time to vote on the wiki?

On Aug 19, 2014 9:39 AM, "Edgar Magana" 
mailto:edgar.mag...@workday.com>> wrote:
Kevin,

I just verified, Thanks a lot.

Edgar

From: Kevin Benton mailto:blak...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Friday, August 15, 2014 at 4:56 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] [third-party] What tests are required to 
be run

You didn't wait long enough for the Big Switch CI to reach your negative test. 
:-)
 Currently the CI system is backed by about 100 patches to push responses out 
~22 hours.

This does bring up an old discussion that was never resolved.
What is the minimum expected response time for CI systems?


On Fri, Aug 15, 2014 at 3:35 PM, Edgar Magana 
mailto:edgar.mag...@workday.com>> wrote:
Team,

I did a quick audit on the Neutron CI. Very sad results. Only few plugins
and drivers are running properly and testing all Neutron commits.
I created a report here:
https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugin
_and_Drivers


We will discuss the actions to take on the next Neutron IRC meeting. So
please, reach me out to clarify what is the status of your CI.
I had two commits to quickly verify the CI reliability:

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

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


I would expect all plugins and drivers passing on the first one and
failing for the second but I got so many surprises.

Neutron code quality and reliability is a top priority, if you ignore this
report that plugin/driver will be candidate to be remove from Neutron tree.

Cheers,

Edgar

P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty job!


On 8/14/14, 8:30 AM, "Kyle Mestery" 
mailto:mest...@mestery.com>> wrote:

>Folks, I'm not sure if all CI accounts are running sufficient tests.
>Per the requirements wiki page here [1], everyone needs to be running
>more than just Tempest API tests, which I still see most neutron
>third-party CI setups doing. I'd like to ask everyone who operates a
>third-party CI account for Neutron to please look at the link below
>and make sure you are running appropriate tests. If you have
>questions, the weekly third-party meeting [2] is a great place to ask
>questions.
>
>Thanks,
>Kyle
>
>[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
>[2] https://wiki.openstack.org/wiki/Meetings/ThirdParty
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

[Edgar Magana]

Sorry my bad but I just changed.

Edgar

On 8/21/14, 2:13 PM, "Dane Leblanc (leblancd)"  wrote:

>Edgar:
>
>I'm still seeing the comment "Results are not accurate. Needs
>clarification..."
>
>Dane
>
>-Original Message-
>From: Edgar Magana [mailto:edgar.mag...@workday.com]
>Sent: Thursday, August 21, 2014 2:58 PM
>To: Dane Leblanc (leblancd); OpenStack Development Mailing List (not for
>usage questions)
>Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>required to be run
>
>Dane,
>
>Wiki has been updated.
>
>Thanks,
>
>Edgar
>
>On 8/21/14, 7:57 AM, "Dane Leblanc (leblancd)"  wrote:
>
>>Edgar:
>>
>>The status on the wiki page says "Results are not accurate. Needs
>>clarification from Cisco".
>>Can you please tell me what we are missing?
>>
>>-Dane
>>
>>-Original Message-
>>From: Dane Leblanc (leblancd)
>>Sent: Tuesday, August 19, 2014 3:05 PM
>>To: 'Edgar Magana'; OpenStack Development Mailing List (not for usage
>>questions)
>>Subject: RE: [openstack-dev] [neutron] [third-party] What tests are
>>required to be run
>>
>>The APIC CI did run tests against that commit (after some queue latency):
>>
>>http://128.107.233.28:8080/job/apic/1860/
>>http://cisco-neutron-ci.cisco.com/logs/apic/1860/
>>
>>But the review comments never showed up on Gerrit. This seems to be an
>>intermittent quirk of Jenkins/Gerrit: We have 3 CIs triggered from this
>>Jenkins/Gerrit server. Whenever we disable another one of our other
>>Jenkins jobs (in this case, we disabled DFA for some rework), the
>>review comments sometimes stop showing up on Gerrit.
>>
>>-Original Message-
>>From: Edgar Magana [mailto:edgar.mag...@workday.com]
>>Sent: Tuesday, August 19, 2014 1:33 PM
>>To: Dane Leblanc (leblancd); OpenStack Development Mailing List (not
>>for usage questions)
>>Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>>required to be run
>>
>>I was looking to one of the most recent Neutron commits:
>>https://review.openstack.org/#/c/115175/
>>
>>
>>I could not find the APIC report.
>>
>>Edgar
>>
>>On 8/19/14, 9:48 AM, "Dane Leblanc (leblancd)" 
>>wrote:
>>
>>>From which commit is it missing?
>>>https://review.openstack.org/#/c/114629/
>>>https://review.openstack.org/#/c/114393/
>>>
>>>-Original Message-
>>>From: Edgar Magana [mailto:edgar.mag...@workday.com]
>>>Sent: Tuesday, August 19, 2014 12:28 PM
>>>To: Dane Leblanc (leblancd); OpenStack Development Mailing List (not
>>>for usage questions)
>>>Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>>>required to be run
>>>
>>>Dane,
>>>
>>>Are you sure about it?
>>>I just went to this commit and I could not find the APIC tests.
>>>
>>>Thanks,
>>>
>>>Edgar
>>>
>>>On 8/17/14, 8:47 PM, "Dane Leblanc (leblancd)" 
>>>wrote:
>>>
>>>>Edgar:
>>>>
>>>>The Cisco APIC should be reporting results for both APIC-related and
>>>>non-APIC related changes now.
>>>>(See http://cisco-neutron-ci.cisco.com/logs/apic/1738/).
>>>>
>>>>Will you be updating the wiki page?
>>>>
>>>>-Dane
>>>>
>>>>-Original Message-
>>>>From: Dane Leblanc (leblancd)
>>>>Sent: Friday, August 15, 2014 8:18 PM
>>>>To: OpenStack Development Mailing List (not for usage questions)
>>>>Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>>>>required to be run
>>>>
>>>>Also, you can add me as a contact person for the Cisco VPNaaS driver.
>>>>
>>>>-Original Message-
>>>>From: Dane Leblanc (leblancd)
>>>>Sent: Friday, August 15, 2014 8:14 PM
>>>>To: OpenStack Development Mailing List (not for usage questions)
>>>>Subject: RE: [openstack-dev] [neutron] [third-party] What tests are
>>>>required to be run
>>>>
>>>>Edgar:
>>>>
>>>>For the Notes for the Cisco APIC, can you change the comment "results
>>>>are fake" to something like "results are only valid for APIC-related
>>>>commits"? I think this more accurately represents our current results
>>>>(for reasons we chatted about on another thread).
>

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

[Edgar Magana]

so looking into using a REST API to cancel a Jenkins job
>> programmatically.
>> * If no solution or workaround is available, we work with infra team or
>>with
>> Jenkins team to create a solution.
>> * Until a solution is available, for plugins which are blocked by a
>>critical
>> bug, we post a status/notes indicating the plugin's situation on our 3rd
>> party CI status wiki, e.g.:
>>
>> Vendor  Plugin/Driver Name      Contact Name
>> Status  Notes
>> My Vendor Name  My Plugin CIMy Contact Person   T
>> Throttled / Partially blocked / Awaiting Intial Commits
>>
>> The status/notes should be clear and understood by the Neutron team.
>>The
>> console logs for change sets where the tests were skipped should also
>> contain a message that all testing is being skipped for that commit.
>>
>> Note that when the DFA initial commits are merged, then this issue
>>would go
>> away for the DFA CI. However, this problem will reappear every time a
>> blocking critical bug shows up for a 3rd party CI setup, or a new
>>plugin is
>> introduced and the hardware-enabling commits are not yet merged.  (That
>>is,
>> until we have a solution for the Jenkins limitation).
>>
>> Let me know what you think.
>>
>>
>> Thanks,
>> Dane
>>
>> -Original Message-
>> From: Edgar Magana [mailto:edgar.mag...@workday.com]
>>
>> Sent: Friday, August 22, 2014 1:57 PM
>> To: Dane Leblanc (leblancd); OpenStack Development Mailing List (not for
>> usage questions)
>> Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>>required
>> to be run
>>
>> Sorry my bad but I just changed.
>>
>> Edgar
>>
>> On 8/21/14, 2:13 PM, "Dane Leblanc (leblancd)" 
>>wrote:
>>
>>>Edgar:
>>>
>>>I'm still seeing the comment "Results are not accurate. Needs
>>>clarification..."
>>>
>>>Dane
>>>
>>>-Original Message-
>>>From: Edgar Magana [mailto:edgar.mag...@workday.com]
>>>Sent: Thursday, August 21, 2014 2:58 PM
>>>To: Dane Leblanc (leblancd); OpenStack Development Mailing List (not
>>>for usage questions)
>>>Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>>>required to be run
>>>
>>>Dane,
>>>
>>>Wiki has been updated.
>>>
>>>Thanks,
>>>
>>>Edgar
>>>
>>>On 8/21/14, 7:57 AM, "Dane Leblanc (leblancd)" 
>>>wrote:
>>>
>>>>Edgar:
>>>>
>>>>The status on the wiki page says "Results are not accurate. Needs
>>>>clarification from Cisco".
>>>>Can you please tell me what we are missing?
>>>>
>>>>-Dane
>>>>
>>>>-Original Message-
>>>>From: Dane Leblanc (leblancd)
>>>>Sent: Tuesday, August 19, 2014 3:05 PM
>>>>To: 'Edgar Magana'; OpenStack Development Mailing List (not for usage
>>>>questions)
>>>>Subject: RE: [openstack-dev] [neutron] [third-party] What tests are
>>>>required to be run
>>>>
>>>>The APIC CI did run tests against that commit (after some queue
>>>>latency):
>>>>
>>>>http://128.107.233.28:8080/job/apic/1860/
>>>>http://cisco-neutron-ci.cisco.com/logs/apic/1860/
>>>>
>>>>But the review comments never showed up on Gerrit. This seems to be an
>>>>intermittent quirk of Jenkins/Gerrit: We have 3 CIs triggered from
>>>>this Jenkins/Gerrit server. Whenever we disable another one of our
>>>>other Jenkins jobs (in this case, we disabled DFA for some rework),
>>>>the review comments sometimes stop showing up on Gerrit.
>>>>
>>>>-Original Message-
>>>>From: Edgar Magana [mailto:edgar.mag...@workday.com]
>>>>Sent: Tuesday, August 19, 2014 1:33 PM
>>>>To: Dane Leblanc (leblancd); OpenStack Development Mailing List (not
>>>>for usage questions)
>>>>Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
>>>>required to be run
>>>>
>>>>I was looking to one of the most recent Neutron commits:
>>>>https://review.openstack.org/#/c/115175/
>>>>
>>>>
>>>>I could not find the APIC report.
>>>>
>>>>Edgar
>>>>
>>>>On 8/19/14, 9:48 AM, "Dane Leblanc (le

Re: [openstack-dev] [Neutron] Author tags

[Edgar Magana]

I do agree with Kyle. There is no rush for having this code merged in
order to a void multiple rebase work for the other patches.

Edgar

On 8/27/14, 9:25 AM, "Kyle Mestery"  wrote:

>On Wed, Aug 27, 2014 at 8:24 AM, Gary Kotton  wrote:
>> Hi,
>> A few cycles ago the Nova group decided to remove @author from copyright
>> statements. This is due to the fact that this information is stored in
>>git.
>> After adding a similar hacking rule to Neutron it has stirred up some
>> debate.
>> Does anyone have any reason to for us not to go ahead with
>> https://review.openstack.org/#/c/112329/.
>> Thanks
>> Gary
>>
>My main concern is around landing a change like this during feature
>freeze week, I think at best this should land at the start of Kilo.
>
>> ___
>> 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] [third-party] collecting recheck command to re-trigger third party CI

[Edgar Magana]

Hopefully, our schedule for Kilo will be flexible enough to allocate a session 
to discuss CI for Third Party in Neutron.
So, I completely agree with Sukhdev that all MLs iteration should get us into a 
formal conclusion and later into guidelines/process for all CI owners.

Edgar

From: Sukhdev Kapur mailto:sukhdevka...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, September 3, 2014 at 4:34 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [neutron] [third-party] collecting recheck command 
to re-trigger third party CI

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
[https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif]


On Wed, Sep 3, 2014 at 2:34 PM, Anita Kuno 
mailto: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<mailto:OpenStack-dev@lists.opensta

Re: [openstack-dev] Documentation on writing a neutron plugin/driver

[Edgar Magana]

Daniel,

You can start with:
https://wiki.openstack.org/wiki/NeutronDevelopment

You can also take a look to one of the latest plugins in being merged:
https://review.openstack.org/#/c/96630/

If you are looking into a ML2 driver:
https://review.openstack.org/#/c/64944/

Cheers,

Edgar

From: openstack technology 
<128openst...@gmail.com>
Reply-To: 
"OpenStack-dev@lists.openstack.org" 
mailto:OpenStack-dev@lists.openstack.org>>
Date: Thursday, September 18, 2014 at 2:05 PM
To: 
"OpenStack-dev@lists.openstack.org" 
mailto:OpenStack-dev@lists.openstack.org>>
Subject: [openstack-dev] Documentation on writing a neutron plugin/driver

Hi All:

Is there any documentation on how to write a neutron plugin & drivers 
(including what files need to be changed), I could not find this on OpenStack 
documentation pages. I tried to use the "Hdn" example plugin and tried to 
integrate it as a part of "DevStack" but looks like the "Hdn" example plugin is 
incomplete.

Any help on directions on how to write a neutron plugin & drivers (along with 
instructions on what files need to be changed).

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

Re: [openstack-dev] [Neutron] Race condition between DB layer and plugin back-end implementation

[Edgar Magana]

Isaku,

Do you have in mind any implementation, any BP?
We could actually work on this together, all plugins will get the benefits
of a better implementation.

Thanks,

Edgar

On 11/19/13 3:57 AM, "Isaku Yamahata"  wrote:

>On Mon, Nov 18, 2013 at 03:55:49PM -0500,
>Robert Kukura  wrote:
>
>> On 11/18/2013 03:25 PM, Edgar Magana wrote:
>> > Developers,
>> > 
>> > This topic has been discussed before but I do not remember if we have
>>a
>> > good solution or not.
>> 
>> The ML2 plugin addresses this by calling each MechanismDriver twice. The
>> create_network_precommit() method is called as part of the DB
>> transaction, and the create_network_postcommit() method is called after
>> the transaction has been committed. Interactions with devices or
>> controllers are done in the postcommit methods. If the postcommit method
>> raises an exception, the plugin deletes that partially-created resource
>> and returns the exception to the client. You might consider a similar
>> approach in your plugin.
>
>Splitting works into two phase, pre/post, is good approach.
>But there still remains race window.
>Once the transaction is committed, the result is visible to outside.
>So the concurrent request to same resource will be racy.
>There is a window after pre_xxx_yyy before post_xxx_yyy() where
>other requests can be handled.
>
>The state machine needs to be enhanced, I think. (plugins need
>modification)
>For example, adding more states like pending_{create, delete, update}.
>Also we would like to consider serializing between operation of ports
>and subnets. or between operation of subnets and network depending on
>performance requirement.
>(Or carefully audit complex status change. i.e.
>changing port during subnet/network update/deletion.)
>
>I think it would be useful to establish reference locking policy
>for ML2 plugin for SDN controllers.
>Thoughts or comments? If this is considered useful and acceptable,
>I'm willing to help.
>
>thanks,
>Isaku Yamahata
>
>> -Bob
>> 
>> > Basically, if concurrent API calls are sent to Neutron, all of them
>>are
>> > sent to the plug-in level where two actions have to be made:
>> > 
>> > 1. DB transaction ? No just for data persistence but also to collect
>>the
>> > information needed for the next action
>> > 2. Plug-in back-end implementation ? In our case is a call to the
>>python
>> > library than consequentially calls PLUMgrid REST GW (soon SAL)
>> > 
>> > For instance:
>> > 
>> > def create_port(self, context, port):
>> > with context.session.begin(subtransactions=True):
>> > # Plugin DB - Port Create and Return port
>> > port_db = super(NeutronPluginPLUMgridV2,
>> > self).create_port(context,
>> >   
>> port)
>> > device_id = port_db["device_id"]
>> > if port_db["device_owner"] == "network:router_gateway":
>> > router_db = self._get_router(context, device_id)
>> > else:
>> > router_db = None
>> > try:
>> > LOG.debug(_("PLUMgrid Library: create_port() called"))
>> > # Back-end implementation
>> > self._plumlib.create_port(port_db, router_db)
>> > except Exception:
>> > Š
>> > 
>> > The way we have implemented at the plugin-level in Havana (even in
>> > Grizzly) is that both action are wrapped in the same "transaction"
>>which
>> > automatically rolls back any operation done to its original state
>> > protecting mostly the DB of having any inconsistency state or left
>>over
>> > data if the back-end part fails.=.
>> > The problem that we are experiencing is when concurrent calls to the
>> > same API are sent, the number of operation at the plug-in back-end are
>> > long enough to make the next concurrent API call to get stuck at the
>>DB
>> > transaction level, which creates a hung state for the Neutron Server
>>to
>> > the point that all concurrent API calls will fail.
>> > 
>> > This can be fixed if we include some "locking" system such as calling:
>> > 
>> > from neutron.common import utile
>> > Š
>> > 
>> > @utils.synchronized('any-name', external=True)
>> > def create_port(self, context, port):
>> > Š
>> > 
>> > Obviously, this will

Re: [openstack-dev] [Neutron] Race condition between DB layer and plugin back-end implementation

[Edgar Magana]

Let me take a look and circle back to you in a bit. This is a very
sensitive part of the code, so we need to
Handle properly any change.

Thanks,

Edgar

On 11/20/13 5:46 AM, "Isaku Yamahata"  wrote:

>On Tue, Nov 19, 2013 at 08:59:38AM -0800,
>Edgar Magana  wrote:
>
>> Do you have in mind any implementation, any BP?
>> We could actually work on this together, all plugins will get the
>>benefits
>> of a better implementation.
>
>Yes, let's work together. Here is my blueprint (it's somewhat old.
>So needs to be updated.)
>https://blueprints.launchpad.net/neutron/+spec/fix-races-of-db-based-plugi
>n
>https://docs.google.com/file/d/0B4LNMvjOzyDuU2xNd0piS3JBMHM/edit
>
>Although I've thought of status change(adding more status) and locking
>protocol so far, TaskFlow seems something to look at before starting and
>another possible approach is decoupling backend process from api call
>as Salvatore suggested like NVP plugin.
>Even with taskflow or decoupling approach, some kind of enhancing status
>change/locking protocol will be necessary for performance of creating
>many ports at once.
>
>thanks,
>
>> 
>> Thanks,
>> 
>> Edgar
>> 
>> On 11/19/13 3:57 AM, "Isaku Yamahata"  wrote:
>> 
>> >On Mon, Nov 18, 2013 at 03:55:49PM -0500,
>> >Robert Kukura  wrote:
>> >
>> >> On 11/18/2013 03:25 PM, Edgar Magana wrote:
>> >> > Developers,
>> >> > 
>> >> > This topic has been discussed before but I do not remember if we
>>have
>> >>a
>> >> > good solution or not.
>> >> 
>> >> The ML2 plugin addresses this by calling each MechanismDriver twice.
>>The
>> >> create_network_precommit() method is called as part of the DB
>> >> transaction, and the create_network_postcommit() method is called
>>after
>> >> the transaction has been committed. Interactions with devices or
>> >> controllers are done in the postcommit methods. If the postcommit
>>method
>> >> raises an exception, the plugin deletes that partially-created
>>resource
>> >> and returns the exception to the client. You might consider a similar
>> >> approach in your plugin.
>> >
>> >Splitting works into two phase, pre/post, is good approach.
>> >But there still remains race window.
>> >Once the transaction is committed, the result is visible to outside.
>> >So the concurrent request to same resource will be racy.
>> >There is a window after pre_xxx_yyy before post_xxx_yyy() where
>> >other requests can be handled.
>> >
>> >The state machine needs to be enhanced, I think. (plugins need
>> >modification)
>> >For example, adding more states like pending_{create, delete, update}.
>> >Also we would like to consider serializing between operation of ports
>> >and subnets. or between operation of subnets and network depending on
>> >performance requirement.
>> >(Or carefully audit complex status change. i.e.
>> >changing port during subnet/network update/deletion.)
>> >
>> >I think it would be useful to establish reference locking policy
>> >for ML2 plugin for SDN controllers.
>> >Thoughts or comments? If this is considered useful and acceptable,
>> >I'm willing to help.
>> >
>> >thanks,
>> >Isaku Yamahata
>> >
>> >> -Bob
>> >> 
>> >> > Basically, if concurrent API calls are sent to Neutron, all of them
>> >>are
>> >> > sent to the plug-in level where two actions have to be made:
>> >> > 
>> >> > 1. DB transaction ? No just for data persistence but also to
>>collect
>> >>the
>> >> > information needed for the next action
>> >> > 2. Plug-in back-end implementation ? In our case is a call to the
>> >>python
>> >> > library than consequentially calls PLUMgrid REST GW (soon SAL)
>> >> > 
>> >> > For instance:
>> >> > 
>> >> > def create_port(self, context, port):
>> >> > with context.session.begin(subtransactions=True):
>> >> > # Plugin DB - Port Create and Return port
>> >> > port_db = super(NeutronPluginPLUMgridV2,
>> >> > self).create_port(context,
>> >> >
>> >> port)
>> >> > device_id = port_db["device_id"]
>> >> > if port_db["de

Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

[Edgar Magana]

Everything seems to be covered, thank for taking care of this.

Thanks,

Edgar

On 11/20/13 5:29 PM, "Anita Kuno"  wrote:

>Time for an update.
>
>Neutron Tempest code sprint
>Montreal, QC, Canada
>January 15, 16, 17 2014
>Salle du Parc, New Residence
>McGill University, 3625 Parc Avenue
>9pm - 5pm each day
>Breakfast, Lunch and coffee/tea included
>Agenda: details to be determined, focusing on addressing Neutron Tempest
>testing and communications between -neutron, -infra and -qa.
>
>Travel and accommodation: On your own.
>Dinners: On your own (unless someone wants to organize something)
>
>Do I need a visa to enter Canada?
>Good question, please check: http://www.cic.gc.ca/ENGLISH/visit/visas.asp
>
>If you are planning on attending and have not received an email from me
>asking you about dietary requirements, please email me at anteaya at
>anteaya dot info indicating your interest in attending.
>
>No official hotel but Rosella feels Le Nouvel Hotel has a good price:
>http://bit.ly/1fWLrV1
>
>Please ask questions if you need more than this.
>
>Thank you,
>Anita.
>
>
>On 11/13/2013 01:48 PM, Anita Kuno wrote:
>> So if you are requesting a letter of invitation to enter Canada, here is
>> what I have to do to provide it:
>> http://www.cic.gc.ca/english/visit/letter.asp
>> 
>> It appears that letters of invitation are only required sometimes:
>> "Sometimes, when you apply for a visa to visit Canada, we ask you to
>> give us a letter of invitation from someone in Canada."
>> so I will encourage you to contact your closest Canadian embassy or
>> consulate outside of Canada to assess if you need one. Hopefully if you
>> are planning on staying less that 1 week, you won't need one. But
>> contact the embassy and be sure.
>> 
>> Thanks,
>> Anita.
>> 
>> On 11/13/2013 01:25 PM, Edgar Magana wrote:
>>> Will do ASAP.
>>>
>>> Thanks,
>>>
>>> Edgar
>>>
>>> On 11/13/13 10:20 AM, "Anita Kuno"  wrote:
>>>
>>>> Hi Edgar:
>>>>
>>>> I hadn't thought of that, I guess I am going to have to do that.
>>>>
>>>> For others, check if you need a visa to enter Canada:
>>>> http://www.cic.gc.ca/ENGLISH/visit/visas.asp
>>>> Please notify me ASAP if you do, even if you aren't sure you can
>>>>attend
>>>> so I can get the paperwork you need.
>>>>
>>>> Edgar, can you email me your address to my personal email anteaya at
>>>> anteaya dot info so I can work on this for you.
>>>>
>>>> Thanks,
>>>> Anita.
>>>>
>>>> On 11/13/2013 01:12 PM, Edgar Magana wrote:
>>>>> Anita,
>>>>>
>>>>> Could you prepare the invitation letters for the ones that will
>>>>>require
>>>>> a
>>>>> visa?, which is my case.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Edgar
>>>>>
>>>>> On 11/13/13 8:10 AM, "Anita Kuno"  wrote:
>>>>>
>>>>>> Neutron Tempest code sprint
>>>>>>
>>>>>> In the second week of January in Montreal, Quebec, Canadathere will
>>>>>>be
>>>>>> a
>>>>>> Neutron Tempest code sprint to improve the status of Neutron tests
>>>>>>in
>>>>>> Tempest and to add new tests.
>>>>>> It will be a 3 day event. Right now there are 14 peoplewho came
>>>>>> forward
>>>>>> when it was announced on the Friday at the summit. We need to know
>>>>>>how
>>>>>> many additional people are interested in attending.
>>>>>>
>>>>>> This is an impromptu event based on my assessment of the need for
>>>>>>this
>>>>>> to happen, so don't feel left out if you didn't know about it in
>>>>>> advance.
>>>>>>
>>>>>> We picked Montreal for two main reasons:
>>>>>> 1. All 4 people whose attendance is critical (markmclain,
>>>>>> salv-orlando,
>>>>>> sdague and mtrenish) can get there. It was New York or Montreal.
>>>>>> 2. I can't think in New York, love it, can't compose a thought, so
>>>>>> Montreal it is.
>>>>>>
>>>>>> It turns out this location choice has some resultant effects:
>>>>>

[openstack-dev] FW: [Bug 1257788] Re: nova-network doesn't handle large amount of concurrent booting instances well

[Edgar Magana]

FYI. Concurrent calls are a problem all around in OpenStack!

Edgar

On 12/10/13 8:47 AM, "Abhishek Chanda"  wrote:

>** Changed in: nova
>   Status: New => Triaged
>
>-- 
>You received this bug notification because you are subscribed to
>neutron.
>https://bugs.launchpad.net/bugs/1257788
>
>Title:
>  nova-network doesn't handle large amount of concurrent booting
>  instances well
>
>Status in OpenStack Neutron (virtual network service):
>  Triaged
>Status in OpenStack Compute (Nova):
>  Triaged
>
>Bug description:
>  As seen by the large-ops test nova-network has trouble booting 150 VMs
>  concurrently. Part of the problem is that setting up the network for
>  each instance is relatively expensive with many locks and root-wrapped
>  calls. Both of which significantly hurt performance.  One possible fix
>  would be to do more bulk network operations when possible, so instead
>  of 100 separate calls to a root-wrapped tool call it once.
>
>To manage notifications about this bug go to:
>https://bugs.launchpad.net/neutron/+bug/1257788/+subscriptions



___
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 plugin testingmeeting

[Edgar Magana]

Also joining!
Looking forward to hearing your ideas folks!

Edgar

On 12/10/13 10:16 AM, "Nachi Ueno"  wrote:

>+1 ! I'll join.
>I'm also working on investigating how to use openstack gating system.
>(This document is still draft version)
>https://docs.google.com/presentation/d/1WJInaSt_H2kVkjnhtPmiATP1F-0BVbuk1e
>efQalL5Q0/edit#slide=id.p
>
>2013/12/10 Ivar Lazzaro :
>> +1 for 1700UTC Thursday on IRC
>>
>> -Original Message-
>> From: Kyle Mestery [mailto:mest...@siliconloons.com]
>> Sent: Tuesday, December 10, 2013 9:21 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin
>>testing meeting
>>
>> On Dec 10, 2013, at 10:45 AM, "Veiga, Anthony"
>> wrote:
>>> -Original Message-
>>> From: Kyle Mestery 
>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>>questions)"
>>> 
>>> Date: Tuesday, December 10, 2013 10:48
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> 
>>> Subject: [openstack-dev] [neutron] Third party Neutron plugin testing
>>> meeting
>>>
 Last week I took an action item to organize a meeting for everyone
 who is doing third-party testing in Neutron for plugins, whether this
 is vendor or Open Source based. The idea is to share ideas around
 setups and any issues people hit. I'd like to set this meeting up for
 this week, Thursday at 1700UTC. I would also like to propose we make
 this a dial in meeting using the Infrastructure Conferencing bridges
 [1]. If this time works, I'll set something up and reply to this
 thread with the dial in information.
>>>
>>> +1 for the meeting time.  Any particular reason for voice over IRC?
>>>
>> We kind of decided that doing this over voice initially would be
>>expedient, but I am fine with moving to IRC. If I don't hear objections,
>>lets assume we will meet at 1700UTC Thursday on #openstack-meeting-alt.
>>
>>

 Also, I've started a etherpad page [2] with information. It would be
 good for people to add information to this etherpad as well. I've
 coupled this pad with information around multi-node gate testing for
 Neutron as well, as I suspect most of the third-party testing will
 require multiple nodes as well.
>>>
>>> I'll start filling out our setup.  I have some questions around
>>> Third-Party Testing in particular, and look forward to this discussion.
>>>
>> Awesome, thanks Anthony!
>>

 Thanks!
 Kyle

 [1] https://wiki.openstack.org/wiki/Infrastructure/Conferencing
 [2] https://etherpad.openstack.org/p/multi-node-neutron-tempest

 ___
 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



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

[openstack-dev] [Neutron] Fix to agents race condition creates another issue

[Edgar Magana]

In commit:
https://review.openstack.org/#/c/58814/

There is an assumption that all "plugins" creates the
plumgrid_neutron.agents which is not the case. I just tested big switch and
plumgrid and they are failing:

INFO  [alembic.migration] Running upgrade havana -> e197124d4b9, add unique
constraint to members
INFO  [alembic.migration] Running upgrade e197124d4b9 -> 1fcfc149aca4, Add
a unique constraint on (agent_type, host) columns to prevent a race
condition when an agent entry is 'upserted'.
Traceback (most recent call last):
  File "/usr/local/bin/neutron-db-manage", line 10, in 
sys.exit(main())
  File "/opt/stack/neutron/neutron/db/migration/cli.py", line 143, in main
CONF.command.func(config, CONF.command.name)
  File "/opt/stack/neutron/neutron/db/migration/cli.py", line 80, in
do_upgrade_downgrade
do_alembic_command(config, cmd, revision, sql=CONF.command.sql)
  File "/opt/stack/neutron/neutron/db/migration/cli.py", line 59, in
do_alembic_command
getattr(alembic_command, cmd)(config, *args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/alembic/command.py", line
124, in upgrade
script.run_env()
  File "/usr/local/lib/python2.7/dist-packages/alembic/script.py", line
193, in run_env
util.load_python_file(self.dir, 'env.py')
  File "/usr/local/lib/python2.7/dist-packages/alembic/util.py", line 177,
in load_python_file
module = load_module(module_id, path)
  File "/usr/local/lib/python2.7/dist-packages/alembic/compat.py", line 39,
in load_module
return imp.load_source(module_id, path, fp)
  File "/opt/stack/neutron/neutron/db/migration/alembic_migrations/env.py",
line 105, in 
run_migrations_online()
  File "/opt/stack/neutron/neutron/db/migration/alembic_migrations/env.py",
line 89, in run_migrations_online
options=build_options())
  File "", line 7, in run_migrations
  File "/usr/local/lib/python2.7/dist-packages/alembic/environment.py",
line 652, in run_migrations
self.get_context().run_migrations(**kw)
  File "/usr/local/lib/python2.7/dist-packages/alembic/migration.py", line
224, in run_migrations
change(**kw)
  File
"/opt/stack/neutron/neutron/db/migration/alembic_migrations/versions/1fcfc149aca4_agents_unique_by_type_and_host.py",
line 50, in upgrade
local_cols=['agent_type', 'host']
  File "", line 7, in create_unique_constraint
  File "/usr/local/lib/python2.7/dist-packages/alembic/operations.py", line
539, in create_unique_constraint
schema=schema, **kw)
  File "/usr/local/lib/python2.7/dist-packages/alembic/ddl/impl.py", line
135, in add_constraint
self._exec(schema.AddConstraint(const))
  File "/usr/local/lib/python2.7/dist-packages/alembic/ddl/impl.py", line
76, in _exec
conn.execute(construct, *multiparams, **params)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py",
line 1449, in execute
params)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py",
line 1542, in _execute_ddl
compiled
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py",
line 1698, in _execute_context
context)
  File "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py",
line 1691, in _execute_context
context)
  File
"/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line
331, in do_execute
cursor.execute(statement, parameters)
  File "/usr/lib/python2.7/dist-packages/MySQLdb/cursors.py", line 174, in
execute
self.errorhandler(self, exc, value)
  File "/usr/lib/python2.7/dist-packages/MySQLdb/connections.py", line 36,
in defaulterrorhandler
raise errorclass, errorvalue
sqlalchemy.exc.ProgrammingError: (ProgrammingError) (1146, "Table
'plumgrid_neutron.agents' doesn't exist") 'ALTER TABLE agents ADD
CONSTRAINT uniq_agents0agent_type0host UNIQUE (agent_type, host)' ()
++ failed
++ local r=1
+++ jobs -p
++ kill
++ set +o xtrace



Is this known issues? If not, let me know and I can properly reported.

Thanks,

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

Re: [openstack-dev] [Neutron] Fix to agents race condition creates another issue

[Edgar Magana]

Ok, I just did it.
https://bugs.launchpad.net/neutron/+bug/1260232

It seems that Yong found the same problem for ML2:
https://bugs.launchpad.net/bugs/1260224

I am just wondering, how come we did not catch this with ML2 when we are
claiming that it is our default plugin.

Edgar



On Wed, Dec 11, 2013 at 10:38 PM, Eugene Nikanorov
wrote:

> Hi, Edgar,
>
> Please file a bug on this. Obviously this was introduced by that commit.
>
> Thanks,
> Eugene.
>
>
> On Thu, Dec 12, 2013 at 7:45 AM, Edgar Magana wrote:
>
>> In commit:
>> https://review.openstack.org/#/c/58814/
>>
>> There is an assumption that all "plugins" creates the
>> plumgrid_neutron.agents which is not the case. I just tested big switch and
>> plumgrid and they are failing:
>>
>> INFO  [alembic.migration] Running upgrade havana -> e197124d4b9, add
>> unique constraint to members
>> INFO  [alembic.migration] Running upgrade e197124d4b9 -> 1fcfc149aca4,
>> Add a unique constraint on (agent_type, host) columns to prevent a race
>> condition when an agent entry is 'upserted'.
>> Traceback (most recent call last):
>>   File "/usr/local/bin/neutron-db-manage", line 10, in 
>> sys.exit(main())
>>   File "/opt/stack/neutron/neutron/db/migration/cli.py", line 143, in main
>> CONF.command.func(config, CONF.command.name)
>>   File "/opt/stack/neutron/neutron/db/migration/cli.py", line 80, in
>> do_upgrade_downgrade
>> do_alembic_command(config, cmd, revision, sql=CONF.command.sql)
>>   File "/opt/stack/neutron/neutron/db/migration/cli.py", line 59, in
>> do_alembic_command
>> getattr(alembic_command, cmd)(config, *args, **kwargs)
>>   File "/usr/local/lib/python2.7/dist-packages/alembic/command.py", line
>> 124, in upgrade
>> script.run_env()
>>   File "/usr/local/lib/python2.7/dist-packages/alembic/script.py", line
>> 193, in run_env
>> util.load_python_file(self.dir, 'env.py')
>>   File "/usr/local/lib/python2.7/dist-packages/alembic/util.py", line
>> 177, in load_python_file
>> module = load_module(module_id, path)
>>   File "/usr/local/lib/python2.7/dist-packages/alembic/compat.py", line
>> 39, in load_module
>> return imp.load_source(module_id, path, fp)
>>   File
>> "/opt/stack/neutron/neutron/db/migration/alembic_migrations/env.py", line
>> 105, in 
>> run_migrations_online()
>>   File
>> "/opt/stack/neutron/neutron/db/migration/alembic_migrations/env.py", line
>> 89, in run_migrations_online
>> options=build_options())
>>   File "", line 7, in run_migrations
>>   File "/usr/local/lib/python2.7/dist-packages/alembic/environment.py",
>> line 652, in run_migrations
>> self.get_context().run_migrations(**kw)
>>   File "/usr/local/lib/python2.7/dist-packages/alembic/migration.py",
>> line 224, in run_migrations
>> change(**kw)
>>   File
>> "/opt/stack/neutron/neutron/db/migration/alembic_migrations/versions/1fcfc149aca4_agents_unique_by_type_and_host.py",
>> line 50, in upgrade
>> local_cols=['agent_type', 'host']
>>   File "", line 7, in create_unique_constraint
>>   File "/usr/local/lib/python2.7/dist-packages/alembic/operations.py",
>> line 539, in create_unique_constraint
>> schema=schema, **kw)
>>   File "/usr/local/lib/python2.7/dist-packages/alembic/ddl/impl.py", line
>> 135, in add_constraint
>> self._exec(schema.AddConstraint(const))
>>   File "/usr/local/lib/python2.7/dist-packages/alembic/ddl/impl.py", line
>> 76, in _exec
>> conn.execute(construct, *multiparams, **params)
>>   File
>> "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line
>> 1449, in execute
>> params)
>>   File
>> "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line
>> 1542, in _execute_ddl
>> compiled
>>   File
>> "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line
>> 1698, in _execute_context
>> context)
>>   File
>> "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line
>> 1691, in _execute_context
>> context)
>>   File
>> "/usr/local/lib/python2.7/dist-packages/sqlalchemy/engine/default.py", line
>> 331, in do_execute
>> cursor.execute(statement, parameters)
>>   File "/usr/lib/pyth

Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

[Edgar Magana]

Anita,

Fawad and Myself will be also attending.

BTW. Fawad will require an invitation letter for visa. He will email you
directly with that request.

Thanks,

Edgar


On Wed, Dec 18, 2013 at 1:17 PM, Anita Kuno  wrote:

> Okay time for a recap.
>
> What: Neutron Tempest code sprint
> Where: Montreal, QC, Canada
> When: January 15, 16, 17 2014
> Location: I am about to sign the contract for Salle du Parc at 3625 Parc
> avenue, a room in a residence of McGill University.
> Time: 9am - 5am
>
> I am expecting to see the following people in Montreal in January:
> Mark McClain
> Salvatore Orlando
> Sean Dague
> Matt Trenish
> Jay Pipes
> Sukhdev Kapur
> Miguel Lavelle
> Oleg Bondarev
> Rossella Sblendido
> Emilien Macchi
> Sylvain Afchain
> Nicolas Planel
> Kyle Mestery
> Dane Leblanc
> Sumit Naiksatam
> Henry Gessau
> Don Kehn
> Carl Baldwin
> Justin Hammond
> Anita Kuno
>
> If you are on the above list and can't attend, please email me so I have
> an up-to-date list. If you are planning on attending and I don't have
> your name listed, please email me without delay so that I can add you
> and you get done what you need to get done to attend.
>
> I have the contract for the room and will be signing it and sending it
> in with the room deposit tomorrow. Monty has about 6 more hours to get
> back to me on this, then I just have to go ahead and do it.
>
> Caterer is booked and I will be doing menu selection over the holidays.
> I can post the intended, _the intended_ menu once I have decided. Soup,
> salad, sandwich - not glamourous but hopefully filling. If the menu on
> the day isn't the same as what I post, please forgive me. Unforeseen
> circumstances may crop up and I will do my best to get you fed. One
> person has identified they have a specific food request, if there are
> any more out there, please email me now. This covers breakfast, lunch
> and tea/coffee all day.
>
> Henry Gessau will be social convener for dinners. If you have some
> restaurant suggestions, please contact Henry. Organization of dinners
> will take place once we congregate in our meeting room.
>
> T-shirts: we decided that the code quality of Neutron was a higher
> priority than t-shirts.
>
> One person required a letter of invitation for visa purposes and
> received it. I hope the visa has been granted.
>
> Individuals arrangements for hotels seem to be going well from what I
> have been hearing. A few people will be staying at Le Nouvel Hotel,
> thanks for finding that one, Rosella.
>
> Weather: well you got me on this one. This winter is colder than we have
> had in some time and more snow too. So it will be beautiful but bring or
> buy warm clothes. A few suggestions:
> * layer your clothes (t-shirt, turtleneck, sweatshirt)
> * boots with removable liners (this is my boot of choice:
> http://amzn.to/19ddJve) remove the liners at the end of each day to dry
> them
> * warm coat
> * toque (wool unless you are allergic) I'm seeing them for $35, don't
> pay that much, you should be able to get something warm for $15 or less
> * warm socks (cotton socks and wool over top)- keep your feet dry
> * mitts (mitts keep my fingers warmer than gloves)
> * scarf
> If the weather is making you panic, talk to me and I will see about
> bringing some of my extra accessories with me. The style might not be
> you but you will be warm.
>
> Remember, don't lick the flagpole. It doesn't matter what your friends
> tell you.
>
> That's all I can think of, if I missed something, email me.
>
> Oh, and best to consider me offline from Jan.2 until the code sprint.
> Make sure you have all the information you need prior to that time.
>
> See you in Montreal,
> Anita.
>
>
> On 11/19/2013 11:31 AM, Rossella Sblendido wrote:
> > Hi all,
> >
> > sorry if this is a bit OT now.
> > I contacted some hotels to see if we could get a special price if we book
> > many rooms. According to my research the difference in price is not much.
> > Also, as Anita was saying, booking for everybody is more complicated.
> > So I decided to booked a room for myself.
> > I share the name of the hotel, in case you want to stay in the same place
> > http://www.lenouvelhotel.com/<
> http://www.booking.com/hotel/ca/le-nouvel-spa.html?aid=318615&label=postbooking_confemail&pbsource=conf_email_hotel_name&et=UmFuZG9tSVYkc2RlIyh9YQkLIKuQhwqabGHP/3dl6rJzqy0AqLilEWRB9q2h3N7LbLpnopp78jpk3Zrw8QEON8/7uGk2Z4XEVgx0jMidsc7G6J6/mpIjb0/tpL+TyUzh/SougdT7JVfQN96wrY/Uz9Cu068o86et5KaL1N1ikBA2yvj25PBlFEF+/iBPj8Nq
> >.
> > It's close to the meeting room and the price is one of the best I have
> > found.
> >
> > cheers,
> >
> > Rossella
> >
> >
> >
> >
> > On Sat, Nov 16, 2013 at 7:39 PM, Anita Kuno 
> wrote:
> >
> >>  On 11/16/2013 01:14 PM, Anita Kuno wrote:
> >>
> >> On 11/16/2013 12:37 PM, Sean Dague wrote:
> >>
> >> On 11/15/2013 10:36 AM, Russell Bryant wrote:
> >>
> >>  On 11/13/2013 11:10 AM, Anita Kuno wrote:
> >>
> >>  Neutron Tempest code sprint
> >>
> >> In the second week of January in Montreal, 

Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

[Edgar Magana]

Anita,

Did you get my email with my confirmation?

Thanks,

Edgar


On Thu, Dec 19, 2013 at 4:02 PM, Edgar Magana  wrote:

> Anita,
>
> Fawad and Myself will be also attending.
>
> BTW. Fawad will require an invitation letter for visa. He will email you
> directly with that request.
>
> Thanks,
>
> Edgar
>
>
> On Wed, Dec 18, 2013 at 1:17 PM, Anita Kuno  wrote:
>
>> Okay time for a recap.
>>
>> What: Neutron Tempest code sprint
>> Where: Montreal, QC, Canada
>> When: January 15, 16, 17 2014
>> Location: I am about to sign the contract for Salle du Parc at 3625 Parc
>> avenue, a room in a residence of McGill University.
>> Time: 9am - 5am
>>
>> I am expecting to see the following people in Montreal in January:
>> Mark McClain
>> Salvatore Orlando
>> Sean Dague
>> Matt Trenish
>> Jay Pipes
>> Sukhdev Kapur
>> Miguel Lavelle
>> Oleg Bondarev
>> Rossella Sblendido
>> Emilien Macchi
>> Sylvain Afchain
>> Nicolas Planel
>> Kyle Mestery
>> Dane Leblanc
>> Sumit Naiksatam
>> Henry Gessau
>> Don Kehn
>> Carl Baldwin
>> Justin Hammond
>> Anita Kuno
>>
>> If you are on the above list and can't attend, please email me so I have
>> an up-to-date list. If you are planning on attending and I don't have
>> your name listed, please email me without delay so that I can add you
>> and you get done what you need to get done to attend.
>>
>> I have the contract for the room and will be signing it and sending it
>> in with the room deposit tomorrow. Monty has about 6 more hours to get
>> back to me on this, then I just have to go ahead and do it.
>>
>> Caterer is booked and I will be doing menu selection over the holidays.
>> I can post the intended, _the intended_ menu once I have decided. Soup,
>> salad, sandwich - not glamourous but hopefully filling. If the menu on
>> the day isn't the same as what I post, please forgive me. Unforeseen
>> circumstances may crop up and I will do my best to get you fed. One
>> person has identified they have a specific food request, if there are
>> any more out there, please email me now. This covers breakfast, lunch
>> and tea/coffee all day.
>>
>> Henry Gessau will be social convener for dinners. If you have some
>> restaurant suggestions, please contact Henry. Organization of dinners
>> will take place once we congregate in our meeting room.
>>
>> T-shirts: we decided that the code quality of Neutron was a higher
>> priority than t-shirts.
>>
>> One person required a letter of invitation for visa purposes and
>> received it. I hope the visa has been granted.
>>
>> Individuals arrangements for hotels seem to be going well from what I
>> have been hearing. A few people will be staying at Le Nouvel Hotel,
>> thanks for finding that one, Rosella.
>>
>> Weather: well you got me on this one. This winter is colder than we have
>> had in some time and more snow too. So it will be beautiful but bring or
>> buy warm clothes. A few suggestions:
>> * layer your clothes (t-shirt, turtleneck, sweatshirt)
>> * boots with removable liners (this is my boot of choice:
>> http://amzn.to/19ddJve) remove the liners at the end of each day to dry
>> them
>> * warm coat
>> * toque (wool unless you are allergic) I'm seeing them for $35, don't
>> pay that much, you should be able to get something warm for $15 or less
>> * warm socks (cotton socks and wool over top)- keep your feet dry
>> * mitts (mitts keep my fingers warmer than gloves)
>> * scarf
>> If the weather is making you panic, talk to me and I will see about
>> bringing some of my extra accessories with me. The style might not be
>> you but you will be warm.
>>
>> Remember, don't lick the flagpole. It doesn't matter what your friends
>> tell you.
>>
>> That's all I can think of, if I missed something, email me.
>>
>> Oh, and best to consider me offline from Jan.2 until the code sprint.
>> Make sure you have all the information you need prior to that time.
>>
>> See you in Montreal,
>> Anita.
>>
>>
>> On 11/19/2013 11:31 AM, Rossella Sblendido wrote:
>> > Hi all,
>> >
>> > sorry if this is a bit OT now.
>> > I contacted some hotels to see if we could get a special price if we
>> book
>> > many rooms. According to my research the difference in price is not
>> much.
>> > Also, as Anita was saying, booking for everybody is more complicated.
>> > So I decid

Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

[Edgar Magana]

Mark,

We do not disagree with you. The main reason was indeed to onboard new
developers in Neutron. I will help Fawad on his introduction before and
after the sprint, therefore you should start seeing some code reviews and
code commitments from him ASAP.

Thanks,

Edgar


On Fri, Dec 20, 2013 at 1:42 PM, Mark McClain wrote:

> Edgar-
>
> I’m a bit concerned about Fawad joining the sprint.  He’s a new
> contributor who has never landed a patch in Neutron or Tempest.  Closing
> the testing gaps with experienced devs is the goal of the Montreal sprint
> and I do not think we’ll have manpower to onboard new contributors (3 days
> is a really short time).  While I’m happy to welcome more workers there, I
> do not want to waste his time or PLUMgrid’s resources.
>
> mark
>
> On Dec 19, 2013, at 7:02 PM, Edgar Magana  wrote:
>
> Anita,
>
> Fawad and Myself will be also attending.
>
> BTW. Fawad will require an invitation letter for visa. He will email you
> directly with that request.
>
> Thanks,
>
> Edgar
>
>
> On Wed, Dec 18, 2013 at 1:17 PM, Anita Kuno  wrote:
>
>> Okay time for a recap.
>>
>> What: Neutron Tempest code sprint
>> Where: Montreal, QC, Canada
>> When: January 15, 16, 17 2014
>> Location: I am about to sign the contract for Salle du Parc at 3625 Parc
>> avenue, a room in a residence of McGill University.
>> Time: 9am - 5am
>>
>> I am expecting to see the following people in Montreal in January:
>> Mark McClain
>> Salvatore Orlando
>> Sean Dague
>> Matt Trenish
>> Jay Pipes
>> Sukhdev Kapur
>> Miguel Lavelle
>> Oleg Bondarev
>> Rossella Sblendido
>> Emilien Macchi
>> Sylvain Afchain
>> Nicolas Planel
>> Kyle Mestery
>> Dane Leblanc
>> Sumit Naiksatam
>> Henry Gessau
>> Don Kehn
>> Carl Baldwin
>> Justin Hammond
>> Anita Kuno
>>
>> If you are on the above list and can't attend, please email me so I have
>> an up-to-date list. If you are planning on attending and I don't have
>> your name listed, please email me without delay so that I can add you
>> and you get done what you need to get done to attend.
>>
>> I have the contract for the room and will be signing it and sending it
>> in with the room deposit tomorrow. Monty has about 6 more hours to get
>> back to me on this, then I just have to go ahead and do it.
>>
>> Caterer is booked and I will be doing menu selection over the holidays.
>> I can post the intended, _the intended_ menu once I have decided. Soup,
>> salad, sandwich - not glamourous but hopefully filling. If the menu on
>> the day isn't the same as what I post, please forgive me. Unforeseen
>> circumstances may crop up and I will do my best to get you fed. One
>> person has identified they have a specific food request, if there are
>> any more out there, please email me now. This covers breakfast, lunch
>> and tea/coffee all day.
>>
>> Henry Gessau will be social convener for dinners. If you have some
>> restaurant suggestions, please contact Henry. Organization of dinners
>> will take place once we congregate in our meeting room.
>>
>> T-shirts: we decided that the code quality of Neutron was a higher
>> priority than t-shirts.
>>
>> One person required a letter of invitation for visa purposes and
>> received it. I hope the visa has been granted.
>>
>> Individuals arrangements for hotels seem to be going well from what I
>> have been hearing. A few people will be staying at Le Nouvel Hotel,
>> thanks for finding that one, Rosella.
>>
>> Weather: well you got me on this one. This winter is colder than we have
>> had in some time and more snow too. So it will be beautiful but bring or
>> buy warm clothes. A few suggestions:
>> * layer your clothes (t-shirt, turtleneck, sweatshirt)
>> * boots with removable liners (this is my boot of choice:
>> http://amzn.to/19ddJve) remove the liners at the end of each day to dry
>> them
>> * warm coat
>> * toque (wool unless you are allergic) I'm seeing them for $35, don't
>> pay that much, you should be able to get something warm for $15 or less
>> * warm socks (cotton socks and wool over top)- keep your feet dry
>> * mitts (mitts keep my fingers warmer than gloves)
>> * scarf
>> If the weather is making you panic, talk to me and I will see about
>> bringing some of my extra accessories with me. The style might not be
>> you but you will be warm.
>>
>> Remember, don't lick the flagpole. It doesn't matter what your friends
>> tell you.
>>
>&

Re: [openstack-dev] [neutron] [third-party-testing] Sharing information

[Edgar Magana]

I like it and I am in favor. 
Some of us, will be in Montreal attending the sprint tempest session. Hopefully 
we can all take it from there. 

Edgar

> On Jan 14, 2014, at 6:31 AM, Kyle Mestery  wrote:
> 
> Thanks for sending this note Mohammad. I am all in favor of another
> 3rd party testing meeting on IRC. How about if we shoot for tomorrow,
> Wednesday the 15, at 2200 UTC? Please ack if that works for everyone.
> 
> Thanks,
> Kyle
> 
>> On Jan 13, 2014, at 5:08 PM, Mohammad Banikazemi  wrote:
>> 
>> Hi everybody,
>> 
>> I see that we already have at least two 3rd party testing setups (from 
>> Arista and Midokura) up and running. Noticed their votes on our newly 
>> submitted plugin.
>> The etherpad which is to be used for sharing information about setting up 
>> 3rd party testing (as well as multi-node testing) [1] seems to have not been 
>> updated recently. Would those who have setup their 3rd party testing 
>> successfully be willing to share more information as to what they have done 
>> and possibly update the etherpad?
>> 
>> Would it be of value to others if we have another IRC meeting to discuss 
>> this matter? 
>> (Kyle, I am sure you are busy so I took the liberty to send this note. 
>> Please let us know what you think.)
>> 
>> Thanks,
>> 
>> Mohammad
>> 
>> 
>> [1] https://etherpad.openstack.org/p/multi-node-neutron-tempest 
>> 
>> Kyle Mestery ---12/19/2013 09:17:44 AM---Apologies folks, I 
>> meant 2200 UTC Thursday. We'll still do the meeting today.
>> 
>> From:Kyle Mestery 
>> To:"OpenStack Development Mailing List \(not for usage questions\)" 
>> , 
>> Date:12/19/2013 09:17 AM
>> Subject:Re: [openstack-dev] [neutron] [third-party-testing] Reminder:
>> Meeting tomorrow
>> 
>> 
>> 
>> Apologies folks, I meant 2200 UTC Thursday. We'll still do the
>> meeting today.
>> 
>>> On Dec 18, 2013, at 4:40 PM, Don Kehn  wrote:
>>> 
>>> Wouldn't 2200 UTC be in about 20 mins?
>>> 
>>> 
>>> On Wed, Dec 18, 2013 at 3:32 PM, Itsuro ODA  wrote:
>>> Hi,
>>> 
>>> It seems the meeting was not held on 2200 UTC on Wednesday (today).
>>> 
>>> Do you mean 2200 UTC on Thursday ?
>>> 
>>> Thanks.
>>> 
>>> On Thu, 12 Dec 2013 11:43:03 -0600
>>> Kyle Mestery  wrote:
>>> 
 Hi everyone:
 
 We had a meeting around Neutron Third-Party testing today on IRC.
 The logs are available here [1]. We plan to host another meeting
 next week, and it will be at 2200 UTC on Wednesday in the
 #openstack-meeting-alt channel on IRC. Please attend and update
 the etherpad [2] with any items relevant to you before then.
 
 Thanks again!
 Kyle
 
 [1] 
 http://eavesdrop.openstack.org/meetings/networking_third_party_testing/2013/
 [2] https://etherpad.openstack.org/p/multi-node-neutron-tempest
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> On Wed, 18 Dec 2013 15:10:46 -0600
>>> Kyle Mestery  wrote:
>>> 
 Just a reminder, we'll be meeting at 2200 UTC on #openstack-meeting-alt.
 We'll be looking at this etherpad [1] again, and continuing discussions 
 from
 last week.
 
 Thanks!
 Kyle
 
 [1] https://etherpad.openstack.org/p/multi-node-neutron-tempest
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> --
>>> Itsuro ODA 
>>> 
>>> 
>>> ___
>>> OpenStack-dev mailing list
>>> OpenStack-dev@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>>> 
>>> 
>>> -- 
>>> 
>>> Don Kehn
>>> 303-442-0060
>>> ___
>>> 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] Neutron should disallow /32 CIDR

[Edgar Magana]

Wouldn't be easier just to check if:

cidr is 32?

 I believe it is a good idea to not allow /32 network but this is just my
opinion

Edgar

From:  Paul Ward 
Reply-To:  OpenStack List 
Date:  Tuesday, January 21, 2014 12:35 PM
To:  OpenStack List 
Subject:  [openstack-dev] [neutron] Neutron should disallow /32 CIDR

Currently, NeutronDbPluginV2._validate_allocation_pools() does some very
basic checking to be sure the specified subnet is valid.  One thing that's
missing is checking for a CIDR of /32.  A subnet with one IP address in it
is unusable as the sole IP address will be allocated to the gateway, and
thus no IPs are left over to be allocated to VMs.

The fix for this is simple.  In
NeutronDbPluginV2._validate_allocation_pools(), we'd check for start_ip ==
end_ip and raise an exception if that's true.

I've opened lauchpad bug report 1271311
(https://bugs.launchpad.net/neutron/+bug/1271311) for this, but wanted to
start a discussion here to see if others find this enhancement to be a
valuable addition.
___ 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] [Fwd: Change in openstack/neutron[master]: Kill dnsmasq and ns-meta softly]

[Edgar Magana]

No doubt about it!!!

Edgar

On 1/28/14 8:45 AM, "Jay Pipes"  wrote:

>This might just be the most creative commit message of the year.
>
>-jay
>___
>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] Neutron should disallow /32 CIDR

[Edgar Magana]

Well say Carl!
I am sorry I did not get back to you on this topic before.
In general and after thinking about it, it makes sense to leave could
admin to adage the /32 cases if any.

Edgar

On 1/28/14 1:46 PM, "Carl Baldwin"  wrote:

>I think I agree.  The new check isn't adding much value and we could
>debate for a long time whether /30 is useful and should be disallowed
>or not.  There are bigger fish to fry.
>
>Carl
>
>On Fri, Jan 24, 2014 at 10:43 AM, Paul Ward  wrote:
>> Given your obviously much more extensive understanding of networking
>>than
>> mine, I'm starting to move over to the "we shouldn't make this fix"
>>camp.
>> Mostly because of this:
>>
>> "CARVER, PAUL"  wrote on 01/23/2014 08:57:10 PM:
>>
>>
>>
>>> Putting a friendly helper in Horizon will help novice users and
>>> provide a good example to anyone who is developing an alternate UI
>>> to invoke the Neutron API. I¹m not sure what the benefit is of
>>> putting code in the backend to disallow valid but silly subnet
>>> masks. I include /30, /31, AND /32 in the category of ³silly² subnet
>>> masks to use on a broadcast medium. All three are entirely
>>> legitimate subnet masks, it¹s just that they¹re not useful for end
>>> host networks.
>>
>> My mindset has always been that we should programmatically prevent
>>things
>> that are definitively wrong.  Of which, these netmasks apparently are
>>not.
>> So it would seem we should leave neutron server code alone under the
>> assumption that those using CLI to create networks *probably* know what
>> they're doing.
>>
>> However, the UI is supposed to be the more friendly interface and
>>perhaps
>> this is the more appropriate place for this change?  As I stated before,
>> horizon prevents /32, but allows /31.
>>
>> I'm no UI guy, so maybe the best course of action is to abandon my
>>change in
>> gerrit and move the launchpad bug back to unassigned and see if someone
>>with
>> horizon experience wants to pick this up.  What do others think about
>>this?
>>
>> Thanks again for your participation in this discussion, Paul.  It's been
>> very enlightening to me.
>>
>>
>> ___
>> 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] Nominate Oleg Bondarev for Core

[Edgar Magana]

+1 of course!

Edgar 

Sent from my iPhone

> On Feb 11, 2014, at 8:28 AM, Mark McClain  wrote:
> 
> All-
> 
> I’d like to nominate Oleg Bondarev to become a Neutron core reviewer.  Oleg 
> has been valuable contributor to Neutron by actively reviewing, working on 
> bugs, and contributing code.
> 
> Neutron cores please reply back with +1/0/-1 votes.
> 
> mark
> ___
> 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] Nominate Oleg Bondarev for Core

[Edgar Magana]

Congratulations Oleg!!!

No need for welcoming you to the team, you were already part of  ;-)

Edgar

From:  Oleg Bondarev 
Reply-To:  OpenStack List 
Date:  Thursday, February 20, 2014 6:43 AM
To:  OpenStack List 
Subject:  Re: [openstack-dev] [Neutron] Nominate Oleg Bondarev for Core

Thanks Mark,

thanks everyone for voiting! I'm so happy to become a member of this really
great team!

Oleg


On Thu, Feb 20, 2014 at 6:29 PM, Mark McClain 
wrote:
>  I¹d like to welcome Oleg as member of the core Neutron team as he has
> received more than enough +1s and no negative votes from the other cores.
> 
> mark
> 
> On Feb 10, 2014, at 6:28 PM, Mark McClain  wrote:
> 
>> > All-
>> >
>> > I¹d like to nominate Oleg Bondarev to become a Neutron core reviewer.  Oleg
>> has been valuable contributor to Neutron by actively reviewing, working on
>> bugs, and contributing code.
>> >
>> > Neutron cores please reply back with +1/0/-1 votes.
>> >
>> > mark
>> > ___
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

Re: [openstack-dev] [Nova][Neutron] Error message when Neutron network is running out of IP addresses

[Edgar Magana]

Ok, I will open a bug and commit a patch!  :-)

Edgar

From: Vishvananda Ishaya mailto:vishvana...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, November 18, 2014 at 3:27 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Nova][Neutron] Error message when Neutron network 
is running out of IP addresses

It looks like this has not been reported so a bug would be great. It looks like 
it might be as easy as adding the NoMoreFixedIps exception to the list where 
FixedIpLimitExceeded is caught in nova/network/manager.py

Vish

On Nov 18, 2014, at 8:13 AM, Edgar Magana 
mailto:edgar.mag...@workday.com>> wrote:

Hello Community,

When a network subnet runs out of IP addresses a request to create a VM on that 
network fails with the Error message: "No valid host was found. There are not 
enough hosts available."
In the nova logs the error message is: NoMoreFixedIps: No fixed IP addresses 
available for network:

Obviously, this is not the desirable behavior, is there any work in progress to 
change it or I should open a bug to properly propagate the right error message.

Thanks,

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

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

Re: [openstack-dev] [Nova][Neutron] Error message when Neutron network is running out of IP addresses

[Edgar Magana]

Nova People,

In Havana the behavior of this issue was different, basically the VM was 
successfully created and after trying multiple times to get an IP the state was 
changed to ERROR.
This behavior is different in Juno (currently testing Icehouse) but I am not 
able to find the bug fix.
As an operator this is really important, anyone can help me to find the fix 
that I just described above?

Thanks,

Edgar

From: Vishvananda Ishaya mailto:vishvana...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, November 18, 2014 at 3:27 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Nova][Neutron] Error message when Neutron network 
is running out of IP addresses

It looks like this has not been reported so a bug would be great. It looks like 
it might be as easy as adding the NoMoreFixedIps exception to the list where 
FixedIpLimitExceeded is caught in nova/network/manager.py

Vish

On Nov 18, 2014, at 8:13 AM, Edgar Magana 
mailto:edgar.mag...@workday.com>> wrote:

Hello Community,

When a network subnet runs out of IP addresses a request to create a VM on that 
network fails with the Error message: "No valid host was found. There are not 
enough hosts available."
In the nova logs the error message is: NoMoreFixedIps: No fixed IP addresses 
available for network:

Obviously, this is not the desirable behavior, is there any work in progress to 
change it or I should open a bug to properly propagate the right error message.

Thanks,

Edgar
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto: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] Bug day

[Edgar Magana]

Great progress! Thanks for this huge effort.

Edgar

From: Eugene Nikanorov mailto:enikano...@mirantis.com>>
Reply-To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Date: Monday, November 24, 2014 at 1:52 AM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Bug day

Hi again,

I'd like to share some results of the bug day we've conducted on 2014-11-21.
Stats:

  *   73 New 
bugs
  *   795 Open bugs
  *   285 In-progress 
bugs

I personally went over some opened/new bugs with High/Medium importance, trying 
to detect duplicates, get rid of some bugs that were not active for too long 
(like ones that have been filed back in 2013), pinging submitters to provide 
more info and such.

I've also moved some bugs from 'In progress' to 'New' or 'Confirmed' and 
removed assignees if their submitted patches were either abandoned or have not 
been updated for months.
So don't be surprised if I've removed someone. As Russel Bryant has mentioned, 
assignment might potentially discourage people from looking into the bug.

Thanks everyone for helping with this!

Eugene.

On Fri, Nov 21, 2014 at 11:03 AM, Eugene Nikanorov 
mailto:enikano...@mirantis.com>> wrote:
Hi neutron folks!

Today we've decided to conduct bug triaging day.
We have more than one thousand bugs needing their state to be checked.
So everyone is welcome to participate!

The goals of bug triaging day are:
1) Decrease the number of New bugs.
Possible 'resolution' would be:
 - confirm bug. If you see the issue in the code, or you can reproduce it
 - mark as Incomplete. Bug description doesn't contain sufficient information 
to triage the bug.
 - mark as Invalid. Not a bug, or we're not going to fix it.
 - mark as duplicate. If you know that other bug filed earlier is describing 
the same issue.
 - mark as Fix committed if you know that the issue was fixed. It's good if you 
could provide a link to corresponding review.

2) Check the Open and In progress bugs.
If the last activity on the bug happened more than a month ago - it makes sense 
sometimes to bring it back to 'New'.
By activity I mean comments in the bug, actively maintained patch on review, 
and such.

Of course feel free to assign a bug to yourself if you know how and going to 
fix it.

Some statistics:

  *   85 New 
bugs
  *   811 Open bugs
  *   331 In-progress 
bugs

Thanks,
Eugene.


___
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

[Edgar Magana]

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

Re: [openstack-dev] [neutron] Services are now split out and neutron is open for commits!

[Edgar Magana]

Great Work Team!

Congratulations..

Edgar

From: Kyle Mestery mailto:mest...@mestery.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, December 10, 2014 at 3:10 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [neutron] Services are now split out and neutron is 
open for commits!

Folks, just a heads up that we have completed splitting out the services 
(FWaaS, LBaaS, and VPNaaS) into separate repositores. [1] [2] [3]. This was all 
done in accordance with the spec approved here [4]. Thanks to all involved, but 
a special thanks to Doug and Anita, as well as infra. Without all of their work 
and help, this wouldn't have been possible!

Neutron and the services repositories are now open for merges again. We're 
going to be landing some major L3 agent refactoring across the 4 repositories 
in the next four days, look for Carl to be leading that work with the L3 team.

In the meantime, please report any issues you have in launchpad [5] as bugs, 
and find people in #openstack-neutron or send an email. We've verified things 
come up and all the tempest and API tests for basic neutron work fine.

In the coming week, we'll be getting all the tests working for the services 
repositories. Medium term, we need to also move all the advanced services 
tempest tests out of tempest and into the respective repositories. We also need 
to beef these tests up considerably, so if you want to help out on a critical 
project for Neutron, please let me know.

Thanks!
Kyle

[1] http://git.openstack.org/cgit/openstack/neutron-fwaas
[2] http://git.openstack.org/cgit/openstack/neutron-lbaas
[3] http://git.openstack.org/cgit/openstack/neutron-vpnaas
[4] 
http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/kilo/services-split.rst
[5] https://bugs.launchpad.net/neutron
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] #PERSONAL# : Git checkout command for Blueprints submission

[Edgar Magana]

It is git checkout -b bp/

Edgar

From: Swati Shukla1 mailto:swati.shuk...@tcs.com>>
Reply-To: 
"openstack-dev@lists.openstack.org" 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, December 16, 2014 at 10:53 PM
To: 
"openstack-dev@lists.openstack.org" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] #PERSONAL# : Git checkout command for Blueprints 
submission


Hi All,

Generally, for bug submissions, we use ""git checkout -b bug/""

What is the similar 'git checkout' command for blueprints submission?

Swati Shukla
Tata Consultancy Services
Mailto: swati.shuk...@tcs.com
Website: http://www.tcs.com

Experience certainty. IT Services
Business Solutions
Consulting


=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain
confidential or privileged information. If you are
not the intended recipient, any dissemination, use,
review, distribution, printing or copying of the
information contained in this e-mail message
and/or attachments to it are strictly prohibited. If
you have received this communication in error,
please notify us by reply e-mail or telephone and
immediately and permanently delete the message
and any attachments. Thank you
___
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

[Edgar Magana]

+1 For adding Doug as Core in Neutron!

I have seen his work on the services part and he is a great member of the 
OpenStack community!

Edgar

From: Kyle Mestery mailto:mest...@mestery.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, January 15, 2015 at 2:31 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [neutron] Changes to the core team

The last time we looked at core reviewer stats was in December [1]. In looking 
at the current stats, I'm going to propose some changes to the 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 90 day period [2] indicate 
some changes are needed for core reviewers who are no longer reviewing on pace 
with the other core reviewers.

First of all, I'm removing Sumit Naiksatam from neutron-core. Sumit has been a 
core reviewer for a long time, and his past contributions are very much thanked 
by the entire OpenStack Neutron team. If Sumit jumps back in with thoughtful 
reviews in the future, we can look at getting him back as a Neutron core 
reviewer. But for now, his stats indicate he's not reviewing at a level 
consistent with the rest of the Neutron core reviewers.

As part of the change, I'd like to propose Doug Wiegley as a new Neutron core 
reviewer. Doug has been actively reviewing code across not only all the Neutron 
projects, but also other projects such as infra. His help and work in the 
services split in December were the reason we were so successful in making that 
happen. Doug has also been instrumental in the Neutron LBaaS V2 rollout, as 
well as helping to merge code in the other neutron service repositories.

I'd also like to take this time to remind everyone that reviewing code is a 
responsibility, in Neutron the same as other projects. And core reviewers are 
especially beholden to this responsibility. I'd also like to point out that 
+1/-1 reviews are very useful, and I encourage everyone to continue reviewing 
code even if you are not a core reviewer.

Existing neutron cores, please vote +1/-1 for the addition of Doug to the core 
team.

Thanks!
Kyle

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-December/051986.html
[2] http://russellbryant.net/openstack-stats/neutron-reviewers-90.txt
__
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]

[Edgar Magana]

Nader,

I would encourage you to first discuss the possible extension with the ML2
team. Rober and Kyle are leading this effort and they have a IRC meeting
every week:
https://wiki.openstack.org/wiki/Meetings#ML2_Network_sub-team_meeting

Bring your concerns on this meeting and get the right feedback.

Thanks,

Edgar

From:  Nader Lahouti 
Reply-To:  OpenStack List 
Date:  Thursday, March 6, 2014 12:14 PM
To:  OpenStack List 
Subject:  Re: [openstack-dev] [Neutron][ML2]

Hi Aaron,

I appreciate your reply.

Here is some more details on what I'm trying to do:
I need to add new attribute to the network resource using extensions (i.e.
network config profile) and use it in the mechanism driver (in the
create_network_precommit/postcommit).
If I use current implementation of Ml2Plugin, when a call is made to
mechanism driver's create_network_precommit/postcommit the new attribute is
not included in the 'mech_context'
Here is code from Ml2Plugin:
class Ml2Plugin(...):
...
   def create_network(self, context, network):
net_data = network['network']
...
with session.begin(subtransactions=True):
self._ensure_default_security_group(context, tenant_id)
result = super(Ml2Plugin, self).create_network(context, network)
network_id = result['id']
...
mech_context = driver_context.NetworkContext(self, context,
result)
self.mechanism_manager.create_network_precommit(mech_context)

Also need to include new extension in the  _supported_extension_aliases.

So to avoid changes in the existing code, I was going to create my own
plugin (which will be very similar to Ml2Plugin) and use it as core_plugin.

Please advise the right solution implementing that.

Regards,
Nader.


On Wed, Mar 5, 2014 at 11:49 PM, Aaron Rosen  wrote:
> Hi Nader, 
> 
> Devstack's default plugin is ML2. Usually you wouldn't 'inherit' one plugin in
> another. I'm guessing  you probably wire a driver that ML2 can use though it's
> hard to tell from the information you've provided what you're trying to do.
> 
> Best, 
> 
> Aaron
> 
> 
> On Wed, Mar 5, 2014 at 10:42 PM, Nader Lahouti 
> wrote:
>> Hi All,
>> 
>> I have a question regarding ML2 plugin in neutron:
>> My understanding is that, 'Ml2Plugin' is the default core_plugin for neutron
>> ML2. We can use either the default plugin or our own plugin (i.e.
>> my_ml2_core_plugin that can be inherited from Ml2Plugin) and use it as
>> core_plugin.
>> 
>> Is my understanding correct?
>> 
>> 
>> Regards,
>> Nader.
>> 
>> ___
>> 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] [devstack] [neutron] How to tell a compute host the control host is running Neutron

[Edgar Magana]

Kyle,

Please, point me to the wiki with the documentation for testing the
devstack patch!
This work seems to be very interesting. Yeah!!! I love to have one more
agent less but let's have all agents gone once for all.  :-)

Edgar

On 3/6/14 8:24 AM, "Akihiro Motoki"  wrote:

>Hi Kyle,
>
>I am happy to hear OpenDaylight installation and startup are restored
>to devstack.
>It really helps openstack integration with other open source based
>software.
>
>I have a question on a file location for non-OpenStack open source
>software.
>when I refactored neutron related devstack code, we placed files related
>to
>such files to lib/neutron_thirdparty directory.
>I would like to know the new policy of file locations for such software.
>I understand it is limited to neutron and it may happens to other
>projects.
>
>Thanks,
>Akihiro
>
>
>On Thu, Mar 6, 2014 at 11:19 PM, Kyle Mestery 
>wrote:
>> On Tue, Mar 4, 2014 at 7:34 AM, Kyle Mestery 
>> wrote:
>>>
>>> On Tue, Mar 4, 2014 at 5:46 AM, Sean Dague  wrote:

 On 03/03/2014 11:32 PM, Dean Troyer wrote:
 > On Mon, Mar 3, 2014 at 8:36 PM, Kyle Mestery
>>> > > wrote:
 >
 > In all cases today with Open Source plugins, Neutron agents have
 > run
 > on the hosts. For OpenDaylight, this is not the case.
OpenDaylight
 > integrates with Neutron as a ML2 MechanismDriver. But it has no
 > Neutron code on the compute hosts. OpenDaylight itself
communicates
 > directly to those compute hosts to program Open vSwitch.
 >
 >
 >
 > devstack doesn't provide a way for me to express this today. On
the
 > compute hosts in the above scenario, there is no "q-*" services
 > enabled, so the "is_neutron_enabled" function returns 1,
meaning no
 > neutron.
 >
 >
 > True and working as designed.
 >
 >
 > And then devstack sets Nova up to use nova-networking, which
fails.
 >
 >
 > This only happens if you have enabled nova-network.  Since it is on
by
 > default you must disable it.
 >
 >
 > The patch I have submitted [1] modifies "is_neutron_enabled" to
 > check for the meta neutron service being enabled, which will
then
 > configure nova to use Neutron instead of nova-networking on the
 > hosts. If this sounds wonky and incorrect, I'm open to
suggestions
 > on how to make this happen.
 >
 >
 > From the review:
 >
 > is_neutron_enabled() is doing exactly what it is expected to do,
return
 > success if it finds any "q-*" service listed in ENABLED_SERVICES.
If no
 > neutron services are configured on a compute host, then this must
not
 > say they are.
 >
 > Putting 'neutron' in ENABLED_SERVICES does nothing and should do
 > nothing.
 >
 > Since you are not implementing the ODS as a Neutron plugin (as far
as
 > DevStack is concerned) you should then treat it as a system service
and
 > configure it that way, adding 'opendaylight' to ENABLED_SERVICES
 > whenever you want something to know it is being used.
 >
 >
 >
 > Note: I have another patch [2] which enables an OpenDaylight
 > service, including configuration of OVS on hosts. But I cannot
 > check
 > if the "opendaylight" service is enabled, because this will only
 > run
 > on a single node, and again, not on each compute host.
 >
 >
 > I don't understand this conclusion. in multi-node each node gets its
 > own
 > specific ENABLED_SERVICES list, you can check that on each node to
 > determine how to configure that node.  That is what I'm trying to
 > explain in that last paragraph above, maybe not too clearly.

 So in an Open Daylight environment... what's running on the compute
host
 to coordinate host level networking?

>>> Nothing. OpenDaylight communicates to each host using OpenFlow and
>>>OVSDB
>>> to manage networking on the host. In fact, this is one huge advantage
>>>for
>>> the
>>> ODL MechanismDriver in Neutron, because it's one less agent running on
>>>the
>>> host.
>>>
>>> Thanks,
>>> Kyle
>>>
>> As an update here, I've reworked my devstack patch [1]  for adding
>> OpenDaylight
>> support to make OpenDaylight a top-level service, per suggestion from
>>Dean.
>> You
>> can now enable both "odl-server" and "odl-compute" in your local.conf
>>with
>> my patch.
>> Enabling "odl-server" will run OpenDaylight under devstack. Enabling
>> "odl-compute"
>> will configure the host's OVS to work with OpenDaylight.
>>
>> Per discussion with Sean, I'd like to look at refactoring some other
>>bits of
>> the Neutron
>> devstack code in the coming weeks as well.
>>
>> Thanks!
>> Kyle
>>
>> [1] https://review.openstack.org/#/c/69774/
>>

 -Sean

 --
 Sean Dague
 Samsung Research Ame

Re: [openstack-dev] [Neutron] Developer documentation

[Edgar Magana]

I agree this is a valid request. As a team we should consider this special
request and help is possible.
Specially on Documentation!!  :-)

Edgar

On 3/7/14 10:12 AM, "Collins, Sean" 
wrote:

>Hi,
>
>I know everyone is very busy working on the I-3 release, but I wanted
>solicit feedback on my developer documentation review.
>
>https://review.openstack.org/#/c/72428/
>
>Currently, we have a couple +1's and a +2 from Nachi - Akihirio Motoki
>and Henry Gessau brought up valid points about the TESTING file, but I
>felt that they can be addressed in other patchsets - since I don't feel
>confident in making the changes that they suggested, and some of the
>comments refer to issues that exist in the
>
>In addition, we're almost to the goal line - I'd rather get some docs
>merged and update in another patchset, rather than update this review
>with another patchset, that clears out all the +2's and +1's and then
>wait for everyone to circle back and re-approve.
>
>I understand this is a unusual request and I am asking for special
>treatment, but Neutron is severely lacking in documentation for new
>developers and I think this patch moves us closer to fixing it.
>
>Thoughts?
>
>-- 
>Sean M. Collins
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



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

Re: [openstack-dev] [Neutron][LBaaS] Mini-summit Interest?

[Edgar Magana]

Team,

I found that having a mini-summit with a very short notice means excluding
a lot of developers of such an interesting topic for Neutron.
The OpenStack summit is the opportunity for all developers to come
together and discuss the next steps, there are many developers that CAN
NOT afford another trip for a "special" summit. I am personally against
that and I do support Mark's proposal of having all the conversation over
IRC and mailing list.

Please, do not start excluding people that won't be able to attend another
face-to-face meeting besides the summit. I believe that these are the
little things that make an open source community weak if we do not control
it.

Thanks,

Edgar


On 3/6/14 9:51 PM, "Mark McClain"  wrote:

>
>On Mar 6, 2014, at 4:31 PM, Jay Pipes  wrote:
>
>> On Thu, 2014-03-06 at 21:14 +, Youcef Laribi wrote:
>>> +1
>>> 
>>> I think if we can have it before the Juno summit, we can take
>>> concrete, well thought-out proposals to the community at the summit.
>> 
>> Unless something has changed starting at the Hong Kong design summit
>> (which unfortunately I was not able to attend), the design summits have
>> always been a place to gather to *discuss* and *debate* proposed
>> blueprints and design specs. It has never been about a gathering to
>> rubber-stamp proposals that have already been hashed out in private
>> somewhere else.
>
>You are correct that is the goal of the design summit.  While I do think
>it is wise to discuss the next steps with LBaaS at this point in time, I
>am not a proponent of in person mini-design summits.  Many contributors
>to LBaaS are distributed all over the global, and scheduling a mini
>summit with short notice will exclude valuable contributors to the team.
>I¹d prefer to see an open process with discussions on the mailing list
>and specially scheduled IRC meetings to discuss the ideas.
>
>mark
>
>
>___
>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][LBaaS] Mini-summit Interest?

[Edgar Magana]

Eugene,

A have a few arguments why I believe this is not 100% inclusive
* Is the foundation involved on this process? How? What is the budget? Who
is the responsible from the foundation  side?
* If somebody made already travel arraignments, it won't be possible to make
changes at not cost.
* Staying extra days in a different city could impact anyone's budget
* As a OpenStack developer. I want to understand why the summit is not
enough for deciding the next steps for each project. If that is the case, I
would prefer to make changes on the organization of the summit instead of
creating mini-summits all around!
I could continue but I think these are good enough.

I could agree with your point about previous summits being distractive for
developers, this is why this time the OpenStack foundation is trying very
hard to allocate specific days for the conference and specific days for the
summit.
The point that I am totally agree with you is that we SHOULD NOT have
session about work that will be done no matter what!  Those are just a waste
of good time that could be invested in very interesting discussions about
topics that are still not clear.
I would recommend that you express this opinion to Mark. He is the right guy
to decide which sessions will bring interesting discussions and which ones
will be just a declaration of intents.

Thanks,

Edgar

From:  Eugene Nikanorov 
Reply-To:  OpenStack List 
Date:  Monday, March 10, 2014 10:32 AM
To:  OpenStack List 
Subject:  Re: [openstack-dev] [Neutron][LBaaS] Mini-summit Interest?

Hi Edgar,

I'm neutral to the suggestion of mini summit at this point.
Why do you think it will exclude developers?
If we keep it 1-3 days prior to OS Summit in Atlanta (e.g. in the same city)
that would allow anyone who joins OS Summit to save on extra travelling.
OS Summit itself is too distractive to have really productive discussions,
unless your missing the sessions and spend time discussing.
For instance design sessions basically only good for declaration of intents,
but not for real discussion of a complex topic at meaningful detail level.

What would be your suggestions to make this more inclusive?
I think the time and place is the key here - hence Atlanta and few days
prior OS summit.

Thanks,
Eugene.



On Mon, Mar 10, 2014 at 10:59 PM, Edgar Magana  wrote:
> Team,
> 
> I found that having a mini-summit with a very short notice means excluding
> a lot of developers of such an interesting topic for Neutron.
> The OpenStack summit is the opportunity for all developers to come
> together and discuss the next steps, there are many developers that CAN
> NOT afford another trip for a "special" summit. I am personally against
> that and I do support Mark's proposal of having all the conversation over
> IRC and mailing list.
> 
> Please, do not start excluding people that won't be able to attend another
> face-to-face meeting besides the summit. I believe that these are the
> little things that make an open source community weak if we do not control
> it.
> 
> Thanks,
> 
> Edgar
> 
> 
> On 3/6/14 9:51 PM, "Mark McClain"  wrote:
> 
>> >
>> >On Mar 6, 2014, at 4:31 PM, Jay Pipes  wrote:
>> >
>>> >> On Thu, 2014-03-06 at 21:14 +, Youcef Laribi wrote:
>>>> >>> +1
>>>> >>>
>>>> >>> I think if we can have it before the Juno summit, we can take
>>>> >>> concrete, well thought-out proposals to the community at the summit.
>>> >>
>>> >> Unless something has changed starting at the Hong Kong design summit
>>> >> (which unfortunately I was not able to attend), the design summits have
>>> >> always been a place to gather to *discuss* and *debate* proposed
>>> >> blueprints and design specs. It has never been about a gathering to
>>> >> rubber-stamp proposals that have already been hashed out in private
>>> >> somewhere else.
>> >
>> >You are correct that is the goal of the design summit.  While I do think
>> >it is wise to discuss the next steps with LBaaS at this point in time, I
>> >am not a proponent of in person mini-design summits.  Many contributors
>> >to LBaaS are distributed all over the global, and scheduling a mini
>> >summit with short notice will exclude valuable contributors to the team.
>> >I¹d prefer to see an open process with discussions on the mailing list
>> >and specially scheduled IRC meetings to discuss the ideas.
>> >
>> >mark
>> >
>> >
>> >___
>> >OpenStack-dev mailing list
>> >OpenStack-dev@lists.openstack.org
>> >http://lists.openstack.org/cgi-bi

Re: [openstack-dev] [Neutron] Docs for new plugins

[Edgar Magana]

You should be able to add your plugin here:
http://docs.openstack.org/havana/config-reference/content/networking-options
-plugins.html

Thanks,

Edgar

From:  Mohammad Banikazemi 
Date:  Monday, March 10, 2014 2:40 PM
To:  OpenStack List 
Cc:  Edgar Magana 
Subject:  Re: [openstack-dev] [Neutron] Docs for new plugins

Would like to know what to do for adding documentation for a new plugin. Can
someone point me to the right place/process please.

Thanks,

Mohammad


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

Re: [openstack-dev] [Neutron] Docs for new plugins

[Edgar Magana]

Hi There,

Basically, we just wanted to be sure that the pre-populated information is
accurate and if there is nothing else to add you can close the bug.

Thanks,

Edgar

From:  Mohammad Banikazemi 
Date:  Wednesday, March 12, 2014 8:53 PM
To:  OpenStack List 
Cc:  Edgar Magana , OpenStack List

Subject:  Re: [openstack-dev] [Neutron] Docs for new plugins

Tom Fifield  wrote on 03/12/2014 10:51:54 PM:

> From: Tom Fifield 
> To: "OpenStack Development Mailing List (not for usage questions)"
> , Edgar Magana ,
> Date: 03/12/2014 10:59 PM
> Subject: Re: [openstack-dev] [Neutron] Docs for new plugins
> 
> On 13/03/14 13:43, Mohammad Banikazemi wrote:
> > Thanks for your response.
> >
> > It looks like the page you are referring to gets populated automatically
> > and I see a link already added to it for the new plugin. I also see a
> > file corresponding to the new plugin having been created and populated
> > with the plugin config options in the latest openstack-manuals cloned
> > from github.
> >
> > After talking to the docs people on #openstack-docs, now I know that
> > these files get created automatically and periodically. Any changes to
> > the docs should come through changes to the config file in the code
> > which will be automatically picked up at some point when the docs
> > scripts get executed.
> 
> Just to clarify one point - the text comes from the code, in the oslo
> option registration's helptext, not from the configuration files in etc.
> 

Thanks for clarifying this point and for the initial information as well.
Yes, by "config file in the code" I was referring to the config.py file in
our plugin (and a few other Neutron plugins I have seen) where the plugin
options and corresponding helptexts get registered by using register_opts()
from oslo.


> > It looks like there is nothing to be done in this front for adding the
> > docs for the new plugin. If that seems reasonable, I will close the bug
> > I had opened for the the docs for our plugin.
> >
> > Thanks,
> >
> > -Mohammad
> >
> >
> >
> >
> >
> > Inactive hide details for Edgar Magana ---03/12/2014 06:10:31 PM---You
> > should be able to add your plugin here: http://docs.openEdgar Magana
> > ---03/12/2014 06:10:31 PM---You should be able to add your plugin here:
> > http://docs.openstack.org/havana/config-reference/conten
> >
> > From: Edgar Magana 
> > To: Mohammad Banikazemi/Watson/IBM@IBMUS, "OpenStack Development Mailing
> > List (not for usage questions)" ,
> > Date: 03/12/2014 06:10 PM
> > Subject: Re: [openstack-dev] [Neutron] Docs for new plugins
> >
> > 
> >
> >
> >
> > You should be able to add your plugin here:
> > _http://docs.openstack.org/havana/config-reference/content/
> networking-options-plugins.html_
> >
> > Thanks,
> >
> > Edgar
> >
> > *From: *Mohammad Banikazemi <_...@us.ibm.com_ <mailto:m...@us.ibm.com>>*
> > Date: *Monday, March 10, 2014 2:40 PM*
> > To: *OpenStack List <_openstack-dev@lists.openstack.org_
> > <mailto:openstack-dev@lists.openstack.org>>*
> > Cc: *Edgar Magana <_emagana@plumgrid.com_ <mailto:emag...@plumgrid.com>>*
> > Subject: *Re: [openstack-dev] [Neutron] Docs for new plugins
> >
> > Would like to know what to do for adding documentation for a new plugin.
> > Can someone point me to the right place/process please.
> >
> > Thanks,
> >
> > Mohammad
> >
> >
> >
> > ___
> > 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][LBaaS] Mini-summit Interest?

[Edgar Magana]

That sounds like a good idea Mark!
Yes, please do not do it during the World Cup at least the meeting is in
Brazil  :-)

Edgar

On 3/13/14 2:11 PM, "Mark McClain"  wrote:

>
>On Mar 13, 2014, at 4:22 PM, Jay Pipes  wrote:
>
>> 
>> 
>> I personally would not be able to attend a mini-summit days before the
>> regular summit. I would, however, support a mini-summit about a month
>> after the regular summit, where the focus would be on implementing the
>> designs that are discussed at the regular summit.
>
>I¹ve been working some of the others on the core team to setup another
>Neutron mid-cycle meet up. Like the last one, this will be focused on
>writing/reviewing code for important Juno blueprints (so those who can¹t
>travel can still participate).  The trouble with finding dates in late
>May to early July dates is there are a number of large regional OpenStack
>events, other conferences, and the World Cup (we do have a several
>football fans on the team).  I hope that we¹ll be able to share the
>information with everyone soon.
>
>mark 
>___
>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] Docs for new plugins

[Edgar Magana]

Including Anne in this thread.

Anne,

Can your provide your input here?

Thanks,

Edgar

From:  Mohammad Banikazemi 
Reply-To:  OpenStack List 
Date:  Monday, March 17, 2014 8:02 AM
To:  OpenStack List 
Subject:  Re: [openstack-dev] [Neutron] Docs for new plugins

I think the docs get updated for each release, so probably the newly added
stuff (after I3) will be picked up by the RC1 release date. (cc'ing Tom
Fifield for a definitive answer.)

By the way I do see the odl config table in the openstack-manuals source
tree: 
https://github.com/openstack/openstack-manuals/blob/master/doc/common/tables
/neutron-ml2_odl.xml
and that is being referenced here:
https://github.com/openstack/openstack-manuals/blob/master/doc/config-refere
nce/networking/section_networking-plugins-ml2.xml

Best,

Mohammad


Kyle Mestery ---03/17/2014 09:40:51 AM---Edgar: I don't see the
configuration options for the OpenDaylight ML2

From: Kyle Mestery 
To: "OpenStack Development Mailing List (not for usage questions)"
,
Date: 03/17/2014 09:40 AM
Subject: Re: [openstack-dev] [Neutron] Docs for new plugins




Edgar:

I don't see the configuration options for the OpenDaylight ML2
MechanismDriver
added here yet, even though the code was checked in well over a week ago.
How long does it take to autogenerate this page from the code?

Thanks!
Kyle



On Wed, Mar 12, 2014 at 5:10 PM, Edgar Magana mailto:emag...@plumgrid.com> > wrote:
> You should be able to add your plugin here:
> http://docs.openstack.org/havana/config-reference/content/networking-options-p
> lugins.html 
> <http://docs.openstack.org/havana/config-reference/content/networking-options-
> plugins.html> 
> 
> Thanks,
> 
> Edgar
> 
> From: Mohammad Banikazemi mailto:m...@us.ibm.com> >
> Date: Monday, March 10, 2014 2:40 PM
> To: OpenStack List  <mailto:openstack-dev@lists.openstack.org> >
> Cc: Edgar Magana mailto:emag...@plumgrid.com> >
> Subject: Re: [openstack-dev] [Neutron] Docs for new plugins
> 
> Would like to know what to do for adding documentation for a new plugin. Can
> someone point me to the right place/process please.
> 
> Thanks,
> 
> Mohammad
> 
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org <mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> <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] Docs for new plugins

[Edgar Magana]

Thanks for the input Anne!

Kyle,

Please file the proper bugs in the manual projects to be able to track the
progress of this topic.

Thanks,

Edgar

From:  Anne Gentle 
Date:  Wednesday, March 19, 2014 4:54 AM
To:  Edgar Magana 
Cc:  OpenStack List 
Subject:  Re: [openstack-dev] [Neutron] Docs for new plugins




On Wed, Mar 19, 2014 at 12:45 AM, Edgar Magana  wrote:
> Including Anne in this thread.
> 
> Anne,
> 
> Can your provide your input here?
> 
> Thanks,
> 
> Edgar
> 
> From:  Mohammad Banikazemi 
> Reply-To:  OpenStack List 
> Date:  Monday, March 17, 2014 8:02 AM
> To:  OpenStack List 
> 
> Subject:  Re: [openstack-dev] [Neutron] Docs for new plugins
> 
> I think the docs get updated for each release, so probably the newly added
> stuff (after I3) will be picked up by the RC1 release date. (cc'ing Tom
> Fifield for a definitive answer.)
> 
> By the way I do see the odl config table in the openstack-manuals source tree:
> https://github.com/openstack/openstack-manuals/blob/master/doc/common/tables/n
> eutron-ml2_odl.xml
> and that is being referenced here:
> https://github.com/openstack/openstack-manuals/blob/master/doc/config-referenc
> e/networking/section_networking-plugins-ml2.xml
> 
> Best,
> 
> Mohammad
> 
> 
> Kyle Mestery ---03/17/2014 09:40:51 AM---Edgar: I don't see the configuration
> options for the OpenDaylight ML2


Hi Kyle, there is still a manual step by a docs person to run the scripts
and create a patch.

Does Gauvain's patch contain the OpenDaylight config options?
 https://review.openstack.org/#/c/81013/
<https://review.openstack.org/#/c/81013/>

I also want to note that just because there is reference information doesn't
mean the docs are complete -- are there concepts and tasks still to be
written so that users know how to use this ML2 plug-in and that it's
available? Add those to the Cloud Administration Guide please.

Thanks,
Anne
> 
> 
> From: Kyle Mestery 
> To: "OpenStack Development Mailing List (not for usage questions)"
> ,
> Date: 03/17/2014 09:40 AM
> Subject: Re: [openstack-dev] [Neutron] Docs for new plugins
> 
> 
> 
> 
> Edgar:
> 
> I don't see the configuration options for the OpenDaylight ML2 MechanismDriver
> added here yet, even though the code was checked in well over a week ago.
> How long does it take to autogenerate this page from the code?
> 
> Thanks!
> Kyle
> 
> 
> 
> On Wed, Mar 12, 2014 at 5:10 PM, Edgar Magana  <mailto:emag...@plumgrid.com> > wrote:
>> You should be able to add your plugin here:
>> http://docs.openstack.org/havana/config-reference/content/networking-options-
>> plugins.html 
>> <http://docs.openstack.org/havana/config-reference/content/networking-options
>> -plugins.html> 
>> 
>> Thanks,
>> 
>> Edgar
>> 
>> From: Mohammad Banikazemi mailto:m...@us.ibm.com> >
>> Date: Monday, March 10, 2014 2:40 PM
>> To: OpenStack List > <mailto:openstack-dev@lists.openstack.org> >
>> Cc: Edgar Magana mailto:emag...@plumgrid.com> >
>> Subject: Re: [openstack-dev] [Neutron] Docs for new plugins
>> 
>> Would like to know what to do for adding documentation for a new plugin. Can
>> someone point me to the right place/process please.
>> 
>> Thanks,
>> 
>> Mohammad
>> 
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org <mailto:OpenStack-dev@lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> <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.orghttp://lists.openstack.org/cgi-bin/mailman/li
> stinfo/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-docs] Neutron documentation to update about new vendor plugin, but without code in repository?

[Edgar Magana]

Hi,

IMHO we should have a proper way to reference external vendor specific 
plugins/drivers mostly because at least in Neutron we are considering to move 
ALL vendor specific code out-of-tree, again it is just a consideration not a 
fact.

So, having a place holder for that will make sense.

Thanks,

Edgar

From: Anne Gentle mailto:a...@openstack.org>>
Date: Friday, October 10, 2014 at 12:18 PM
To: 
"OpenStack-dev@lists.openstack.org" 
mailto:OpenStack-dev@lists.openstack.org>>
Cc: 
"openstack-d...@lists.openstack.org" 
mailto:openstack-d...@lists.openstack.org>>
Subject: Re: [OpenStack-docs] [openstack-dev] Neutron documentation to update 
about new vendor plugin, but without code in repository?



On Fri, Oct 10, 2014 at 2:11 PM, Vadivel Poonathan 
mailto:vadivel.openst...@gmail.com>> wrote:

Hi,

How to include a new vendor plug-in (aka mechanism_driver in ML2 framework) 
into the Openstack documentation?.. In other words, is it possible to include a 
new plug-in in the Openstack documentation page without having the actual 
plug-in code as part of the Openstack neutron repository?... The actual plug-in 
is posted and available for the public to download as Ubuntu package. But i 
need to mention somewhere in the Openstack documentation that this new plugin 
is available for the public to use along with its documentation.

We definitely want you to include pointers to vendor documentation in the 
OpenStack docs, but I'd prefer make sure they're gate tested before they get 
listed on docs.openstack.org. Drivers change enough 
release-to-release that it's difficult to keep up maintenance.

Lately I've been talking to driver contributors (hypervisor, storage, 
networking) about the out-of-tree changes possible. I'd like to encourage even 
out-of-tree drivers to get listed, but to store their main documents outside of 
docs.openstack.org, if they are gate-tested.

Anyone have other ideas here?

Looping in the OpenStack-docs mailing list also.
Anne



Pls. provide some insights into whether it is possible?.. and any further info 
on this?..

Thanks,

Vad

--

___
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] Neutron documentation to update about new vendor plugin, but without code in repository?

[Edgar Magana]

I second Anne’s and Kyle comments. Actually, I like very much the wiki part to 
provide some visibility for out-of-tree plugins/drivers but not into the 
official documentation.

Thanks,

Edgar

From: Anne Gentle mailto:a...@openstack.org>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, October 23, 2014 at 8:51 AM
To: Kyle Mestery mailto:mest...@mestery.com>>
Cc: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Neutron documentation to update about 
new vendor plugin, but without code in repository?



On Thu, Oct 23, 2014 at 10:31 AM, Kyle Mestery 
mailto:mest...@mestery.com>> wrote:
Vad:

The third-party CI is required for your upstream driver. I think
what's different from my reading of this thread is the question of
what is the requirement to have a driver listed in the upstream
documentation which is not in the upstream codebase. To my knowledge,
we haven't done this. Thus, IMHO, we should NOT be utilizing upstream
documentation to document drivers which are themselves not upstream.
When we split out the drivers which are currently upstream in neutron
into a separate repo, they will still be upstream. So my opinion here
is that if your driver is not upstream, it shouldn't be in the
upstream documentation. But I'd like to hear others opinions as well.


This is my sense as well.

The hypervisor drivers are documented on the wiki, sometimes they're in-tree, 
sometimes they're not, but the state of testing is documented on the wiki. I 
think we could take this approach for network and storage drivers as well.

https://wiki.openstack.org/wiki/HypervisorSupportMatrix

Anne

Thanks,
Kyle

On Thu, Oct 23, 2014 at 9:44 AM, Vadivel Poonathan
mailto:vadivel.openst...@gmail.com>> wrote:
> Kyle,
> Gentle reminder... when you get a chance!..
>
> Anne,
> In case, if i need to send it to different group or email-id to reach Kyle
> Mestery, pls. let me know. Thanks for your help.
>
> Regards,
> Vad
> --
>
>
> On Tue, Oct 21, 2014 at 8:51 AM, Vadivel Poonathan
> mailto:vadivel.openst...@gmail.com>> wrote:
>>
>> Hi Kyle,
>>
>> Can you pls. comment on this discussion and confirm the requirements for
>> getting out-of-tree mechanism_driver listed in the supported plugin/driver
>> list of the Openstack Neutron docs.
>>
>> Thanks,
>> Vad
>> --
>>
>> On Mon, Oct 20, 2014 at 12:48 PM, Anne Gentle 
>> mailto:a...@openstack.org>> wrote:
>>>
>>>
>>>
>>> On Mon, Oct 20, 2014 at 2:42 PM, Vadivel Poonathan
>>> mailto:vadivel.openst...@gmail.com>> wrote:

 Hi,

  On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton 
  mailto:blak...@gmail.com>>
  wrote:
 >
 > I think you will probably have to wait until after the summit so
 > we can
 > see the direction that will be taken with the rest of the in-tree
 > drivers/plugins. It seems like we are moving towards removing all
 > of them so
 > we would definitely need a solution to documenting out-of-tree
 > drivers as
 > you suggested.

 [Vad] while i 'm waiting for the conclusion on this subject, i 'm trying
 to setup the third-party CI/Test system and meet its requirements to get my
 mechanism_driver listed in the Kilo's documentation, in parallel.

 Couple of questions/confirmations before i proceed further on this
 direction...

 1) Is there anything more required other than the third-party CI/Test
 requirements ??.. like should I still need to go-through the entire
 development process of submit/review/approval of the blue-print and code of
 my ML2 driver which was already developed and in-use?...

>>>
>>> The neutron PTL Kyle Mestery can answer if there are any additional
>>> requirements.
>>>

 2) Who is the authority to clarify and confirm the above (and how do i
 contact them)?...
>>>
>>>
>>> Elections just completed, and the newly elected PTL is Kyle Mestery,
>>> http://lists.openstack.org/pipermail/openstack-dev/2014-March/031433.html.
>>>


 Thanks again for your inputs...

 Regards,
 Vad
 --

 On Tue, Oct 14, 2014 at 3:17 PM, Anne Gentle 
 mailto:a...@openstack.org>> wrote:
>
>
>
> On Tue, Oct 14, 2014 at 5:14 PM, Vadivel Poonathan
> mailto:vadivel.openst...@gmail.com>> wrote:
>>
>> Agreed on the requirements of test results to qualify the vendor
>> plugin to be listed in the upstream docs.
>> Is there any procedure/infrastructure currently available for this
>> purpose?..
>> Pls. fwd any link/pointers on those info.
>>
>
> Here's a link to the third-party testing setup information.
>
> http://ci.openstack.org/third_party.html
>
> Feel free to keep asking questions as you dig deeper.
> Thanks,
> Anne
>
>>

Re: [openstack-dev] [Neutron] Neutron documentation to update about new vendor plugin, but without code in repository?

[Edgar Magana]

I forgot to mention that I can help to coordinate the creation and maintenance 
of the wiki for non-upstreamed drivers for Neutron.
We need to be sure that we DO NOT confuse users with the current information 
here:
https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers

I have been maintaining that wiki and I would like to keep just for upstreamed 
vendor-specific plugins/drivers.

Edgar

From: Edgar Magana mailto:edgar.mag...@workday.com>>
Date: Thursday, October 23, 2014 at 9:46 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>, 
Kyle Mestery mailto:mest...@mestery.com>>
Subject: Re: [openstack-dev] [Neutron] Neutron documentation to update about 
new vendor plugin, but without code in repository?

I second Anne’s and Kyle comments. Actually, I like very much the wiki part to 
provide some visibility for out-of-tree plugins/drivers but not into the 
official documentation.

Thanks,

Edgar

From: Anne Gentle mailto:a...@openstack.org>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, October 23, 2014 at 8:51 AM
To: Kyle Mestery mailto:mest...@mestery.com>>
Cc: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Neutron documentation to update about 
new vendor plugin, but without code in repository?



On Thu, Oct 23, 2014 at 10:31 AM, Kyle Mestery 
mailto:mest...@mestery.com>> wrote:
Vad:

The third-party CI is required for your upstream driver. I think
what's different from my reading of this thread is the question of
what is the requirement to have a driver listed in the upstream
documentation which is not in the upstream codebase. To my knowledge,
we haven't done this. Thus, IMHO, we should NOT be utilizing upstream
documentation to document drivers which are themselves not upstream.
When we split out the drivers which are currently upstream in neutron
into a separate repo, they will still be upstream. So my opinion here
is that if your driver is not upstream, it shouldn't be in the
upstream documentation. But I'd like to hear others opinions as well.


This is my sense as well.

The hypervisor drivers are documented on the wiki, sometimes they're in-tree, 
sometimes they're not, but the state of testing is documented on the wiki. I 
think we could take this approach for network and storage drivers as well.

https://wiki.openstack.org/wiki/HypervisorSupportMatrix

Anne

Thanks,
Kyle

On Thu, Oct 23, 2014 at 9:44 AM, Vadivel Poonathan
mailto:vadivel.openst...@gmail.com>> wrote:
> Kyle,
> Gentle reminder... when you get a chance!..
>
> Anne,
> In case, if i need to send it to different group or email-id to reach Kyle
> Mestery, pls. let me know. Thanks for your help.
>
> Regards,
> Vad
> --
>
>
> On Tue, Oct 21, 2014 at 8:51 AM, Vadivel Poonathan
> mailto:vadivel.openst...@gmail.com>> wrote:
>>
>> Hi Kyle,
>>
>> Can you pls. comment on this discussion and confirm the requirements for
>> getting out-of-tree mechanism_driver listed in the supported plugin/driver
>> list of the Openstack Neutron docs.
>>
>> Thanks,
>> Vad
>> --
>>
>> On Mon, Oct 20, 2014 at 12:48 PM, Anne Gentle 
>> mailto:a...@openstack.org>> wrote:
>>>
>>>
>>>
>>> On Mon, Oct 20, 2014 at 2:42 PM, Vadivel Poonathan
>>> mailto:vadivel.openst...@gmail.com>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> >>>> On Fri, Oct 10, 2014 at 7:36 PM, Kevin Benton 
>>>> >>>> mailto:blak...@gmail.com>>
>>>> >>>> wrote:
>>>> >>>>>
>>>> >>>>> I think you will probably have to wait until after the summit so
>>>> >>>>> we can
>>>> >>>>> see the direction that will be taken with the rest of the in-tree
>>>> >>>>> drivers/plugins. It seems like we are moving towards removing all
>>>> >>>>> of them so
>>>> >>>>> we would definitely need a solution to documenting out-of-tree
>>>> >>>>> drivers as
>>>> >>>>> you suggested.
>>>>
>>>> [Vad] while i 'm waiting for the conclusion on this subject, i 'm trying
>>>> to setup the third-party CI/Test system and meet its requirements to get my
>>>> mechanism_driver listed in the Kilo's documentation, in parallel.
>>>>
>>>> Couple of questions/confirmations before i

Re: [openstack-dev] [neutron] Neutron mid-cycle announcement

[Edgar Magana]

I cant attend it if it moves to the week of Dec 15th. I have already booked a 
trip for that week and even other commitments. 

Is there any chance to push it back to Dec 8th?

Thanks,

Edgar

> On Nov 13, 2014, at 2:18 AM, Kyle Mestery  wrote:
> 
>> On Tue, Nov 11, 2014 at 7:04 AM, Kyle Mestery  wrote:
>> Hi folks:
>> 
>> Apologies for the delay in announcing the Neutron mid-cycle, but I was
>> confirming the details up until last night. I've captured the details
>> on an etherpad here [1]. The dates are December 8-10
>> (Monday-Wednesday), and it will be at the Adobe offices in Lehi, Utah,
>> USA.
>> 
>> We're still collecting information on hotels which should be on the
>> etherpad later today.
>> 
>> Thanks, looking forward to seeing everyone I missed in Paris!
>> Kyle
> Folks, just an update, but the host organization is running into some
> trouble with the selected dates of Dec 8-10. We may need to shift the
> dates by a week to Dec. 15-17. If you've already booked travel, please
> ping me privately, otherwise hold off for another day until we sort
> this out. Apologies for the trouble here.
> 
> Thanks,
> Kyle
> 
>> [1] https://etherpad.openstack.org/p/neutron-kilo-midcycle
> 
> ___
> 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] [Nova][Neutron] Error message when Neutron network is running out of IP addresses

[Edgar Magana]

Hello Community,


When a network subnet runs out of IP addresses a request to create a VM on that 
network fails with the Error message: "No valid host was found. There are not 
enough hosts available."

In the nova logs the error message is: NoMoreFixedIps: No fixed IP addresses 
available for network:

Obviously, this is not the desirable behavior, is there any work in progress to 
change it or I should open a bug to properly propagate the right error message.

Thanks,

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

Re: [openstack-dev] [Nova][Neutron][Technical Committee] nova-network -> Neutron. Throwing a wrench in the Neutron gap analysis

[Edgar Magana]

Jay,

I do agree with you on the focus areas. I believe Neutron should focus on
the nova-parity (DVR) and DB migrations more than ever, instead of
increasing the priority to new API such as the GBP. Actually, yesterday
Neutron IRC showed the need of having a more focused work instead of
picking in to many ³N² different areas.

The part that I disagree is with the focus on the nova-network -> Neutron
migration. I feel this activity is under control and even that it will not
deliver the ³no-downtime² expect ion, it will offer an alternative to
migration instances for those operators that could be interested.

Now, if Metacloud has a process that will work, please share it and let¹s
document it. The more the merrier, it will be up to the operators to chose
the best approach for their own clouds.

Edgar

On 8/5/14, 9:27 AM, "Monty Taylor"  wrote:

>On 08/05/2014 09:18 AM, Jay Pipes wrote:
>> Hello stackers, TC, Neutron contributors,
>>
>> At the Nova mid-cycle meetup last week in Oregon, during the discussion
>> about the future of nova-network, the topic of nova-network -> Neutron
>> migration came up.
>>
>> For some reason, I had been clueless about the details of one of the
>> items in the gap analysis the TC had requested [1]. Namely, the 5th
>> item, about nova-network -> Neutron migration, which is detailed in the
>> following specification:
>>
>> 
>>https://review.openstack.org/#/c/101921/12/specs/juno/neutron-migration.r
>>st
>>
>> The above specification outlines a plan to allow migration of *running*
>> instances from an OpenStack deployment using nova-network (both with and
>> without multi-host mode) to an OpenStack deployment using Neutron, with
>> little to no downtime using live migration techniques and an array of
>> post-vm-migrate strategies to wire up the new VIFs to the Neutron ports.
>>
>> I personally believe that this requirement to support a live migration
>> with no downtime of running instances between a nova-network and a
>> Neutron deployment *is neither realistic, nor worth the extensive time
>> and technical debt needed to make this happen*.
>>
>> I suggest that it would be better to instead provide good instructions
>> for doing cold migration (snapshot VMs in old nova-network deployment,
>> store in Swift or something, then launch VM from a snapshot in new
>> Neutron deployment) -- which should cover the majority of deployments --
>> and then write some instructions for what to look out for when doing a
>> custom migration for environments that simply cannot afford any downtime
>> and *really* want to migrate to Neutron. For these deployments, it's
>> almost guaranteed that they will need to mangle their existing databases
>> and do manual data migration anyway -- like RAX did when moving from
>> nova-network to Neutron. The variables are too many to list here, and
>> the number of deployments actually *needing* this work seems to me to be
>> very limited. Someone suggested Metacloud *might* be the only deployment
>> that might meet the needs for a live nova-network -> Neutron migration.
>> Metacloud folks, please do respond here!
>>
>> In short, I don't think the live migration requirement for nova-network
>> to Neutron is either realistic or valuable, and suggest relaxing it to
>> be good instructions for cold migration of instances from an older
>> deployment to a newer deployment. There are other more valuable things
>> that Neutron contributors could focus on, IMO -- such as the DVR
>> functionality that brings parity to Neutron with nova-network's
>> multi-host mode.
>>
>> Thoughts?
>
>I agree 100%. Although I understand the I think it's an unreasonably
>high burden in an area where there are many many other real pressing
>issues that need to be solved.
>
>
>___
>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] Group Based Policy and the way forward

[Edgar Magana]

This is the consequence of a proposal that is not following the standardized 
terminology (IETF - RFC) for any Policy-based System:
http://tools.ietf.org/html/rfc3198

Well, I did bring  this point during the Hong Kong Summit but as you can see my 
comments were totally ignored:
https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit

I clearly saw this kind of issues coming. Let me quote myself what I suggested: 
"For instance: "endpoints" should be "enforcement point"

I do not understand why GBP did not include this suggestion...

Edgar

From: Kevin Benton mailto:blak...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, August 6, 2014 at 10:22 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward


What I was referring to was also not Keystone's definition of an endpoint. It's 
almost as if the term has many uses and was not invented for Keystone. :-)

http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html

Did a similar discussion occur when Heat wanted to use the word 'template' 
since this was clearly already in use by Horizon?

On Aug 6, 2014 9:24 AM, "Jay Pipes" 
mailto:jaypi...@gmail.com>> wrote:
On 08/06/2014 02:12 AM, Kevin Benton wrote:
Given that, pointing to the Nova parity work seems a bit like a red
herring. This new API is being developed orthogonally to the existing
API endpoints

You see how you used the term endpoints there? :P

-jay

___
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] Group Based Policy and the way forward

[Edgar Magana]

That is the beauty of the open source projects, there is always a smartest
reviewer catching out the facts that you don¹t.

Edgar

On 8/6/14, 10:55 AM, "Sumit Naiksatam"  wrote:

>Edgar, you seemed to have +2'ed this patch on July 2nd [1]:
>
>"
>Edgar Magana
>Jul 2 8:42 AM
>
>Patch Set 13: Code-Review+2
>
>All looks good to me! I am not approving yet because Nachi was also
>reviewing this code and I would like to see his opinion as well.
>"
>
>That would suggest that you were happy with what was in it. I don't
>see anything in the review comments that suggests otherwise.
>
>[1]  https://review.openstack.org/#/c/95900/
>
>On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana 
>wrote:
>> This is the consequence of a proposal that is not following the
>>standardized
>> terminology (IETF - RFC) for any Policy-based System:
>> http://tools.ietf.org/html/rfc3198
>>
>> Well, I did bring  this point during the Hong Kong Summit but as you
>>can see
>> my comments were totally ignored:
>> 
>>https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIr
>>upCD9E/edit
>>
>> I clearly saw this kind of issues coming. Let me quote myself what I
>> suggested: "For instance: "endpoints" should be "enforcement point"
>>
>> I do not understand why GBP did not include this suggestionŠ
>>
>> Edgar
>>
>> From: Kevin Benton 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Wednesday, August 6, 2014 at 10:22 AM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>>
>> Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
>> forward
>>
>> What I was referring to was also not Keystone's definition of an
>>endpoint.
>> It's almost as if the term has many uses and was not invented for
>>Keystone.
>> :-)
>>
>> http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html
>>
>> Did a similar discussion occur when Heat wanted to use the word
>>'template'
>> since this was clearly already in use by Horizon?
>>
>> On Aug 6, 2014 9:24 AM, "Jay Pipes"  wrote:
>>>
>>> On 08/06/2014 02:12 AM, Kevin Benton wrote:
>>>>
>>>> Given that, pointing to the Nova parity work seems a bit like a red
>>>> herring. This new API is being developed orthogonally to the existing
>>>> API endpoints
>>>
>>>
>>> You see how you used the term endpoints there? :P
>>>
>>> -jay
>>>
>>> ___
>>> 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] Group Based Policy and the way forward

[Edgar Magana]

Basically, I am admitting that I did not catch in my review the part of
the endpoint term that Jay was pointing out.

Edgar

On 8/6/14, 11:32 AM, "Sumit Naiksatam"  wrote:

>Not sure what you are talking about? You claim now that you had
>suggestion which was not considered, yet you +2'ed a patch, by stating
>that "All looks good to me!".
>
>On Wed, Aug 6, 2014 at 11:19 AM, Edgar Magana 
>wrote:
>> That is the beauty of the open source projects, there is always a
>>smartest
>> reviewer catching out the facts that you don¹t.
>>
>> Edgar
>>
>> On 8/6/14, 10:55 AM, "Sumit Naiksatam"  wrote:
>>
>>>Edgar, you seemed to have +2'ed this patch on July 2nd [1]:
>>>
>>>"
>>>Edgar Magana
>>>Jul 2 8:42 AM
>>>
>>>Patch Set 13: Code-Review+2
>>>
>>>All looks good to me! I am not approving yet because Nachi was also
>>>reviewing this code and I would like to see his opinion as well.
>>>"
>>>
>>>That would suggest that you were happy with what was in it. I don't
>>>see anything in the review comments that suggests otherwise.
>>>
>>>[1]  https://review.openstack.org/#/c/95900/
>>>
>>>On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana 
>>>wrote:
>>>> This is the consequence of a proposal that is not following the
>>>>standardized
>>>> terminology (IETF - RFC) for any Policy-based System:
>>>> http://tools.ietf.org/html/rfc3198
>>>>
>>>> Well, I did bring  this point during the Hong Kong Summit but as you
>>>>can see
>>>> my comments were totally ignored:
>>>>
>>>>https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaB
>>>>Ir
>>>>upCD9E/edit
>>>>
>>>> I clearly saw this kind of issues coming. Let me quote myself what I
>>>> suggested: "For instance: "endpoints" should be "enforcement point"
>>>>
>>>> I do not understand why GBP did not include this suggestionŠ
>>>>
>>>> Edgar
>>>>
>>>> From: Kevin Benton 
>>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>>>questions)"
>>>> 
>>>> Date: Wednesday, August 6, 2014 at 10:22 AM
>>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>> 
>>>>
>>>> Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
>>>> forward
>>>>
>>>> What I was referring to was also not Keystone's definition of an
>>>>endpoint.
>>>> It's almost as if the term has many uses and was not invented for
>>>>Keystone.
>>>> :-)
>>>>
>>>> http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html
>>>>
>>>> Did a similar discussion occur when Heat wanted to use the word
>>>>'template'
>>>> since this was clearly already in use by Horizon?
>>>>
>>>> On Aug 6, 2014 9:24 AM, "Jay Pipes"  wrote:
>>>>>
>>>>> On 08/06/2014 02:12 AM, Kevin Benton wrote:
>>>>>>
>>>>>> Given that, pointing to the Nova parity work seems a bit like a red
>>>>>> herring. This new API is being developed orthogonally to the
>>>>>>existing
>>>>>> API endpoints
>>>>>
>>>>>
>>>>> You see how you used the term endpoints there? :P
>>>>>
>>>>> -jay
>>>>>
>>>>> ___
>>>>> 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

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

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Edgar Magana]

Ivar,

Of course and this is why we are having this conversation, in order to merge 
our different opinions.

Edgar

From: Ivar Lazzaro mailto:ivarlazz...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, August 6, 2014 at 1:41 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

Hi Edgar,

Actually, I think that other reviewers saw that name clash, and still thought 
it was ok to use the same terminology in such a different context.
BP reviews are a community effort right? So of course someones' idea may be 
different from yours.

Regards,
Ivar.


On Wed, Aug 6, 2014 at 10:29 PM, Edgar Magana 
mailto:edgar.mag...@workday.com>> wrote:
Basically, I am admitting that I did not catch in my review the part of
the endpoint term that Jay was pointing out.

Edgar

On 8/6/14, 11:32 AM, "Sumit Naiksatam" 
mailto:sumitnaiksa...@gmail.com>> wrote:

>Not sure what you are talking about? You claim now that you had
>suggestion which was not considered, yet you +2'ed a patch, by stating
>that "All looks good to me!".
>
>On Wed, Aug 6, 2014 at 11:19 AM, Edgar Magana 
>mailto:edgar.mag...@workday.com>>
>wrote:
>> That is the beauty of the open source projects, there is always a
>>smartest
>> reviewer catching out the facts that you don¹t.
>>
>> Edgar
>>
>> On 8/6/14, 10:55 AM, "Sumit Naiksatam" 
>> mailto:sumitnaiksa...@gmail.com>> wrote:
>>
>>>Edgar, you seemed to have +2'ed this patch on July 2nd [1]:
>>>
>>>"
>>>Edgar Magana
>>>Jul 2 8:42 AM
>>>
>>>Patch Set 13: Code-Review+2
>>>
>>>All looks good to me! I am not approving yet because Nachi was also
>>>reviewing this code and I would like to see his opinion as well.
>>>"
>>>
>>>That would suggest that you were happy with what was in it. I don't
>>>see anything in the review comments that suggests otherwise.
>>>
>>>[1]  https://review.openstack.org/#/c/95900/
>>>
>>>On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana 
>>>mailto:edgar.mag...@workday.com>>
>>>wrote:
>>>> This is the consequence of a proposal that is not following the
>>>>standardized
>>>> terminology (IETF - RFC) for any Policy-based System:
>>>> http://tools.ietf.org/html/rfc3198
>>>>
>>>> Well, I did bring  this point during the Hong Kong Summit but as you
>>>>can see
>>>> my comments were totally ignored:
>>>>
>>>>https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaB
>>>>Ir
>>>>upCD9E/edit
>>>>
>>>> I clearly saw this kind of issues coming. Let me quote myself what I
>>>> suggested: "For instance: "endpoints" should be "enforcement point"
>>>>
>>>> I do not understand why GBP did not include this suggestionŠ
>>>>
>>>> Edgar
>>>>
>>>> From: Kevin Benton mailto:blak...@gmail.com>>
>>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>>>questions)"
>>>> mailto:openstack-dev@lists.openstack.org>>
>>>> Date: Wednesday, August 6, 2014 at 10:22 AM
>>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>> mailto:openstack-dev@lists.openstack.org>>
>>>>
>>>> Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
>>>> forward
>>>>
>>>> What I was referring to was also not Keystone's definition of an
>>>>endpoint.
>>>> It's almost as if the term has many uses and was not invented for
>>>>Keystone.
>>>> :-)
>>>>
>>>> http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html
>>>>
>>>> Did a similar discussion occur when Heat wanted to use the word
>>>>'template'
>>>> since this was clearly already in use by Horizon?
>>>>
>>>> On Aug 6, 2014 9:24 AM, "Jay Pipes" 
>>>> mailto:jaypi...@gmail.com>> wrote:
>>>>>
>>>>> On 08/06/2014 02:12 AM, Kevin Benton wrote:
>>>>>>
>>>>>> Given that, pointing to the Nova parity work seems a bit like a red
>&g

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Edgar Magana]

Ivar,

You are totally right. I just want to clarify that I haven’t express any 
disagreement on the plugin, I actually (as Sumit mentioned) +2 this patch 
before. I just pointed our that I have expressed previously that GBP should use 
the standard Policy Terminology. I did not push hard enough at the right time 
because I consider it a minor thing but Jay has a valid point and I think it 
has to be reconsidered IMHO.

Let’s be careful with our public statements!

Edgar

From: Ivar Lazzaro mailto:ivarlazz...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, August 6, 2014 at 2:52 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward


Edgar,

Actually, As Pedro said, I think that the time for discussing these kind of 
concerns was the BP approval. The fact that it has been approved after many 
proposals and reviews means that a community effort wanted the GBP to be 
implemented in this release cycle the way it was presented at that time.

With this, I absolutely don't want to say that you should not express your 
disagreement! I'm just saying that it should be expressed differently (a BP to 
propose your model in K?). Otherwise, the whole BP process becomes just 
pointless.

Meanwhile, imho, blocking the patch feels really unfair.

Ivar.

On Aug 6, 2014 11:00 PM, "Edgar Magana" 
mailto:edgar.mag...@workday.com>> wrote:
Ivar,

Of course and this is why we are having this conversation, in order to merge 
our different opinions.

Edgar

From: Ivar Lazzaro mailto:ivarlazz...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, August 6, 2014 at 1:41 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

Hi Edgar,

Actually, I think that other reviewers saw that name clash, and still thought 
it was ok to use the same terminology in such a different context.
BP reviews are a community effort right? So of course someones' idea may be 
different from yours.

Regards,
Ivar.


On Wed, Aug 6, 2014 at 10:29 PM, Edgar Magana 
mailto:edgar.mag...@workday.com>> wrote:
Basically, I am admitting that I did not catch in my review the part of
the endpoint term that Jay was pointing out.

Edgar

On 8/6/14, 11:32 AM, "Sumit Naiksatam" 
mailto:sumitnaiksa...@gmail.com>> wrote:

>Not sure what you are talking about? You claim now that you had
>suggestion which was not considered, yet you +2'ed a patch, by stating
>that "All looks good to me!".
>
>On Wed, Aug 6, 2014 at 11:19 AM, Edgar Magana 
>mailto:edgar.mag...@workday.com>>
>wrote:
>> That is the beauty of the open source projects, there is always a
>>smartest
>> reviewer catching out the facts that you don¹t.
>>
>> Edgar
>>
>> On 8/6/14, 10:55 AM, "Sumit Naiksatam" 
>> mailto:sumitnaiksa...@gmail.com>> wrote:
>>
>>>Edgar, you seemed to have +2'ed this patch on July 2nd [1]:
>>>
>>>"
>>>Edgar Magana
>>>Jul 2 8:42 AM
>>>
>>>Patch Set 13: Code-Review+2
>>>
>>>All looks good to me! I am not approving yet because Nachi was also
>>>reviewing this code and I would like to see his opinion as well.
>>>"
>>>
>>>That would suggest that you were happy with what was in it. I don't
>>>see anything in the review comments that suggests otherwise.
>>>
>>>[1]  https://review.openstack.org/#/c/95900/
>>>
>>>On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana 
>>>mailto:edgar.mag...@workday.com>>
>>>wrote:
>>>> This is the consequence of a proposal that is not following the
>>>>standardized
>>>> terminology (IETF - RFC) for any Policy-based System:
>>>> http://tools.ietf.org/html/rfc3198
>>>>
>>>> Well, I did bring  this point during the Hong Kong Summit but as you
>>>>can see
>>>> my comments were totally ignored:
>>>>
>>>>https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaB
>>>>Ir
>>>>upCD9E/edit
>>>>
>>>> I clearly saw this kind of issues coming. Let me quote myself what I
>>>> suggested: "For instance: "endpoints" should be "enforcement point"
>>>>
>>>

Re: [openstack-dev] [Neutron] Bug squashing day

[Edgar Magana]

I will be around today. I can help on bug triaging.. Catch me on IRC
(emagana)

Thank for coordinating this Eugene!

Edgar

On 8/7/14, 9:19 AM, "Akihiro Motoki"  wrote:

>Thanks Eugene for initiating Neutron bug squashing day!
>I would like to focus on bug triaging and checking bug status rather
>than fixing bugs.
>There seem be many bugs which are not valid anymore.
>
>Thanks,
>Akihiro
>
>On Thu, Aug 7, 2014 at 11:31 PM, Eugene Nikanorov
> wrote:
>> Hi neutron folks,
>>
>> Today should have been 'Bug squashing day' where we go over existing
>>bugs
>> filed for the project and triage/prioritize/comment on them.
>>
>> I've created an etherpad with (hopefully) full list of neutron bugs:
>> https://etherpad.openstack.org/p/neutron-bug-squashing-day-2014-08-07
>>
>> I was able to walk through a couple of almost thousand of bugs we have.
>> My target was to reduce the number of open bugs, so some of them I
>>moved to
>> incomplete/invalid/won't fix state (not many though); then, to reduce
>>the
>> number of high importance bugs, especially if they're hanging for too
>>long.
>>
>> As you can see, bugs in the etherpad are sorted by importance.
>> Some of my observations include:
>> - almost all bugs with High priority really seem like issues we should
>>be
>> fixing.
>> In many cases submitter or initial contributor abandoned his work on the
>> bug...
>> - there are a couple of important bugs related to DVR where previously
>> working stuff
>> is broken, but in all cases there are DVR subteam members working on
>>those,
>> so we're good here so far.
>>
>> I also briefly described resolution for each bug, where 'n/a' means
>>that bug
>> just needs to be fixed/work should be continued without any change to
>>state.
>> I'm planning to continue to go over this list and expect more bugs will
>>go
>> away which previously have been marked as medium/low or wishlist.
>>
>> If anyone is willing to help - you're welcome!
>>
>> Thanks,
>> Eugene.
>>
>>
>>
>> ___
>> 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][policy] Group Based Policy - Renaming

[Edgar Magana]

I am sorry that I could not attend the GBP meeting.
Is there any reason why the IEFT standard is not considered?
http://tools.ietf.org/html/rfc3198

I would like to understand the argument why we are creating new names instead 
of using the standard ones.

Edgar

From: Ronak Shah mailto:ronak.malav.s...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, August 7, 2014 at 1:17 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming

Hi,
Following a very interesting and vocal thread on GBP for last couple of days 
and the GBP meeting today, GBP sub-team proposes following name changes to the 
resource.


policy-point for endpoint
policy-group for endpointgroup (epg)

Please reply if you feel that it is not ok with reason and suggestion.

I hope that it wont be another 150 messages thread :)

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

Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming

[Edgar Magana]

Ryan,

COPS implies a common protocol to communicate with PEPs, which implies the same 
communication mechanism basically.
So, you are implying that "endpoints" in GBP will use "different" protocol to 
communicate with "decisions" entities?

It that is the case.. Well it sounds very complex for a simple GBP initial 
project. Then, the discussion will be in a different level.

Edgar

From: Ryan Moats mailto:rmo...@us.ibm.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, August 7, 2014 at 2:18 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming


Edgar-

I can't speak for anyone else, but in my mind at least (and having been 
involved in the work that led up to 3198),
the members of the groups being discussed here are not PEPs.   As 3198 states, 
being a PEP implies running COPS
and I don't see that as necessary for membership in GBP groups.

Ryan Moats

Edgar Magana mailto:edgar.mag...@workday.com>> wrote 
on 08/07/2014 04:02:43 PM:

> From: Edgar Magana mailto:edgar.mag...@workday.com>>
> To: "OpenStack Development Mailing List (not for usage questions)"
> mailto:openstack-dev@lists.openstack.org>>
> Date: 08/07/2014 04:03 PM
> Subject: Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming
>
> I am sorry that I could not attend the GBP meeting.
> Is there any reason why the IEFT standard is not considered?
> http://tools.ietf.org/html/rfc3198
>
> I would like to understand the argument why we are creating new
> names instead of using the standard ones.
>
> Edgar
>
> From: Ronak Shah 
> mailto:ronak.malav.s...@gmail.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
> Date: Thursday, August 7, 2014 at 1:17 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
> Subject: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming
>
> Hi,
> Following a very interesting and vocal thread on GBP for last couple
> of days and the GBP meeting today, GBP sub-team proposes following
> name changes to the resource.
>

> policy-point for endpoint
> policy-group for endpointgroup (epg)
>
> Please reply if you feel that it is not ok with reason and suggestion.
>
> I hope that it wont be another 150 messages thread :)
>
> Ronak___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org<mailto: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][policy] Group Based Policy - Renaming

[Edgar Magana]

Thanks for sharing this Sumit.
Again, my apologies for not attending the meeting, I just I couldn’t.

It seems you had a good discussion about the naming and I do respect the
decision.

Cheers,

Edgar


On 8/7/14, 2:32 PM, "Sumit Naiksatam"  wrote:

>Ryan, point well taken. I am paraphrasing the discussion from today's
>GBP sub team meeting on the options considered and the eventual
>proposal for "policy-point" and "policy-group":
>
>18:36:50  so regarding the endpoint terminology
>18:36:53  any suggestions?
>18:36:56  ivar-lazzaro:  If you are expressing your intent of
>doing enforcement at both points you do care then.
>18:37:09  regXboi: Edgar Magana suggested using the IETF
>phrasing -- enforcement point
>18:37:31  i was thinking “edgar point” would be good.  and we
>won’t have to change our slides from EP.
>18:37:44  ivar-lazzaro:  would be great to see an example
>using the CLI how one sets something up that in GBP that does
>enforcement at the instance and router.
>18:37:44  mschoen ++
>18:37:55  rockyg: although enforcement point tends to
>be used in a slightly different context
>18:38:02  mscohen ++
>18:38:04  I was involved in the early IETF policy days, and
>I'm not a big from of ep
>18:38:04  mscohen: we dont want to overload the
>terminology
>18:38:13  regXboi: +1
>18:38:17  I’m not entirely sure “enforcement point” is the
>same as our usage of endpoint
>18:38:25  rkukura: exactly
>18:38:28  SumitNaiksatam: i am joking of course
>18:38:42  mscohen: :-)
>18:38:54  Yeah.  that's the problem with endpoint.  It's right
>for networking, but it already has another definition in
>virtualization world.
>18:38:54  how about network-endpoint (someone else
>suggested that)?
>18:38:55  I think enforcement point is more like the SG or
>FWaaS that is used to render the intent
>18:39:07  rkukura: agree
>18:39:09  so... let's hit the thesaurus
>18:39:16  Rkukara, agree
>18:39:38  I had always throught endpoint was the right word
>for both our usage and for keystone, with similar meanings, but
>different meta-levels
>18:40:01  rkukura: if we can find something different, let's
>consider it
>18:40:11  there is enough of a hill to climb
>18:40:35  how about terminus?
>18:40:52 * regXboi keeps reading synonyms
>18:41:06  network-endpoint?
>18:41:12  um... no
>18:41:27  I think that won't help
>18:41:58  policy-point/policy groups?
>18:42:07  group member?
>18:42:14  termination-point, gbp-id, policy point maybe
>18:42:18  sorry i dropped off again!
>18:42:23  I think member
>18:42:31  unless that's already used somewhere
>18:42:33  i was saying earlier, what about policy-point?
>18:42:36  #chair SumitNaiksatam
>18:42:37  Current chairs: SumitNaiksatam SumitNaiksatam_
>banix rkukura s3wong
>18:42:41  regXboi: Just “member” and “group”?
>18:42:44  s3wong: :-)
>18:43:04  SumitNaiksatam: so now either way works for you :-)
>18:43:09  rkurkura: too general I think...
>18:43:15  policy-provider, policy-consumer
>18:43:16  er rkukura ... sorry
>18:43:17  i still like endpoint better.
>18:43:23  bourn or bourne 1  (bɔːn)
>18:43:23 
>18:43:23  — n
>18:43:23  1.  a destination; goal
>18:43:23  2.  a boundary
>18:43:25  I think policy-point and policy-group
>18:43:27  yyywu: :-)
>18:43:34  Bourne-point?
>18:43:40  rockyg: :-)
>18:44:04  more in favor of policy-point and policy-group?
>18:44:36  i thnk LouisF suggested as well
>18:44:49  +1 to policy-point
>18:44:50  +1 to policy-point and policy-group
>18:44:55  +1
>18:44:56  SumitNaiksatam: +1 too
>18:45:07  +1
>18:45:08  FINALLY... YEAH
>18:45:18  okay so how about we float this in the ML?
>18:45:21  +1
>18:45:31  +1
>18:45:35  Yes... lets do that
>18:45:37  +1
>18:45:44  so that we dont end up picking up an
>overlapping terminology again
>18:45:55  who wants to do it? as in send to the ML?
>18:46:07 * SumitNaiksatam waiting to hand out an AI :-P
>18:46:16  regXboi: ?
>18:46:17  I can do it
>18:46:26  hmm?
>18:46:31  rms_13: ah you put your hand up first
>18:46:36 * regXboi apologies - bouncing between multiple IRC meetings
>18:46:47  policy-endpoint ?
>18:46:57  #action rms_13 to send “policy-point”
>“policy-group” suggestion to mailing list
>
>On Thu, Aug 7, 2014 at 2:18 PM, Ryan Moats  wrote:
>> Edgar-
>>
>> I can't speak for anyone else, but in my mind at least (and having been
>> involved in the work that led up to 3198),
>> the members of the groups being discussed here are not PEPs.   As 3198
>> states, being a PEP implies running COPS
>> and I don't see that as necessary for membership in GBP groups.
>>
>> Ryan Moats

Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming

[Edgar Magana]

That I understand it!
Thanks for the clarification.

Edgar

From: Ryan Moats mailto:rmo...@us.ibm.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, August 7, 2014 at 2:45 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming


Edgar Magana mailto:edgar.mag...@workday.com>> wrote 
on 08/07/2014 04:37:39 PM:

> From: Edgar Magana mailto:edgar.mag...@workday.com>>
> To: "OpenStack Development Mailing List (not for usage questions)"
> mailto:openstack-dev@lists.openstack.org>>
> Date: 08/07/2014 04:40 PM
> Subject: Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming
>
> Ryan,
>
> COPS implies a common protocol to communicate with PEPs, which
> implies the same communication mechanism basically.
> So, you are implying that "endpoints" in GBP will use "different"
> protocol to communicate with "decisions" entities?

Nope, I'm saying that the members of groups are not *required* to do 
enforcement.
They *could* (based on the implementation), but calling them PEPs means they 
would *have* to.

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

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

[Edgar Magana]

Big Plus 1 for Mark!
Great PTL and Excellent Job in Neutron!

Edgar


On Fri, Sep 20, 2013 at 1:44 PM, Mark McClain wrote:

>
> Hi-
>
> I writing to announce my candidacy for the OpenStack Networking (Neutron)
> PTL.
>
> I am the current Neutron PTL.  Our team continued to grow during the
> Havana cycle and both existing and new contributors worked to deliver
> double the number of blueprints than the previous release.  Our vibrant
> ecosystem makes me excited for the future of Neutron and I would love to
> continue as the PTL.
>
> Qualifications
> ---
>
> I am a Neutron core developer with 13 years of commercial Python
> development experience.  During my career, I have developed and deployed
> network applications based on the same underlying libraries used throughout
> Neutron.  I started contributing to Neutron project during the Essex
> development cycle.  In Folsom, I was promoted to core and was the primary
> developer of the DHCP implementation and Neutron's network namespace
> library.  During Grizzly, I worked on the metadata service, database
> migrations, and LBaaS reference implementation.
>
> Havana Accomplishments
> 
>
> During the Havana cycle, I worked as a developer, core team member, and a
> technical lead.
>
> - Planned and implemented the Quantum to Neutron name change.
> - Most active reviewer on the Neutron team (
> http://russellbryant.net/openstack-stats/neutron-reviewers-180.txt)
> - Organized the Networking track at the Havana Design Summit.
> - Led bug triaging and sub-team assignment.
> - Interfaced with vendors new to Neutron and helped in the integration of
> their plugins.
> - Assisted members of the community to further their understanding of
> Neutron and improve Python development best practices.
> - Promoted Neutron by delivering presentations at conferences and regional
> meet ups worldwide.
>
>
> Icehouse
> -
>
> During the Icehouse development cycle, I'd like to see the team focus on:
>
> - Continuing to grow the community of contributors and code reviewers.
> - Improving documentation for both deployers and developers.
> - Build upon the services added in Havana to extend and improve load
> balancing, firewalling, and VPN.
> - Integrating plugins from vendors new to the community including FWaaS,
> LBaaS, ML2, VPNaaS plugins/drivers.
> - More efficient Neutron system testing and gating including full Tempest
> testing.
> - Further work to ease deploying at scale.
> - Refactoring the API layer to leverage a common WSGI framework as other
> OpenStack projects.
> - Improving database resource modeling and extension management.
> - Unified network service management framework.
> - Continued support of the Horizon team to assist with Neutron integration.
> - Defined migration path from nova-network to Quantum.
>
> I'd love the opportunity to continue as the PTL and work with the Neutron
> team to fill in the gaps during the design summit in Hong Kong.
>
> Thanks,
> mark
>
>
>
>
> ___
> 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] Curvature and Donabe repos are now public!

[Edgar Magana]

Debo,

Congratulations on this move! The entire Cisco team is doing an awesome
work around OpenStack.

Cheers,

Edgar

On 10/3/13 11:43 AM, "Debojyoti Dutta"  wrote:

>Hi!
>
>We @Cisco just made the following repos public
>https://github.com/CiscoSystems/donabe
>https://github.com/CiscoSystems/curvature
>
>Donabe was pitched as a recursive container before Heat days.
>Curvature is an alternative interactive GUI front end to openstack
>that can handle virtual resources, templates and can instantiate
>Donabe workloads. The D3 + JS stuff was incorporated into Horizon. A
>short demo was shown last summit and can be found at
>http://www.openstack.org/summit/portland-2013/session-videos/presentation/
>interactive-visual-orchestration-with-curvature-and-donabe
>
>Congrats to the primary developers: @CaffeinatedBrad @John_R_Davidge
>@Tehsmash_ @JackPeterFletch ... Special thanks to @lewtucker for
>supporting this.
>
>Hope this leads to more cool stuff for the Openstack community!
>
>-- 
>-Debo~
>
>___
>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][Client] How do I list interfaces on a router?

[Edgar Magana]

Jay,

You need to find out if the router has ports active, for instance take a
look to this code:

def delete(self, request, obj_id):
try:
router_id = self.table.kwargs['router_id']
port = api.neutron.port_get(request, obj_id)
if port['device_owner'] == 'network:router_gateway':
api.neutron.router_remove_gateway(request, router_id)
else:
api.neutron.router_remove_interface(request, router_id, 
port_id=obj_id)




Regards,

Edgar

On 10/7/13 9:00 AM, "Jay Pipes"  wrote:

>Hi all,
>
>I've got code that is checking to see if a particular router has a
>public gateway set up, and if not, it wires up the gateway:
>
>print "Checking %s router setup ... " % zone.upper(),
>  try:
>router = qc.list_routers(name="demorouter")['routers']
>router = router[0]
>print "OK"
>  except IndexError:
>print "MISSING"
>print "--> Creating missing router ... ",
>router_data = dict(name="demorouter", admin_state_up=True)
>router = qc.create_router(dict(router=router_data))['router']
>print "OK"
>
>print "Checking %s router gateway ... " % zone.upper(),
>if router['external_gateway_info'] is None:
>   print "NOT SET"
>   print "--> Setting external gateway for router ... ",
>   pub_net_id = qc.list_networks(name="public")['networks'][0]['id']
>   net_dict = dict(network_id=pub_net_id)
>   qc.add_gateway_router(router['id'], net_dict)
>   print "OK"
>else:
>   print "OK"
>
>The above code works just fine. The next thing I need to check is
>whether the private subnet is wired into the router. I cannot seem to
>determine how to list interfaces for a particular router.
>
>I checked Horizon and it doesn't seem to have any idea how to do this
>either [1]. Is this just something that is missing from the Neutron API?
>If so, how do you suggest I determine if the demo router has been
>connected to the private subnet?
>
>Thanks in advance for any help,
>-jay
>
>https://github.com/openstack/horizon/blob/master/openstack_dashboard/api/n
>eutron.py 
>lines 660-708
>
>___
>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] Common requirements for services' discussion

[Edgar Magana]

Hello all,

Is anyone working on NATaaS?
I know we have some developer working on Router as a Service and they
probably want to include NAT functionality but I have some interest in
having NAT as a Service.

Please, response is somebody is interested in having some discussions about
it.  

Thanks,

Edgar

From:  Sumit Naiksatam 
Reply-To:  OpenStack List 
Date:  Tuesday, October 8, 2013 8:30 PM
To:  OpenStack List 
Subject:  [openstack-dev] [Neutron] Common requirements for services'
discussion

Hi All,

We had a VPNaaS meeting yesterday and it was felt that we should have a
separate meeting to discuss the topics common to all services. So, in
preparation for the Icehouse summit, I am proposing an IRC meeting on Oct
14th 22:00 UTC (immediately after the Neutron meeting) to discuss common
aspects related to the FWaaS, LBaaS, and VPNaaS.

We will begin with service insertion and chaining discussion, and I hope we
can collect requirements for other common aspects such as service agents,
services instances, etc. as well.

Etherpad for service insertion & chaining can be found here:
https://etherpad.openstack.org/icehouse-neutron-service-insertion-chaining

Hope you all can join.

Thanks,
~Sumit.


___ 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] Common requirements for services' discussion

[Edgar Magana]

Excellent points guys!

Salvatore, It was you presenting that blueprint in San Diego? Hopefully we
can get more people involved. I will not call it NATaaS Š

Harshad,

I also like to simplify as much as possible NAT configuration, in and out
networks and that is  :-)

Rudra,

IPAM extensions sounds very interesting and some how alignment to have NAT
implemented as individual service allowing vendor-technologies to be
included as well in Neutron but in the case of the AWS I don't see going in
the same direction, it seems like two different approaches, what do you
think?

Thanks,

Edgar


From:  Rudra Rugge 
Reply-To:  OpenStack List 
Date:  Thursday, October 10, 2013 5:22 PM
To:  OpenStack List 
Subject:  Re: [openstack-dev] [Neutron] Common requirements for services'
discussion

Here are the blueprints (mentioned by Harshad below) to add complete AWS
VPC compatibility in Openstack. AWS EC2 compatibility already exists in
Openstack. 

https://blueprints.launchpad.net/neutron/+spec/ipam-extensions-for-neutron
https://blueprints.launchpad.net/neutron/+spec/policy-extensions-for-neutron
https://blueprints.launchpad.net/nova/+spec/aws-vpc-support

Services extension is relevant to NATaas (or Natasha :)), VPNaas,
in AWS VPC.

Regards,
Rudra

On Oct 10, 2013, at 6:15 AM, Harshad Nakil 
 wrote:

> Agree, 
> I like what AWS had done. Have a concept of NAT instance. 90 % use cases are
> solved by just specifying
> Inside and outside networks for the NAT instance.
> 
> If one wants fancier NAT config they can always use NATaas API(s)
> To configure this instance.
> 
> There is a blueprint for bringing Amazon VPC API compatibility to nova and
> related extensions to quantum already propose concept of NAT instance.
> 
> How the NAT instance is implemented is left to the plugin.
> 
> Regards 
> -Harshad
> 
> 
> On Oct 10, 2013, at 1:47 AM, Salvatore Orlando  wrote:
> 
>> Can I just ask you to not call it NATaas... if you want to pick a name for
>> it, go for Natasha :)
>> 
>> By the way, the idea of a NAT service plugin was first introduced at the
>> Grizzly summit in San Diego.
>> One hurdle, not a big one however, would be that the external gateway and
>> floating IP features of the L3 extension already implicitly implements NAT.
>> It will be important to find a solution to ensure NAT can be configured
>> explicitly as well while allowing for configuring external gateway and
>> floating IPs through the API in the same way that we do today.
>> 
>> Apart from this, another interesting aspect would be to be see if we can come
>> up with an approach which will result in an API which abstracts as much as
>> possible networking aspects. In other words, I would like to avoid an API
>> which ends up being "iptables over rest", if possible.
>> 
>> Regards,
>> Salvatore
>> 
>> 
>> On 10 October 2013 09:55, Bob Melander (bmelande)  wrote:
>>> Hi Edgar,
>>> 
>>> I'm also interested in a broadening of NAT capability in Neutron using the
>>> evolving service framework.
>>> 
>>> Thanks,
>>> Bob
>>> 
>>> From: Edgar Magana 
>>> Reply-To: OpenStack Development Mailing List
>>> 
>>> Date: onsdag 9 oktober 2013 21:38
>>> To: OpenStack List 
>>> Subject: Re: [openstack-dev] [Neutron] Common requirements for services'
>>> discussion
>>> 
>>> Hello all,
>>> 
>>> Is anyone working on NATaaS?
>>> I know we have some developer working on Router as a Service and they
>>> probably want to include NAT functionality but I have some interest in
>>> having NAT as a Service.
>>> 
>>> Please, response is somebody is interested in having some discussions about
>>> it.  
>>> 
>>> Thanks,
>>> 
>>> Edgar
>>> 
>>> From: Sumit Naiksatam 
>>> Reply-To: OpenStack List 
>>> Date: Tuesday, October 8, 2013 8:30 PM
>>> To: OpenStack List 
>>> Subject: [openstack-dev] [Neutron] Common requirements for services'
>>> discussion
>>> 
>>> Hi All,
>>> 
>>> We had a VPNaaS meeting yesterday and it was felt that we should have a
>>> separate meeting to discuss the topics common to all services. So, in
>>> preparation for the Icehouse summit, I am proposing an IRC meeting on Oct
>>> 14th 22:00 UTC (immediately after the Neutron meeting) to discuss common
>>> aspects related to the FWaaS, LBaaS, and VPNaaS.
>>> 
>>> We will begin with service insertion and chaining discussion, and I hope we
>>> can collect requirements for other common 

Re: [openstack-dev] [GIT] Reset a commit in Gerrit

[Edgar Magana]

Floren,

Just just need to send a patch to gerrit.

>From you local repo, do the necessary fixes and be sure everything is just
as you want.
Then simply run:
#git commit -a --amend
#git review

Thanks,

Edgar

On 10/20/13 11:26 AM, "Floren Llanos"  wrote:

>Hello,
>
>I'm a newbie contributor in Openstack, and I'm newbie using git and
>gerrit too.
>
>I committed a change to gerrit of two files but one of them is not
>correct and I must to undo the change (only one of this files). I need
>to remove this file from gerrit and leave only one.
>
>I found in http://git-scm.com/book/ that I can use git checkout --
> to undo the change in my local environment and I've read about
>git reset too, but I've understand that if this use it's only for
>stashing files. I don't know how undo the change in gerrit (remote).
>
>Thanks in advance,
>
>Floren
>
>___
>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] [Heat] Network topologies

[Edgar Magana]

Heat Developers,

I am one of the core developers for Neutron who is lately working on the
concept of "Network Topologies". I want to discuss with you if the
following blueprint will make sense to have in heat or neutron code:
https://blueprints.launchpad.net/neutron/+spec/network-topologies-api

Basically, I want to let tenants “save”, “duplicate” and “share” network
topologies by means of an API and a standardized JSON format that describes
network topologies. This google document provides detailed description:
https://docs.google.com/document/d/1nPkLcUma_nkmuHYxCuUZ8HuryH752gQnkmrZdXeE2LM/edit#

There is a concern in Neutron of not duplicating efforts done by Heat team
and also to find the right place for this API.

The intended work does NOT include any application driven orchestration
system, does NOT include any already existing or vender-specific standard
format for describing topologies, actually we want to standardized one
based on Neutron but it is still on discussion.

If Heat developers could provide their point of view about this proposal,
wether it should be moved to Heat or it is fine to keep it in Neutron.

Thanks,

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

Re: [openstack-dev] [Heat] Network topologies

[Edgar Magana]

Hello Folks,

Thank you Zane, Steven and Clint for you input.

Our main goal in this BP is to provide networking users such as Heat (we
consider it as a neutron user) a better and consolidated network building
block in terms of an API that you could use for orchestration of
application-driven requirements. This building block does not add any
"intelligence" to the network topology because it does not have it and
this is why I think this BP is different from the work that you are doing
in Heat.

The network topologies BP is not related to the Neutron Network Service
Insertion BP:
https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-c
haining-steering


I do agree with Steven that the insertion work add "intelligence"
(explicit management of dependencies, state and workflow) to the network
orchestration simply because user will need to know the insertion
mechanism and dependencies between Network Advances Services, that work is
more into Heat space that the BP that I am proposing but that is just my
opinion.

However, is there a session where I can discuss this BP with you guys?,
the session that I proposed in Neutron has been rejected because it was
considered by the PTL as an overlapping work with the Heat goals,
therefore I wanted to know if you can to discuss it or I just simple go
ahead and start the implementation. I do still believe it can be easily
implemented in Neutron and then exposed to Heat but I am really looking
forward to having a broader discussion.

Thanks,

Edgar


On 10/28/13 9:47 AM, "Clint Byrum"  wrote:

>Excerpts from Steven Hardy's message of 2013-10-28 07:47:06 -0700:
>> On Sun, Oct 27, 2013 at 08:37:15AM -0700, Edgar Magana wrote:
>> > Heat Developers,
>> > 
>> > I am one of the core developers for Neutron who is lately working on
>>the
>> > concept of "Network Topologies". I want to discuss with you if the
>> > following blueprint will make sense to have in heat or neutron code:
>> > https://blueprints.launchpad.net/neutron/+spec/network-topologies-api
>> > 
>> > Basically, I want to let tenants ³save², ³duplicate² and ³share²
>>network
>> > topologies by means of an API and a standardized JSON format that
>>describes
>> > network topologies. This google document provides detailed
>>description:
>> > 
>>https://docs.google.com/document/d/1nPkLcUma_nkmuHYxCuUZ8HuryH752gQnkmrZd
>>XeE2LM/edit#
>> > 
>> > There is a concern in Neutron of not duplicating efforts done by Heat
>>team
>> > and also to find the right place for this API.
>> > 
>> > The intended work does NOT include any application driven
>>orchestration
>> > system, does NOT include any already existing or vender-specific
>>standard
>> > format for describing topologies, actually we want to standardized one
>> > based on Neutron but it is still on discussion.
>> > 
>> > If Heat developers could provide their point of view about this
>>proposal,
>> > wether it should be moved to Heat or it is fine to keep it in Neutron.
>> 
>> This seems related to a discussion I had last week re the Neutron
>>services
>> insertion and chaining functionality:
>> 
>> 
>>https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion
>>-chaining-steering
>> 
>> It does seem that you (Neutron) are moving towards functionality which
>> requires more explicit management of dependencies, state and workflow,
>>such
>> that it may make sense to implement, some of it at least, in Heat.
>> 
>> My opinion is that we should expose all of the underlying Neutron
>> capabilities (individual bits of functionality) via Heat resources,
>>which I
>> think we're currently doing quite well (see [1] for the current list of
>> supported functionality)
>> 
>> Then any functionality requiring aggregation of resources where
>> dependencies and state are used to create a workflow, should probably
>> happen in Heat, IMHO.  It doesn't make sense to me to have two projects
>> building a dependency graph, managing state, and orchestrating workflow
>>for
>> the same underlying Neutron features.
>> 
>
>Could not have said it better myself, thanks Steve.
>
>One thing this brings to mind is the proposal for adopt/abandon. This
>may be a new use case for that feature in Heat.
>
>Neutron would be able to adopt all of the standing network topology to
>do the serialization into a HOT template, and give it to the Neutron user.
>
>Then to reverse the process Neutron can accept this Heat template
>back from the user, and just use it to

Re: [openstack-dev] [Heat] Network topologies

[Edgar Magana]

Tim,

You statement "building an api that manages a network topology more than
one that needs to build out the dependencies between resources to help
create the network topology"
Is exactly what we are proposing, and this is why we believe this is not
under Heat domain.

This is why we are NOT proposing to manage any dependency between network
elements, that part is what I call "intelligence" of the orchestration and
we are not proposing any orchestration system, you are already have that
in place :-)

So, we simple want an API that tenats may use to "save", "retrieve" and
"share" topologies. For instance, tenant A creates a topology with two
networks (192.168.0.0/24 and 192.168.1.0/24) both with dhcp enabled and a
router connecting them. So, we first create it using CLI commands or
Horizon and then we call the API to save the topology for that tenant,
that topology can be also share  between tenants if the owner wanted to do
that, the same concept that we have in Neutron for "share networks", So
Tenant B or any other Tenants, don't need to re-create the whole topology,
just "open" the shared topology from tenant A. Obviously, overlapping IPs
will be a "must" requirement.

I am including in this thread to Mark McClain who is the Neutron PTL and
the main guy expressing concerns in not  having overlapping
functionalities between Neutron and Heat or any other project.

I am absolutely, happy to discuss further with you but if you are ok with
this approach we could start the development in Neutron umbrella, final
thoughts?

Thanks,

Edgar

On 10/29/13 8:23 AM, "Tim Schnell"  wrote:

>Hi Edgar,
>
>It seems like this blueprint is related more to building an api that
>manages a network topology more than one that needs to build out the
>dependencies between resources to help create the network topology. If we
>are talking about just an api to "save", "duplicate", and "share" these
>network topologies then I would agree that this is not something that Heat
>currently does or should do necessarily.
>
>I have been focusing primarily on front-end work for Heat so I apologize
>if these questions have already been answered. How is this API related to
>the existing network topology in Horizon? The existing network topology
>can already define the relationships and dependencies using Neutron I'm
>assuming so there is no apparent need to use Heat to gather this
>information. I'm a little confused as to the scope of the discussion, is
>that something that you are potentially interested in changing?
>
>Steve, Clint and Zane can better answer whether or not Heat wants to be in
>the business of managing existing network topologies but from my
>perspective I tend to agree with your statement that if you needed Heat to
>help describe the relationships between network resources then that might
>be duplicated effort but if don't need Heat to do that then this blueprint
>belongs in Neutron.
>
>Thanks,
>Tim
>
>
>
>
>
>On 10/29/13 1:32 AM, "Steven Hardy"  wrote:
>
>>On Mon, Oct 28, 2013 at 01:19:13PM -0700, Edgar Magana wrote:
>>> Hello Folks,
>>> 
>>> Thank you Zane, Steven and Clint for you input.
>>> 
>>> Our main goal in this BP is to provide networking users such as Heat
>>>(we
>>> consider it as a neutron user) a better and consolidated network
>>>building
>>> block in terms of an API that you could use for orchestration of
>>> application-driven requirements. This building block does not add any
>>> "intelligence" to the network topology because it does not have it and
>>> this is why I think this BP is different from the work that you are
>>>doing
>>> in Heat.
>>
>>So how do you propose to handle dependencies between elements in the
>>topology, e.g where things need to be created/deleted in a particular
>>order, or where one resource must be in a particular state before another
>>can be created?
>>
>>> The network topologies BP is not related to the Neutron Network Service
>>> Insertion BP:
>>> 
>>>https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertio
>>>n
>>>-c
>>> haining-steering
>>
>>So I wasn't saying they were related, only that they both, arguably, may
>>have some scope overlap with what Heat is doing.
>>
>>> I do agree with Steven that the insertion work add "intelligence"
>>> (explicit management of dependencies, state and workflow) to the
>>>network
>>> orchestration simply because user will need to know the insertion
>>> mech

Re: [openstack-dev] [Heat] Network topologies

[Edgar Magana]

Aaron,

Moving the management of topology?
I am not proposing nothing like that, actually could you explain me the
current workflow to save a network topology created by Neutron APIs, in
order to use it by a different tenant or the owner itself in a different
time?
Possibly, that is the part that I am missing and it will help me to improve
current proposal.

Thanks,

Edgar

From:  Aaron Rosen 
Reply-To:  OpenStack List 
Date:  Tuesday, October 29, 2013 12:48 PM
To:  OpenStack List 
Subject:  Re: [openstack-dev] [Heat] Network topologies

Hi Edgar, 

I definitely see the usecase for the idea that you propose. In my opinion, I
don't see the reason for moving the management of topology into neutron,
Heat already provides this functionality (besides for the part of taking an
existing deployment and generating a template file). Also, I wanted to point
out that in a way you will have to do orchestration as you're topology
manager will have to call the neutron api in order to create the topology
and tear it down. 

Best, 

Aaron


On Tue, Oct 29, 2013 at 11:33 AM, Edgar Magana  wrote:
> Tim,
> 
> You statement "building an api that manages a network topology more than
> one that needs to build out the dependencies between resources to help
> create the network topology"
> Is exactly what we are proposing, and this is why we believe this is not
> under Heat domain.
> 
> This is why we are NOT proposing to manage any dependency between network
> elements, that part is what I call "intelligence" of the orchestration and
> we are not proposing any orchestration system, you are already have that
> in place :-)
> 
> So, we simple want an API that tenats may use to "save", "retrieve" and
> "share" topologies. For instance, tenant A creates a topology with two
> networks (192.168.0.0/24 <http://192.168.0.0/24>  and 192.168.1.0/24
> <http://192.168.1.0/24> ) both with dhcp enabled and a
> router connecting them. So, we first create it using CLI commands or
> Horizon and then we call the API to save the topology for that tenant,
> that topology can be also share  between tenants if the owner wanted to do
> that, the same concept that we have in Neutron for "share networks", So
> Tenant B or any other Tenants, don't need to re-create the whole topology,
> just "open" the shared topology from tenant A. Obviously, overlapping IPs
> will be a "must" requirement.
> 
> I am including in this thread to Mark McClain who is the Neutron PTL and
> the main guy expressing concerns in not  having overlapping
> functionalities between Neutron and Heat or any other project.
> 
> I am absolutely, happy to discuss further with you but if you are ok with
> this approach we could start the development in Neutron umbrella, final
> thoughts?
> 
> Thanks,
> 
> Edgar
> 
> On 10/29/13 8:23 AM, "Tim Schnell"  wrote:
> 
>> >Hi Edgar,
>> >
>> >It seems like this blueprint is related more to building an api that
>> >manages a network topology more than one that needs to build out the
>> >dependencies between resources to help create the network topology. If we
>> >are talking about just an api to "save", "duplicate", and "share" these
>> >network topologies then I would agree that this is not something that Heat
>> >currently does or should do necessarily.
>> >
>> >I have been focusing primarily on front-end work for Heat so I apologize
>> >if these questions have already been answered. How is this API related to
>> >the existing network topology in Horizon? The existing network topology
>> >can already define the relationships and dependencies using Neutron I'm
>> >assuming so there is no apparent need to use Heat to gather this
>> >information. I'm a little confused as to the scope of the discussion, is
>> >that something that you are potentially interested in changing?
>> >
>> >Steve, Clint and Zane can better answer whether or not Heat wants to be in
>> >the business of managing existing network topologies but from my
>> >perspective I tend to agree with your statement that if you needed Heat to
>> >help describe the relationships between network resources then that might
>> >be duplicated effort but if don't need Heat to do that then this blueprint
>> >belongs in Neutron.
>> >
>> >Thanks,
>> >Tim
>> >
>> >
>> >
>> >
>> >
>> >On 10/29/13 1:32 AM, "Steven Hardy"  wrote:
>> >
>>> >>On Mon, Oct 28, 2013 at 01:19:13PM -0700, Edgar Magana wrote:
>>>

Re: [openstack-dev] [Heat] Network topologies

[Edgar Magana]

Zen, Kevin, Aaron, Salvatore et al,

Thank you so much for taking some time and reviewing this proposal. I
couldn't get any time slot neither in Neutron nor Heat track to have a deep
discussion about this proposal. My conclusions are the following:

- This API should be allocated in Heat project, at least will start there
and see how the implementation goes. I am new in Heat, so I will need some
help  :-)
- There are a lot of people who find it interested and useful, therefore It
should be implemented.
- It should be extended to all new "advanced services" (VPNaaS, FWaaS,
LBaaS)
- Dependencies should be included, my point here is to let tenants to
do/control that, even if they make mistakes, is there network design after
all.
- Horizon support will bring a lot of visibility, I will prepare some
mock-ups.

Open Questions:
Is there enough interest in order to schedule an "unconference" session?
 (don't want to be the only one in the room)
What would happen with the concept of "Services Insertion in Neutron"?
Should it be also move to Heat?


Thanks again everybody and I will see you in just one more day.

Edgar



On Sat, Nov 2, 2013 at 1:12 PM, Salvatore Orlando wrote:

> Hi.
>
> I looked at the detailed API specification submitted by Edgar.
> I think that the document Edgar shared does a fine job in discussion how
> an API for managing logical topologies should work.
> On the other hand, there are two aspects which still need some
> clarification, and which perhaps are at the source of the confusion
> regarding whether it belongs to neutron, heat, or anywhere else.
>
> First, the "use cases" section merely re-states the objective session. I
> think that section should somehow address the questions "why do we need
> this API?" "How having an API for storing network topologies would be
> useful for us".
>
> The other aspect is that - and I might be terribly wrong here - I think
> that one of the goals Neutron API was already supposed to abstract the
> complexity of network topologies - if we need another API (or perhaps more
> aptly an extension of the Neutron API) to satisfy this goal, does this mean
> the Neutron API is failing in one of its main goals?
>
> Finally it would be interesting to have a few more details concerning how
> topologies created with this new API would be reflected on the existing
> data model. While this appears easy for bridges and routers, it is not
> immediate for other 'nfds' such as dhcp services.
>
> Salvatore
>
>
> On 29 October 2013 19:48, Aaron Rosen  wrote:
>
>> Hi Edgar,
>>
>> I definitely see the usecase for the idea that you propose. In my
>> opinion, I don't see the reason for moving the management of topology into
>> neutron,  Heat already provides this functionality (besides for the part of
>> taking an existing deployment and generating a template file). Also, I
>> wanted to point out that in a way you will have to do orchestration as
>> you're topology manager will have to call the neutron api in order to
>> create the topology and tear it down.
>>
>> Best,
>>
>> Aaron
>>
>>
>> On Tue, Oct 29, 2013 at 11:33 AM, Edgar Magana wrote:
>>
>>> Tim,
>>>
>>> You statement "building an api that manages a network topology more than
>>> one that needs to build out the dependencies between resources to help
>>> create the network topology"
>>> Is exactly what we are proposing, and this is why we believe this is not
>>> under Heat domain.
>>>
>>> This is why we are NOT proposing to manage any dependency between network
>>> elements, that part is what I call "intelligence" of the orchestration
>>> and
>>> we are not proposing any orchestration system, you are already have that
>>> in place :-)
>>>
>>> So, we simple want an API that tenats may use to "save", "retrieve" and
>>> "share" topologies. For instance, tenant A creates a topology with two
>>> networks (192.168.0.0/24 and 192.168.1.0/24) both with dhcp enabled and
>>> a
>>> router connecting them. So, we first create it using CLI commands or
>>> Horizon and then we call the API to save the topology for that tenant,
>>> that topology can be also share  between tenants if the owner wanted to
>>> do
>>> that, the same concept that we have in Neutron for "share networks", So
>>> Tenant B or any other Tenants, don't need to re-create the whole
>>> topology,
>>> just "open" the shared topology from tenant A. Obviously, overlapping IPs
>&g

Re: [openstack-dev] [Heat] Design summit etherpads

[Edgar Magana]

Steve, 

Can we meet to talk about the network topologies BP?
If you have an open spot I want to chat about it with Heat team

Sent from my iPhone

> On Nov 5, 2013, at 9:19 AM, Steve Baker  wrote:
> 
> Placeholder etherpads have now been created for Heat's design summit sessions 
> on Thursday and Friday.
> 
> https://wiki.openstack.org/wiki/Summit/Icehouse/Etherpads#Heat
> ___
> 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] IPv6 sub-team?

[Edgar Magana]

Absolutely!

+1

Edgar

On 11/5/13 3:50 PM, "Collins, Sean (Contractor)"
 wrote:

>Hi,
>
>Is there any interest in organizing a IPv6 sub-team, similar to how
>there are sub-teams for FwaaS, VPNaas, ML2, etc?
>
>-- 
>Sean M. Collins
>AIM: seanwdp
>___
>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] New plug-ins requirements

[Edgar Magana]

Team,

It has been decided during the Icehouse summit that all vendor specific
plug-ins should enforce remote tempest tests:
http://ci.openstack.org/third_party.html

I would like to understand if we will apply this rule for any new plug-in
during Icehouse or we will start applying this new requirement until "J"
timeframe.

I do believe that should enforce this new requirement ASAP but I also
believe that we need to provide a little bit more of guidance on this
process.
So, Besides the above mentioned wiki, is there any more information that we
can provide about this new requirement? I think we should update Neutron
wiki with this information.
If somebody is very familiar with the process will be interested in posting
their input on this thread.

Thanks,

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

Re: [openstack-dev] [neutron] Group-based Policy Sub-team Meetings

[Edgar Magana]

I do agree with need to sometime to recovery from HK and get the meetings
started next week!

Edgar

On 11/13/13 9:57 AM, "Kyle Mestery (kmestery)"  wrote:

>On Nov 13, 2013, at 10:36 AM, Stephen Wong 
> wrote:
>
>> Hi Kyle,
>> 
>>So no meeting this Thursday?
>> 
>I am inclined to skip this week's meeting due to the fact I haven't heard
>many
>replies yet. I think a good starting point for people would be to review
>the
>BP [1] and Design Document [2] and provide feedback where appropriate.
>We should start to formalize what the APIs will look like at next week's
>meeting,
>and the Design Document has a first pass at this.
>
>Thanks,
>Kyle
>
>[1] 
>https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstract
>ion
>[2] 
>https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIru
>pCD9E/edit?usp=sharing
>
>> Thanks,
>> - Stephen
>> 
>> On Wed, Nov 13, 2013 at 7:11 AM, Kyle Mestery (kmestery)
>>  wrote:
>>> On Nov 13, 2013, at 8:58 AM, "Stein, Manuel (Manuel)"
>>> wrote:
>>> 
 Kyle,
 
 I'm afraid your meeting vanished from the Meetings page [2] when user
amotiki reworked neutron meetings ^.^
 Is the meeting for Thu 1600 UTC still on?
 
>>> Ack, thanks for the heads up here! I have re-added the meeting. I only
>>>heard
>>> back from one other person other than yourself, so at this point I'm
>>>inclined
>>> to wait until next week to hold our first meeting unless I hear back
>>>from others.
>>> 
 A few heads-up questions (couldn't attend the HK design summit Friday
meeting):
 
 1) In the summit session Etherpad [3], ML2 implementation mentions
insertion of arbitrary metadata to hint to underlying implementation.
Is that (a) the plug-ing reporting its policy-bound realization? (b)
the user further specifying what should be used? (c) both? Or (d) none
of that but just some arbitrary message of the day?
 
>>> I believe that would be (a).
>>> 
 2) Would policies _always_ map to the old Neutron entities?
 E.g. when I have policies in place, can I query related network/port,
subnet/address, router elements on the API or are there no equivalents
created? Would the logical topology created under the policies be
exposed otherwise? for e.g. monitoring/wysiwyg/troubleshoot purposes.
 
>>> No, this is up to the plugin/MechanismDriver implementation.
>>> 
 3) Do the chain identifier in your policy rule actions match to
"Service Chain UUID" in Service Insertion, Chaining and API [4]
 
>>> That's one way to look at this, yes.
>>> 
 4) Are you going to describe L2 services the way group policies work?
I mean, why would I need a LoadBalancer or Firewall instance before I
can insert it between two groups when all that load
balancing/firewalling requires is nothing but a policy for group
communication itself? - regardless the service instance used to carry
out the service.
 
>>> These are things I'd like to discuss at the IRC meeting each week. The
>>>goal
>>> would be to try and come up with some actionable items we can drive
>>>towards
>>> in both Icehouse-1 and Icehouse-2. Given how close the closing of
>>>Icehouse-1
>>> is, we need to focus on this very fast if we want to have a measurable
>>>impact in
>>> Icehouse-1.
>>> 
>>> Thanks,
>>> Kyle
>>> 
>>> 
 Best, Manuel
 
 [2] 
https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_Sub-Team_
Meeting
 [3] 
https://etherpad.openstack.org/p/Group_Based_Policy_Abstraction_for_Neu
tron
 [4] 
https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh
0Wl3YF2U/edit#
 
> -Original Message-
> From: Kyle Mestery (kmestery) [mailto:kmest...@cisco.com]
> Sent: Montag, 11. November 2013 19:41
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: [openstack-dev] [neutron] Group-based Policy
> Sub-team Meetings
> 
> Hi folks! Hope everyone had a safe trip back from Hong Kong.
> Friday afternoon in the Neutron sessions we discussed the
> "Group-based Policy Abstraction" BP [1]. It was decided we
> would try to have a weekly IRC meeting to drive out further
> requirements with the hope of coming up with a list of
> actionable tasks to begin working on by December.
> I've tentatively set the meeting [2] for Thursdays at 1600
> UTC on the #openstack-meeting-alt IRC channel. If there are
> serious conflicts with this day and time, please speak up
> soon. Otherwise, we'll host our first meeting on Thursday this week.
> 
> Thanks!
> Kyle
> 
> [1]
> https://blueprints.launchpad.net/neutron/+spec/group-based-pol
 icy-abstraction
> [2]
> https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_
> Sub-Team_Meeting
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
>

Re: [openstack-dev] [Neutron] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

[Edgar Magana]

Anita,

Could you prepare the invitation letters for the ones that will require a
visa?, which is my case.

Thanks,

Edgar

On 11/13/13 8:10 AM, "Anita Kuno"  wrote:

>Neutron Tempest code sprint
>
>In the second week of January in Montreal, Quebec, Canadathere will be a
>Neutron Tempest code sprint to improve the status of Neutron tests in
>Tempest and to add new tests.
>It will be a 3 day event. Right now there are 14 peoplewho came forward
>when it was announced on the Friday at the summit. We need to know how
>many additional people are interested in attending.
>
>This is an impromptu event based on my assessment of the need for this
>to happen, so don't feel left out if you didn't know about it in advance.
>
>We picked Montreal for two main reasons:
>1. All 4 people whose attendance is critical (markmclain, salv-orlando,
>sdague and mtrenish) can get there. It was New York or Montreal.
>2. I can't think in New York, love it, can't compose a thought, so
>Montreal it is.
>
>It turns out this location choice has some resultant effects:
>1. People who wouldn't have time to get a visa to attend an event in the
>States have an easier time entering Canada.
> US requires visa applications filed 2 months in advance of travel
>and we are inside that timeframe.
>2. Montreal is cheaper than NYC.
>3. Being Canadian it is going to be easier for me to produce this event
>in Canada since I am in Canada.
>4. It will be cold. We had few choices on the timing and this event
>can't wait on good weather.
>
>There is no location that will make everyone happy, so people will be
>disappointed by this choice and I accept that. It is my hope that this
>event is a success and we can create a schedule of some sort so that
>people who have a high possibility of attending can vote on the
>location. So that is the future vision.
>
>I have a tenative hold on a venue and am working on getting a rate on a
>block of rooms at a hotel.
>
>I am preparing a budget to submit to the Foundation in the hopes they
>will sponsor the event. Since this was planned with no warning, the
>Foundation has no budget for it. Mark is supportive of the event
>happening and if I can come up with some reasonable numbers, I hope that
>the money can come from the Foundation.
>
>The event will be vendor neutral. We will talk to each other based on
>who we are and our interests, not based on who signs our paycheque. If
>folks arrive with logoed shirts (I don't know which logos are work logos
>and which aren't, so I will request no logos please) I will issue you a
>white T-shirt to wear. We need to work collaboratively to effectlvely
>make progress during the code sprint.
>
>Someone at the summit choose not to wear footwear at the event. If you
>want to come to the code sprint please plan on wearing appropriate
>footwear in the public areas at the code sprint. For two reasons:
>1. It will be cold.
>2. The event is meant to facilitate mutual respect between us to
>increase communication, both at the event and afterwards. I feel wearing
>appropriate footwear supports this goal.
>
>Please indicate your interest by sending an email to
>ante...@anteaya.info, subject "Neutron Tempest code sprint". Don't worry
>about the body of the email, I just need addresses. We will send out
>subsequent emails to this group to gather specific details like shirt
>size, dietary requirements. If you came forward at the summit, no need
>to email again.
>
>If you want to come, but don't feel your employer will fund the trip,
>please include that information in the email. It will depend on what we
>can do for accomodation and travel but hopefully we will have a little
>bit for a few folks. Of course please talk to your manager now to work
>on getting approval to attend, and hopefully your employeer will fund
>your travel and accomodation.
>
>Additional questions? Hit me up on irc in #openstack-neutron nick
>anteaya. I read the neutron logs:
>http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/So I will
>get back to you if I am not around when you ask.
>
>Also rossella_s has come forward to help, thank you rossella_s!
>
>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] Neutron Tempest code sprint - 2nd week of January, Montreal, QC, Canada

[Edgar Magana]

Will do ASAP.

Thanks,

Edgar

On 11/13/13 10:20 AM, "Anita Kuno"  wrote:

>Hi Edgar:
>
>I hadn't thought of that, I guess I am going to have to do that.
>
>For others, check if you need a visa to enter Canada:
>http://www.cic.gc.ca/ENGLISH/visit/visas.asp
>Please notify me ASAP if you do, even if you aren't sure you can attend
>so I can get the paperwork you need.
>
>Edgar, can you email me your address to my personal email anteaya at
>anteaya dot info so I can work on this for you.
>
>Thanks,
>Anita.
>
>On 11/13/2013 01:12 PM, Edgar Magana wrote:
>> Anita,
>>
>> Could you prepare the invitation letters for the ones that will require
>>a
>> visa?, which is my case.
>>
>> Thanks,
>>
>> Edgar
>>
>> On 11/13/13 8:10 AM, "Anita Kuno"  wrote:
>>
>>> Neutron Tempest code sprint
>>>
>>> In the second week of January in Montreal, Quebec, Canadathere will be
>>>a
>>> Neutron Tempest code sprint to improve the status of Neutron tests in
>>> Tempest and to add new tests.
>>> It will be a 3 day event. Right now there are 14 peoplewho came forward
>>> when it was announced on the Friday at the summit. We need to know how
>>> many additional people are interested in attending.
>>>
>>> This is an impromptu event based on my assessment of the need for this
>>> to happen, so don't feel left out if you didn't know about it in
>>>advance.
>>>
>>> We picked Montreal for two main reasons:
>>> 1. All 4 people whose attendance is critical (markmclain, salv-orlando,
>>> sdague and mtrenish) can get there. It was New York or Montreal.
>>> 2. I can't think in New York, love it, can't compose a thought, so
>>> Montreal it is.
>>>
>>> It turns out this location choice has some resultant effects:
>>> 1. People who wouldn't have time to get a visa to attend an event in
>>>the
>>> States have an easier time entering Canada.
>>>  US requires visa applications filed 2 months in advance of travel
>>> and we are inside that timeframe.
>>> 2. Montreal is cheaper than NYC.
>>> 3. Being Canadian it is going to be easier for me to produce this event
>>> in Canada since I am in Canada.
>>> 4. It will be cold. We had few choices on the timing and this event
>>> can't wait on good weather.
>>>
>>> There is no location that will make everyone happy, so people will be
>>> disappointed by this choice and I accept that. It is my hope that this
>>> event is a success and we can create a schedule of some sort so that
>>> people who have a high possibility of attending can vote on the
>>> location. So that is the future vision.
>>>
>>> I have a tenative hold on a venue and am working on getting a rate on a
>>> block of rooms at a hotel.
>>>
>>> I am preparing a budget to submit to the Foundation in the hopes they
>>> will sponsor the event. Since this was planned with no warning, the
>>> Foundation has no budget for it. Mark is supportive of the event
>>> happening and if I can come up with some reasonable numbers, I hope
>>>that
>>> the money can come from the Foundation.
>>>
>>> The event will be vendor neutral. We will talk to each other based on
>>> who we are and our interests, not based on who signs our paycheque. If
>>> folks arrive with logoed shirts (I don't know which logos are work
>>>logos
>>> and which aren't, so I will request no logos please) I will issue you a
>>> white T-shirt to wear. We need to work collaboratively to effectlvely
>>> make progress during the code sprint.
>>>
>>> Someone at the summit choose not to wear footwear at the event. If you
>>> want to come to the code sprint please plan on wearing appropriate
>>> footwear in the public areas at the code sprint. For two reasons:
>>> 1. It will be cold.
>>> 2. The event is meant to facilitate mutual respect between us to
>>> increase communication, both at the event and afterwards. I feel
>>>wearing
>>> appropriate footwear supports this goal.
>>>
>>> Please indicate your interest by sending an email to
>>> ante...@anteaya.info, subject "Neutron Tempest code sprint". Don't
>>>worry
>>> about the body of the email, I just need addresses. We will send out
>>> subsequent emails to this group to gather specific details like shirt
>>

Re: [openstack-dev] [Neutron] New plug-ins requirements

[Edgar Magana]

Salvatore,

I do agree with you. When I said in my first email "little bit of guidance"
I mean the policy for Icehouse and moving forward. I do not want to make
our PTL angry  :-)

Mark,

I hope you can commend on this thread, otherwise I will bring this topic on
our next IRC meeting.

Thanks,

Edgar


On Wed, Nov 13, 2013 at 7:11 PM, Salvatore Orlando wrote:

> I reckon we should wait a little for the PTL to propose a draft of the
> policy we can comment on.
>
> 'thirdy paty test' probably was meant as integration with gerrit (
> http://ci.openstack.org/third_party.html); the test suite to be executed
> is, obviously, the tempest test suite.
> In my opinion, the policy will define criteria for acceptability of
> skipped tests and ability of adding plugin-specific tests.
>
> Regards,
> Salvatore
>
>
> On 12 November 2013 15:15, Kyle Mestery (kmestery) wrote:
>
>> On Nov 12, 2013, at 2:46 AM, Robert Collins 
>> wrote:
>> > On 12 November 2013 21:15, Edgar Magana  wrote:
>> >> Team,
>> >>
>> >> It has been decided during the Icehouse summit that all vendor specific
>> >> plug-ins should enforce remote tempest tests:
>> >> http://ci.openstack.org/third_party.html
>> >>
>> >> I would like to understand if we will apply this rule for any new
>> plug-in
>> >> during Icehouse or we will start applying this new requirement until
>> "J"
>> >> timeframe.
>> >
>> > I can't comment on when - thats a Neutron dev decision, but I heartily
>> > endorse getting all code paths tested asap :).
>> >
>> My personal opinion is if we are going to require all existing Neutron
>> plugins to
>> have valid smokestack tests by Icehouse-2, then any new plugins should not
>> be allowed into the tree without those tests. This includes new Modular
>> Layer 2
>> MechanismDrivers as well.
>>
>> >> I do believe that should enforce this new requirement ASAP but I also
>> >> believe that we need to provide a little bit more of guidance on this
>> >> process.
>> >> So, Besides the above mentioned wiki, is there any more information
>> that we
>> >> can provide about this new requirement? I think we should update
>> Neutron
>> >> wiki with this information.
>> >> If somebody is very familiar with the process will be interested in
>> posting
>> >> their input on this thread.
>> >
>> > I think the requirement of 'use third party tests' is confusing goal
>> > with implementation: the goal should be that 'all vendor plugins be CI
>> > tested at verification level at minimum'. This leaves room for gate
>> > based testing of such plugins too, if the vendor steps up and meets
>> > the requirements to have their plugin be gate checked - which is
>> > superior to merely doing verification checks.
>> >
>> > -Rob
>>
>>
>>
>>
>> ___
>> 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] Port mirroring

[Edgar Magana]

Hello Rossella,

Kyle has a very good point and I wanted to add the documentation request.
Be sure you have a wiki/document (not a technical one) that we can easily
transfer into the OpenStack Docs.

This is a great feature, any idea of the overhead that it will cause?
I assume that this is going to be totally configurable, right?  :-)

Edgar

On 11/14/13 8:34 AM, "Kyle Mestery (kmestery)"  wrote:

>On Nov 14, 2013, at 8:46 AM, Rossella Sblendido 
>wrote:
>> 
>> Hello devs,
>> 
>> I'd like to start working at this blueprint:
>> 
>> https://blueprints.launchpad.net/neutron/+spec/port-mirroring
>> 
>> I didn't receive much feedback so please have a look at it.
>> 
>> It was not approved yet. What's the usual workflow? Shall I wait for
>>approval before I start implementing it? Sorry for the trivial question
>>but I'm new here.
>> 
>Welcome Rossella!
>
>One issue I have with the design document linked in the blueprint is the
>testing section has nothing in it all. Given we're trying hard to focus
>on quality and testing, I'd like you to add some specific testing
>information to the document before we approve it. It would be ideal to
>have Tempest tests which test out the new API functionality as well.
>That's my main issue with this BP as seen now, but I'd like others to
>comment on this as well.
>
>Thanks!
>Kyle
>
>> thanks,
>> 
>> Rossella
>> 
>> ___
>> 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] Blueprint -- Floating IP Auto Association

[Edgar Magana]

Thanks Steven for working on this topic!

I would prefer the second approach, although there were some discussions
during the summit about moving all calls to Neutron instead of having nova
involved.
Anyway, just providing my two cents

Thanks,

Edgar

From:  Salvatore Orlando 
Reply-To:  OpenStack List 
Date:  Thursday, November 14, 2013 3:21 AM
To:  OpenStack List 
Subject:  Re: [openstack-dev] [Neutron] Blueprint -- Floating IP Auto
Association

Hi Steven,

I see three Steven Weston on Launchpad. If you give me your LP ID, I will
assign the blueprint to you.
This is a nova parity item and i'd like to raise the priority to High.

It would be also good to hear from you about the implementation approach.
In the past we debated two alternatives: passing a special attribute to a
port in order to create a floating IP for it too, or orchestrating the
operation from the nova side.
The first option has the cons of adding a side effect to a REST API call
(which is not advisable), and might be a bit complex when the network where
the port is on is attached to multiple routers.
The latter option has the cons of requiring two neutron API calls.

The input of the whole community on this topic will be very appreciated.

Salvatore


On 14 November 2013 05:47, Steven Weston  wrote:
> Thanks for the responses on this.  I definitely still interested in
> implementing the functionality described in this blueprint, but have been
> reluctant to start on it since I did not get a response.
>  
> Yes, please assign it to me and I will get started on it right away!  I do not
> seem to have the capability to assign it to myself.
>  
> Steven
>  
> From: Jaume Devesa [mailto:devv...@gmail.com]
> Sent: Wednesday, November 13, 2013 10:32 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Neutron] Blueprint -- Floating IP Auto
> Association
> 
>  
> 
> Hi all,
> I see it has been passed two weeks since first mail in this thread and that
> blueprint still without assignee. I also think this is a good option for my
> first blueprint. However, I can not assign blueprints to myself, only bugs.
> Can anybody assign to me?
> Steven: if you still interested in it, please tell us. You asked for it first
> and it will be yours.
> Regards
> 
>  
> 
> On 5 November 2013 07:21, Salvatore Orlando  wrote:
>> 
>> I don't think there has been any development in the past 6 months.
>> 
>> A few people have shown interest in it in the past, but the blueprint has
>> currently no assignee.
>> 
>> So If you want to work on it, feel free to assign to yourself.
>> 
>>  
>> 
>> To quickly sum up the discussion around this blueprint, it could be
>> implemented in two ways:
>> 
>> - providing automation in the neutron API (creating the floating IP together
>> with the port)
>> 
>> - automating the operation on the orchestration side (nova-api in this case).
>> 
>>  
>> 
>> There are pro and cons in both solutions. In my humble opinion, the only
>> thing I would care of is that the existing operation in the Neutron API stay
>> "atomic" as they are.
>> 
>>  
>> 
>> Regards,
>> 
>> Salvatore
>> 
>>  
>> 
>> On 30 October 2013 08:46, Steven Weston  wrote:
>>> 
>>> Does anybody know what the status of this Blueprint is?
>>> https://blueprints.launchpad.net/neutron/+spec/auto-associate-floating-ip
>>>  
>>> I am new to the neutron developer community and I am looking for a first
>>> project ­ this might be a good place to start.  But the last update was in
>>> March of this year, so I don¹t know if the specifications have been locked
>>> down yet. 
>>>  
>>> Anybody?
>>>  
>>> Thanks!
>>> Steven Weston
>>>  
>>> ___
>>> 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] Port mirroring

[Edgar Magana]

Rossella,

Looking forward to getting more details!

Edgar

From:  Rossella Sblendido 
Reply-To:  OpenStack List 
Date:  Thursday, November 14, 2013 11:48 AM
To:  OpenStack List 
Subject:  Re: [openstack-dev] [Neutron] Port mirroring

Hi Edgar,

documentation is a great idea. I will make sure to have it. Shall I add it
to the blueprint or just have to keep that in mind?
Yes it will be configurable, if you look at the API I think it's quite
flexible but if you or others have ideas on how to make it better, please
add some comment.

Regarding the overhead, I could give only a vague answer now. Let me think
more through it and I will come back to you. I think the best way is to
provide more details about the implementation in the document so that
everybody can have a better idea of the changes required and can give
his/her feedback too. I will do that.

thanks a lot!

Rossella


On Thu, Nov 14, 2013 at 7:15 PM, Edgar Magana  wrote:
> Hello Rossella,
> 
> Kyle has a very good point and I wanted to add the documentation request.
> Be sure you have a wiki/document (not a technical one) that we can easily
> transfer into the OpenStack Docs.
> 
> This is a great feature, any idea of the overhead that it will cause?
> I assume that this is going to be totally configurable, right?  :-)
> 
> Edgar
> 
> On 11/14/13 8:34 AM, "Kyle Mestery (kmestery)"  wrote:
> 
>> >On Nov 14, 2013, at 8:46 AM, Rossella Sblendido 
>> >wrote:
>>> >>
>>> >> Hello devs,
>>> >>
>>> >> I'd like to start working at this blueprint:
>>> >>
>>> >> https://blueprints.launchpad.net/neutron/+spec/port-mirroring
>>> >>
>>> >> I didn't receive much feedback so please have a look at it.
>>> >>
>>> >> It was not approved yet. What's the usual workflow? Shall I wait for
>>> >>approval before I start implementing it? Sorry for the trivial question
>>> >>but I'm new here.
>>> >>
>> >Welcome Rossella!
>> >
>> >One issue I have with the design document linked in the blueprint is the
>> >testing section has nothing in it all. Given we're trying hard to focus
>> >on quality and testing, I'd like you to add some specific testing
>> >information to the document before we approve it. It would be ideal to
>> >have Tempest tests which test out the new API functionality as well.
>> >That's my main issue with this BP as seen now, but I'd like others to
>> >comment on this as well.
>> >
>> >Thanks!
>> >Kyle
>> >
>>> >> thanks,
>>> >>
>>> >> Rossella
>>> >>
>>> >> ___
>>> >> 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

[openstack-dev] [Neutron] Race condition between DB layer and plugin back-end implementation

[Edgar Magana]

Developers,

This topic has been discussed before but I do not remember if we have a good
solution or not.
Basically, if concurrent API calls are sent to Neutron, all of them are sent
to the plug-in level where two actions have to be made:

1. DB transaction ­ No just for data persistence but also to collect the
information needed for the next action
2. Plug-in back-end implementation ­ In our case is a call to the python
library than consequentially calls PLUMgrid REST GW (soon SAL)

For instance:

def create_port(self, context, port):
with context.session.begin(subtransactions=True):
# Plugin DB - Port Create and Return port
port_db = super(NeutronPluginPLUMgridV2,
self).create_port(context,
   port)
device_id = port_db["device_id"]
if port_db["device_owner"] == "network:router_gateway":
router_db = self._get_router(context, device_id)
else:
router_db = None
try:
LOG.debug(_("PLUMgrid Library: create_port() called"))
# Back-end implementation
self._plumlib.create_port(port_db, router_db)
except Exception:
Š

The way we have implemented at the plugin-level in Havana (even in Grizzly)
is that both action are wrapped in the same "transaction" which
automatically rolls back any operation done to its original state protecting
mostly the DB of having any inconsistency state or left over data if the
back-end part fails.=.
The problem that we are experiencing is when concurrent calls to the same
API are sent, the number of operation at the plug-in back-end are long
enough to make the next concurrent API call to get stuck at the DB
transaction level, which creates a hung state for the Neutron Server to the
point that all concurrent API calls will fail.

This can be fixed if we include some "locking" system such as calling:

from neutron.common import utile
Š

@utils.synchronized('any-name', external=True)
def create_port(self, context, port):
Š

Obviously, this will create a serialization of all concurrent calls which
will ends up in having a really bad performance. Does anyone has a better
solution?

Thanks,

Edgar


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