from:"Armando M."

On 10 November 2016 at 17:36, Armando M. <arma...@gmail.com> wrote:

> Hi Neutrinos,
>
> Some of you may be aware of our CI jobs have been transitioning to Xenial.
> There are a few jobs still left and taking into account mail [1] we need to
> accelerate the process a bit, especially for those jobs that affect our
> gate queue or are voting.
>
> Ajo put together [2], I also added a provisional 'xenial' launchpad bug
> tag [3] to track fixes required to get us in tip-top shape.
>
> Please help out as you can.
>
> Cheers,
> Armando
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-
> November/106906.html
> [2] https://etherpad.openstack.org/p/moving-neutron-jobs-to-xenial
> [3] https://bugs.launchpad.net/neutron/+bugs?field.tag=xenial
>

During the past few weeks lots of progress has been made, we're nearly
completed the transition to xenial as far as the neutron queues go (with
functional and fullstack trailing slightly behind). I have a pending patch
to switch neutron-lib's jobs to xenial [1].

The other untouched surface is python-neutronclient, which I'll be tackling
next. I would invite subprojects maintainers to take a look at their infra
settings to ensure that the switch to xenial won't bite them when it comes.
There's plenty of examples in [2] to learn how to switch.

Cheers,
Armando

[1] https://review.openstack.org/#/c/397401/
[2] https://etherpad.openstack.org/p/moving-neutron-jobs-to-xenial
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] neutron-lib impact

On 23 November 2016 at 16:42, Joshua Harlow <harlo...@fastmail.com> wrote:

> A suggestion would also to setup something like the following:
>
> https://wiki.openstack.org/wiki/Oslo#Periodic
>
> Get the users of neutron lib being tested against the latest neutron lib
> (at least nightly) and seeing if they will be borked by a new neutron lib
> merge...
>
> http://status.openstack.org/openstack-health/#/?groupKey=bui
> ld_name=hour=-with-oslo
>
> Overall be careful with the APIs u expose and plan out how u will shift
> users from the old API to the new API (without destroying the world during
> that transition).
>
> My 3 cents :-P
>

I take the 3 cents, but we already do that :)

http://status.openstack.org/openstack-health/#/?groupKey=build_name=hour=-with-neutron-lib-master


> -Josh
>
>
> Boden Russell wrote:
>
>> I would encourage anyone working on neutron-lib related changes to have
>> a peek at the recently renovated contributing doc [1] if you haven't
>> already.
>>
>> In particular the 'Phase 4: Consume' section [2] provides some tips on
>> how we see this workflow playing out.
>>
>> Thanks
>>
>> [1]
>> https://github.com/openstack/neutron-lib/blob/master/doc/sou
>> rce/contributing.rst
>> [2]
>> https://github.com/openstack/neutron-lib/blob/master/doc/sou
>> rce/contributing.rst#phase-4-consume
>>
>>
>> On 11/23/16 12:39 PM, Armando M. wrote:
>>
>>> Hi neutrinos,
>>>
>>> In the last few hours a couple of changes landed [1,2] that caused a bit
>>> of a jam in the neutron subproject gates, as they overlapped with
>>> another change [3] having impact on the subprojects.
>>>
>>> This is why it is important to communicate during team meetings and/or
>>> ML that patches with potential impact are in flight in our review
>>> pipeline, so that we do our best to coordinate the merge process without
>>> shooting ourselves in the foot.
>>>
>>> To bring this back to sanity, I issued a temporary revert [4], so that
>>> [5] can land undisturbed. After that, a double revert will be applied,
>>> once subprojects have had the opportunity to deal with the aftermath of
>>> the other breaking change [1,2] (e.g. [6,7]).
>>>
>>>  From now on, I'd strongly encourage people proposing/reviewing patches
>>> with potential impact (any impact) to err on the side of caution, and
>>> take the advised steps to ensure such situations don't happen in the
>>> future.
>>>
>>> Thanks,
>>> Armando
>>>
>>> [1] https://review.openstack.org/#/c/397704/
>>> [2] https://review.openstack.org/#/c/397037/
>>> [3] https://review.openstack.org/#/c/386845/
>>> [4] https://review.openstack.org/#/c/401377/
>>> [5] https://review.openstack.org/#/q/topic:plugin-directory+status:open
>>> [6] https://review.openstack.org/#/c/401263/
>>> [7] https://review.openstack.org/#/c/401355/
>>>
>>>
>>> 
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][tacker] Trunk ports in Tacker?

On 23 November 2016 at 01:47, zhi  wrote:

> Hi, all
>
> Recently I did some research about trunk port in neutron by following
> document[1]. By creating a trunk port, I can use this port ( aka " parent
> port " ) to create a VM. So I can add or remove subports on this "parent
> port" which used by the VM I created.
>
> I want to know how Tacker can use " trunk port ". In Tacker, I can create
> a VNFD template which contains network infos like
> "
> VL1:
>   type: tosca.nodes.nfv.VL
>   properties:
> network_name: net_mgmt
> vendor: Tacker
> "
> So I can use this template to create VNFs with specific network info(
> naming net_mgmt ). Finally VNFs own its normal ports in neutron. So my
> question is:
>
> Can I use trunk ports in Tacker?
>
> I read some document about VLAN transparent in Neutron. In my thought, I
> can create a vlan transparent network in Neutron and using this network in
> VNFD template. At last, every VNF's
> port is " trunk port " and I can add or remove subports on it. Am I right?
>
> In Newton, I enabled the vlan-transparent in neutron server and try to
> create a vlan transparent network. But I failed. I got the error message
> is: " Backend does not support VLAN Transparency ".
>
> VLAN transparent doesn't support in Newton now?
>

VLAN transparency is backend dependent. OVS, if that's the one you were
using, does not support it.


>
>
> Thanks
> Zhi Chang
>
> [1]: https://wiki.openstack.org/wiki/Neutron/TrunkPort
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] neutron-lib impact

On 24 November 2016 at 10:16, Neil Jerram <n...@tigera.io> wrote:

> To be clear, when I said 'catching such issues', what I meant was:
> 'letting me know promptly that I now need to update networking-calico'.
>

We're asking folks to take a number of steps to properly communicate
potential issues such as those happened during the past 24 hours:

   - Mark a change's commit message with 'NeutronLibImpact' so that it can
   be caught with gerrit filters [1,2]. This helps folks to check for imminent
   potential impact or past impact that one has to catch up to. We have a
   weekly team meeting discussion about such issues to raise visibility.
   - further raise awareness in ML threads, in case offline discussion is
   required.

Monitoring the usual channels (team meeting logs and ML threads) should
give ample notice to folks and instructions on how to react.

Cheers,
Armando

[1]
https://review.openstack.org/#/q/status:open+message:%22NeutronLibImpact%22
[2]
https://review.openstack.org/#/q/status:merged+message:%22NeutronLibImpact%22


> I absolutely did not mean any kind of delaying or blocking a neutron or
> neutron-lib change.
>
> Thanks,
>  Neil
>
>
>
> On Thu, Nov 24, 2016 at 5:43 PM Kevin Benton <ke...@benton.pub> wrote:
>
>> Yeah, in this case I don't think it would have helped because it was
>> removing several things from neutron simultaneously. The only thing that
>> would have stopped that would have been jobs from all sub projects voting
>> on each neutron change.
>>
>> On Nov 24, 2016 10:02, "Armando M." <arma...@gmail.com> wrote:
>>
>>
>>
>> On 24 November 2016 at 05:27, Neil Jerram <n...@tigera.io> wrote:
>>
>> But I think a periodic check for a Neutron/neutron-lib-using project
>> (such as networking-calico) would still be a decent way of catching such
>> issues, wouldn't it?
>>
>>
>> It depends, and it would. There are many factors at play, as Kevin
>> pointed out.
>>
>>
>>
>>
>> On Thu, Nov 24, 2016 at 12:58 AM Kevin Benton <ke...@benton.pub> wrote:
>>
>> The issue we had is different than breaking changes in neutron-lib. The
>> issue we are running into now is bumps in the road when we are removing
>> deprecated things from Neutron that other projects are still using even
>> though they should be using the neutron-lib version instead.
>>
>> On Wed, Nov 23, 2016 at 5:42 PM, Joshua Harlow <harlo...@fastmail.com>
>> wrote:
>>
>> A suggestion would also to setup something like the following:
>>
>> https://wiki.openstack.org/wiki/Oslo#Periodic
>>
>> Get the users of neutron lib being tested against the latest neutron lib
>> (at least nightly) and seeing if they will be borked by a new neutron lib
>> merge...
>>
>> http://status.openstack.org/openstack-health/#/?groupKey=
>> build_name=hour=-with-oslo
>>
>> Overall be careful with the APIs u expose and plan out how u will shift
>> users from the old API to the new API (without destroying the world during
>> that transition).
>>
>> My 3 cents :-P
>>
>> -Josh
>>
>>
>> Boden Russell wrote:
>>
>> I would encourage anyone working on neutron-lib related changes to have
>> a peek at the recently renovated contributing doc [1] if you haven't
>> already.
>>
>> In particular the 'Phase 4: Consume' section [2] provides some tips on
>> how we see this workflow playing out.
>>
>> Thanks
>>
>> [1]
>> https://github.com/openstack/neutron-lib/blob/master/doc/
>> source/contributing.rst
>> [2]
>> https://github.com/openstack/neutron-lib/blob/master/doc/
>> source/contributing.rst#phase-4-consume
>>
>>
>> On 11/23/16 12:39 PM, Armando M. wrote:
>>
>> Hi neutrinos,
>>
>> In the last few hours a couple of changes landed [1,2] that caused a bit
>> of a jam in the neutron subproject gates, as they overlapped with
>> another change [3] having impact on the subprojects.
>>
>> This is why it is important to communicate during team meetings and/or
>> ML that patches with potential impact are in flight in our review
>> pipeline, so that we do our best to coordinate the merge process without
>> shooting ourselves in the foot.
>>
>> To bring this back to sanity, I issued a temporary revert [4], so that
>> [5] can land undisturbed. After that, a double revert will be applied,
>> once subprojects have had the opportunity to deal with the aftermath of
>> the other breaking change [1,2] (e.g. [6,7]).
>>
&

Re: [openstack-dev] [neutron] stable/newton 'broken'

On 24 November 2016 at 11:12, Gary Kotton <gkot...@vmware.com> wrote:

> The breakage is due to the fact that the projects do not have
> stable/newton branches cut.
>
This is something that I would have expected the neutron team to take care
> of as long as it was under the stadium/tent or whatever we want to call it.
>

Before [1] and [2] you were pulling from master all the time. You are in
charge of your own project, so you are solely at fault of the issue you're
complaining about.

[1] https://review.openstack.org/#/c/400462/
[2] https://review.openstack.org/#/c/402070/


> The fact that the l2gw was removed may have been an indication that it
> should not have been there. But we have a clear responsibility to the
> community about this. Was there are mail indicating that it is excluded
> from the stadium/tent. I do not recall. I just woke up one morning
> discovering that you did that. There was not much discussion there.
>

LOL, you genuinely made me laugh. If you don't stay plugged, whose fault is
that again? The discussion for the governance update did not happen
overnight.


>
It is really unclear how the patches that you added below would have solved
> the problem.
>
> We have made sure that the vmware-nsx code is back up and running. I just
> hope that others are unaffected by this.
>

My patch specifically would have not solved the problem you claim it's
caused by the recent neutron master changes. I am just highlighting that
prior to that you were always pulling from master. With my change you could
simply set BRANCH=stable/newton in [3] in the appropriate branch and you'd
be good to go.

[3]
https://review.openstack.org/#/c/400462/1/tools/tox_install_project.sh@22

What I would like to see happen:
>
> 1.   L2gw gets a stable branch. At the moment the l2gw release team
> is non existent so community please advise how we can add cores
>
You can get hold of people [1] and ask them to make you join the team.

[1] https://review.openstack.org/#/admin/groups/532,members

> 2.   Tap-as-a-service is added to the stadium and tent.
>
 How is this relevant to this discussion?


>
> A luta continua
>
>
>
> *From: *"Armando M." <arma...@gmail.com>
> *Reply-To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Date: *Thursday, November 24, 2016 at 7:03 PM
> *To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [neutron] stable/newton 'broken'
>
>
>
>
>
>
>
> On 24 November 2016 at 02:38, Thierry Carrez <thie...@openstack.org>
> wrote:
>
> Gary Kotton wrote:
> > Please see - http://logs.openstack.org/82/401882/1/check/gate-vmware-
> nsx-python27-db-ubuntu-xenial/1ac0686/console.html#_2016-11-
> 24_06_58_38_520273
> > Here we are pulling trunk as there is no stable version to use
>
> Is neutron stable/newton really broken (like your subject seems to
> indicate) ? Or only vmware-nsx stable/newton ? Since networking-l2gw and
> tap-as-a-service are unofficial projects we can't guarantee that they
> will create branches that match the official stable ones, so we should
> try to avoid depending on them if possible...
>
>
>
> This happens because the referenced projects have no newton branch and the
> consuming project's stable newton was pulling from the master branch (and
> [1] is the hack referenced below). The right fix would be to backport [2],
> create the stable branches of the projects to which vmware-nsx depends on
> and set the branch appropriately. This is what the neutron team does for
> the projects we look after.
>
>
>
> This breakage was waiting to happen, and it just did.
>
>
>
> [1] https://github.com/openstack/vmware-nsx/commit/
> 9a455781e4db9fc360c3264b72c381c91dfa6a15
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_vmware-2Dnsx_commit_9a455781e4db9fc360c3264b72c381c91dfa6a15=DgMFaQ=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=9RMdQBJlmqlbq0DHIHP9NTT4ot9qb0nfNG5qMMfoE2o=v8Iagz-K729O8YOVJ-6w_1lXYa6UNXJt65nAnaHPBns=>
>
> [2] https://github.com/openstack/vmware-nsx/commit/
> a951f5f9299ffdce268c54dc427a71706b8e41da
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_vmware-2Dnsx_commit_a951f5f9299ffdce268c54dc427a71706b8e41da=DgMFaQ=uilaK90D4TOVoH58JNXRgQ=PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw=9RMdQBJlmqlbq0DHIHP9NTT4ot9qb0nfNG5qMMfoE2o=IjsdHWFgL__ygsTjKpo2YJsfuaX6AIuy4Jn82vkfZQg=>
>
>
>
>
> --
> Thierry Carrez (ttx)
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://l

Re: [openstack-dev] [neutron] neutron-lib impact

On 24 November 2016 at 05:27, Neil Jerram <n...@tigera.io> wrote:

> But I think a periodic check for a Neutron/neutron-lib-using project (such
> as networking-calico) would still be a decent way of catching such issues,
> wouldn't it?
>

It depends, and it would. There are many factors at play, as Kevin pointed
out.


>
>
> On Thu, Nov 24, 2016 at 12:58 AM Kevin Benton <ke...@benton.pub> wrote:
>
>> The issue we had is different than breaking changes in neutron-lib. The
>> issue we are running into now is bumps in the road when we are removing
>> deprecated things from Neutron that other projects are still using even
>> though they should be using the neutron-lib version instead.
>>
>> On Wed, Nov 23, 2016 at 5:42 PM, Joshua Harlow <harlo...@fastmail.com>
>> wrote:
>>
>> A suggestion would also to setup something like the following:
>>
>> https://wiki.openstack.org/wiki/Oslo#Periodic
>>
>> Get the users of neutron lib being tested against the latest neutron lib
>> (at least nightly) and seeing if they will be borked by a new neutron lib
>> merge...
>>
>> http://status.openstack.org/openstack-health/#/?groupKey=
>> build_name=hour=-with-oslo
>>
>> Overall be careful with the APIs u expose and plan out how u will shift
>> users from the old API to the new API (without destroying the world during
>> that transition).
>>
>> My 3 cents :-P
>>
>> -Josh
>>
>>
>> Boden Russell wrote:
>>
>> I would encourage anyone working on neutron-lib related changes to have
>> a peek at the recently renovated contributing doc [1] if you haven't
>> already.
>>
>> In particular the 'Phase 4: Consume' section [2] provides some tips on
>> how we see this workflow playing out.
>>
>> Thanks
>>
>> [1]
>> https://github.com/openstack/neutron-lib/blob/master/doc/
>> source/contributing.rst
>> [2]
>> https://github.com/openstack/neutron-lib/blob/master/doc/
>> source/contributing.rst#phase-4-consume
>>
>>
>> On 11/23/16 12:39 PM, Armando M. wrote:
>>
>> Hi neutrinos,
>>
>> In the last few hours a couple of changes landed [1,2] that caused a bit
>> of a jam in the neutron subproject gates, as they overlapped with
>> another change [3] having impact on the subprojects.
>>
>> This is why it is important to communicate during team meetings and/or
>> ML that patches with potential impact are in flight in our review
>> pipeline, so that we do our best to coordinate the merge process without
>> shooting ourselves in the foot.
>>
>> To bring this back to sanity, I issued a temporary revert [4], so that
>> [5] can land undisturbed. After that, a double revert will be applied,
>> once subprojects have had the opportunity to deal with the aftermath of
>> the other breaking change [1,2] (e.g. [6,7]).
>>
>>  From now on, I'd strongly encourage people proposing/reviewing patches
>> with potential impact (any impact) to err on the side of caution, and
>> take the advised steps to ensure such situations don't happen in the
>> future.
>>
>> Thanks,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/397704/
>> [2] https://review.openstack.org/#/c/397037/
>> [3] https://review.openstack.org/#/c/386845/
>> [4] https://review.openstack.org/#/c/401377/
>> [5] https://review.openstack.org/#/q/topic:plugin-directory+status:open
>> [6] https://review.openstack.org/#/c/401263/
>> [7] https://review.openstack.org/#/c/401355/
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
>> unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> 
&

Re: [openstack-dev] [neutron] stable/newton 'broken'

On 24 November 2016 at 02:38, Thierry Carrez  wrote:

> Gary Kotton wrote:
> > Please see - http://logs.openstack.org/82/401882/1/check/gate-vmware-
> nsx-python27-db-ubuntu-xenial/1ac0686/console.html#_2016-11-
> 24_06_58_38_520273
> > Here we are pulling trunk as there is no stable version to use
>
> Is neutron stable/newton really broken (like your subject seems to
> indicate) ? Or only vmware-nsx stable/newton ? Since networking-l2gw and
> tap-as-a-service are unofficial projects we can't guarantee that they
> will create branches that match the official stable ones, so we should
> try to avoid depending on them if possible...
>

This happens because the referenced projects have no newton branch and the
consuming project's stable newton was pulling from the master branch (and
[1] is the hack referenced below). The right fix would be to backport [2],
create the stable branches of the projects to which vmware-nsx depends on
and set the branch appropriately. This is what the neutron team does for
the projects we look after.

This breakage was waiting to happen, and it just did.

[1]
https://github.com/openstack/vmware-nsx/commit/9a455781e4db9fc360c3264b72c381c91dfa6a15
[2]
https://github.com/openstack/vmware-nsx/commit/a951f5f9299ffdce268c54dc427a71706b8e41da


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

[openstack-dev] [neutron] neutron-lib impact

Hi neutrinos,

In the last few hours a couple of changes landed [1,2] that caused a bit of
a jam in the neutron subproject gates, as they overlapped with another
change [3] having impact on the subprojects.

This is why it is important to communicate during team meetings and/or ML
that patches with potential impact are in flight in our review pipeline, so
that we do our best to coordinate the merge process without shooting
ourselves in the foot.

To bring this back to sanity, I issued a temporary revert [4], so that [5]
can land undisturbed. After that, a double revert will be applied, once
subprojects have had the opportunity to deal with the aftermath of the
other breaking change [1,2] (e.g. [6,7]).

>From now on, I'd strongly encourage people proposing/reviewing patches with
potential impact (any impact) to err on the side of caution, and take the
advised steps to ensure such situations don't happen in the future.

Thanks,
Armando

[1] https://review.openstack.org/#/c/397704/
[2] https://review.openstack.org/#/c/397037/
[3] https://review.openstack.org/#/c/386845/
[4] https://review.openstack.org/#/c/401377/
[5] https://review.openstack.org/#/q/topic:plugin-directory+status:open
[6] https://review.openstack.org/#/c/401263/
[7] https://review.openstack.org/#/c/401355/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] neutron-lib impact

On 24 November 2016 at 09:41, Kevin Benton <ke...@benton.pub> wrote:

> Yeah, in this case I don't think it would have helped because it was
> removing several things from neutron simultaneously. The only thing that
> would have stopped that would have been jobs from all sub projects voting
> on each neutron change.
>

Right, and that's never gonna happen otherwise we might as well put all the
code back into one tree.


>
> On Nov 24, 2016 10:02, "Armando M." <arma...@gmail.com> wrote:
>
>>
>>
>> On 24 November 2016 at 05:27, Neil Jerram <n...@tigera.io> wrote:
>>
>>> But I think a periodic check for a Neutron/neutron-lib-using project
>>> (such as networking-calico) would still be a decent way of catching such
>>> issues, wouldn't it?
>>>
>>
>> It depends, and it would. There are many factors at play, as Kevin
>> pointed out.
>>
>>
>>>
>>>
>>> On Thu, Nov 24, 2016 at 12:58 AM Kevin Benton <ke...@benton.pub> wrote:
>>>
>>>> The issue we had is different than breaking changes in neutron-lib. The
>>>> issue we are running into now is bumps in the road when we are removing
>>>> deprecated things from Neutron that other projects are still using even
>>>> though they should be using the neutron-lib version instead.
>>>>
>>>> On Wed, Nov 23, 2016 at 5:42 PM, Joshua Harlow <harlo...@fastmail.com>
>>>> wrote:
>>>>
>>>> A suggestion would also to setup something like the following:
>>>>
>>>> https://wiki.openstack.org/wiki/Oslo#Periodic
>>>>
>>>> Get the users of neutron lib being tested against the latest neutron
>>>> lib (at least nightly) and seeing if they will be borked by a new neutron
>>>> lib merge...
>>>>
>>>> http://status.openstack.org/openstack-health/#/?groupKey=bui
>>>> ld_name=hour=-with-oslo
>>>>
>>>> Overall be careful with the APIs u expose and plan out how u will shift
>>>> users from the old API to the new API (without destroying the world during
>>>> that transition).
>>>>
>>>> My 3 cents :-P
>>>>
>>>> -Josh
>>>>
>>>>
>>>> Boden Russell wrote:
>>>>
>>>> I would encourage anyone working on neutron-lib related changes to have
>>>> a peek at the recently renovated contributing doc [1] if you haven't
>>>> already.
>>>>
>>>> In particular the 'Phase 4: Consume' section [2] provides some tips on
>>>> how we see this workflow playing out.
>>>>
>>>> Thanks
>>>>
>>>> [1]
>>>> https://github.com/openstack/neutron-lib/blob/master/doc/sou
>>>> rce/contributing.rst
>>>> [2]
>>>> https://github.com/openstack/neutron-lib/blob/master/doc/sou
>>>> rce/contributing.rst#phase-4-consume
>>>>
>>>>
>>>> On 11/23/16 12:39 PM, Armando M. wrote:
>>>>
>>>> Hi neutrinos,
>>>>
>>>> In the last few hours a couple of changes landed [1,2] that caused a bit
>>>> of a jam in the neutron subproject gates, as they overlapped with
>>>> another change [3] having impact on the subprojects.
>>>>
>>>> This is why it is important to communicate during team meetings and/or
>>>> ML that patches with potential impact are in flight in our review
>>>> pipeline, so that we do our best to coordinate the merge process without
>>>> shooting ourselves in the foot.
>>>>
>>>> To bring this back to sanity, I issued a temporary revert [4], so that
>>>> [5] can land undisturbed. After that, a double revert will be applied,
>>>> once subprojects have had the opportunity to deal with the aftermath of
>>>> the other breaking change [1,2] (e.g. [6,7]).
>>>>
>>>>  From now on, I'd strongly encourage people proposing/reviewing patches
>>>> with potential impact (any impact) to err on the side of caution, and
>>>> take the advised steps to ensure such situations don't happen in the
>>>> future.
>>>>
>>>> Thanks,
>>>> Armando
>>>>
>>>> [1] https://review.openstack.org/#/c/397704/
>>>> [2] https://review.openstack.org/#/c/397037/
>>>> [3] https://review.openstack.org/#/c/386845/
>>>> [4] https://review.openstack.org/#/c/401377/
>>>> [5

[openstack-dev] [neutron] oslo liasion

2016-11-22 Thread Armando M.

Hi neutrinos,

I would like to announce Victor Morales, aka electrocucaracha as our oslo
liasion [1].

If you would like to be help in any of the liasion capacities available,
please review [1] and reach out to me.

Cheers,
Armando

[1] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Oslo
__
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] [OpenStack-Infra] [infra][neutron] Intel NFV CI voting permission in Neutron

2016-11-22 Thread Armando M.

On 22 November 2016 at 06:09, Znoinski, Waldemar <
waldemar.znoin...@intel.com> wrote:

>
>
>  >-Original Message-
>  >From: Jeremy Stanley [mailto:fu...@yuggoth.org]
>  >Sent: Monday, November 14, 2016 3:40 PM
>  >To: openstack-in...@lists.openstack.org; openstack-dev@lists.openstack.
> org
>  >Subject: Re: [openstack-dev] [OpenStack-Infra] [infra][neutron] Intel
> NFV CI
>  >voting permission in Neutron
>  >
>  >On 2016-11-14 10:44:42 + (+), Znoinski, Waldemar wrote:
>  >> I would like to acquire voting (+/-1 Verified) permission for our
>  >> Intel NFV CI.
>  >[...]
>  >
>  >The requested permission is configured by addition to
>  >https://review.openstack.org/#/admin/groups/neutron-ci which is
>  >controlled by the members of the
>  >https://review.openstack.org/#/admin/groups/neutron-release group.
>  >The Infra team tries not to be involved in these decisions and instead
> prefers
>  >to leave them up to the project team(s) involved.
> [WZ] thanks for explanation Jeremy, that was my intention - the ask is to
> Neutron(-release) guys, with Infra as FYI
>

done


>
>  >
>  >> This e-mail and any attachments may contain confidential material for
>  >> the sole use of the intended recipient(s). Any review or distribution
>  >> by others is strictly prohibited.
>  >[...]
>  >
>  >This seems wholly inappropriate for a public mailing list. I strongly
>  >recommend not sending messages to our mailing lists in which you strictly
>  >prohibit review or distribution by others, as it is guaranteed to happen
> and
>  >we cannot prevent that (nor would we want to).
> [WZ] requested removal of that footer, thanks
>
>  >--
>  >Jeremy Stanley
>  >
>  >__
>  >
>  >OpenStack Development Mailing List (not for usage questions)
>  >Unsubscribe: OpenStack-dev-
>  >requ...@lists.openstack.org?subject:unsubscribe
>  >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] Drivers meeting on Nov 24th cancelled

2016-11-22 Thread Armando M.

Happy Thanksgiving!

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

Re: [openstack-dev] [neutron] neutron-lib impact

2016-11-16 Thread Armando M.

On 16 November 2016 at 10:11, Gary Kotton <gkot...@vmware.com> wrote:

> Hi,
>
> I agree with you on a number of points that you have made below. But you
> are mixing things up. One you state that we should be moving faster and it
> is patches like this that actually hinder us. We are not moving as the core
> team is dwindling down and people are leaving the project. We need to add
> new members to the core team and remove people who are not taking part. We
> are a community and not an autocracy. It is great that you are driving this
> but getting people on board would be helpful. I feel that the cores from
> the subprojects should chime in and review this – at the end of the day it
> affects them too. I have even asked other to base reviews on this code. I
> just think that you need to be aware that there are other people working on
> the project and that they too should be engaged.
>

What's this thread for then if not engaging/inviting people to review? Your
point seems moot.


> Thanks
>
> Gary
>
>
>
> *From: *"Armando M." <arma...@gmail.com>
> *Reply-To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Date: *Wednesday, November 16, 2016 at 6:16 PM
> *To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Subject: *Re: [openstack-dev] [neutron] neutron-lib impact
>
>
>
>
>
>
>
> On 16 November 2016 at 00:55, Gary Kotton <gkot...@vmware.com> wrote:
>
> Hi,
>
> The directory integration will break all of the plugins and neutron
> projects. I do not think that this is something that we should do. It
> breaks the neutron API contract.
>
>
>
> The plugin directory is an implementation internal. Let's be very clear,
> in case you have not realized this already:
>
>
>
> *Neutron is not supposed to be imported directly by projects and we all
> knew it when we started off with the project decomposition.*
>
>
>
> neutron-lib is our response to driving adoption of stable interfaces
> across the neutron ecosystem of repositories. Forcing ourselves to
> introduce artificial deprecation cycles for internal details is not only
> slowing us down but it has proven ineffective so far. We should accelerate
> with the decoupling of projects so that we can all consider these types of
> breakages a thing of the past.
>
>
>
> I think that we should only unblock the patch
> https://review.openstack.org/#/c/386845. I think that due to the fact
> that this patch (very big) will break all plugins, we should only approve
> it once every sub project owner has chimed in.
>
> This will mean that she/he will need to understand that there may be some
> tweaks involved in getting unit tests to pass. CI may automagically work.
>
>
>
> This is impractical and defeats the point of allowing us to go faster. I
> have taken the proactive step of announcing this change publicly and with
> ample notice. I have addressed many subprojects myself and have already
> seen +2/+1 flocking in. I have moved forward without creating busy work for
> myself and the review team.
>
>
>
> I feel that as a core reviewer my responsibility is to make sure that we
> do not break things.
>
>
>
> We are not in a sane situation. It's been two years since we split the
> repo up and very little progress has been made to decouple the projects via
> stable interfaces. I am trying to identify ways to allow us to accelerate
> and you're stifling that effort with your abuse of core rights. I was not
> going to let the patch merge without a final announcement at the next team
> meeting.
>
>
>
> In addition to this we have a responsibility to ensure that things
> continue to work. Hopefully we can find a way to do this in a more friendly
> manner.
>
>
>
> I have taken such a responsibility with [1]. It takes us longer to discuss
> (on something that was already widely agreed on) than either fixing the
> breakage or provide a 'fake' backward compat layer which we'll lead to the
> breakage as soon we take it away [2].
>
>
>
> That said, I am happy to concede if other members of the core team agrees
> with you. As PTL, I have identified a gap that needs to be filled and I am
> proactively stepping up to address the gap. I can't obviously be right all
> the time, but I was under the impression I had the majority of the core
> team on my side.
>
>
>
> At this point, I'd invite other neutron core members to review and vote on
> the patch.
>
>
>
> A.
>
>
>
> [1] https://review.openstack.org/#/q/topic:plugin-directory
> [2]  https://bugs.launchpad.net/vmware-nsx/+bug/1640319
>
>
>
> Thanks
>
> Gary
>
>
>
> *From: *"Armando M.&qu

[openstack-dev] [neutron] neutron-lib impact

2016-11-15 Thread Armando M.

Hi neutrinos,

As mentioned during the last team meeting [1], there is a change [2] in the
works aimed at adopting the neutron plugins directory as provided in
neutron-lib 1.0.0 [3].

As shown in [2], the switch to using the directory is relatively
straightforward. I leave the rest of the affected repos as an exercise for
the reader :)

Cheers,
Armando

[1] http://eavesdrop.openstack.org/meetings/networking/2016/networking.
2016-11-14-21.00.txt
[2] https://review.openstack.org/#/q/topic:plugin-directory
[3] http://docs.openstack.org/releasenotes/neutron-lib/unreleased.html#id3
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] neutron-lib impact

2016-11-16 Thread Armando M.

On 16 November 2016 at 00:55, Gary Kotton <gkot...@vmware.com> wrote:

> Hi,
>
> The directory integration will break all of the plugins and neutron
> projects. I do not think that this is something that we should do. It
> breaks the neutron API contract.
>

The plugin directory is an implementation internal. Let's be very clear, in
case you have not realized this already:

*Neutron is not supposed to be imported directly by projects and we all
knew it when we started off with the project decomposition.*

neutron-lib is our response to driving adoption of stable interfaces across
the neutron ecosystem of repositories. Forcing ourselves to introduce
artificial deprecation cycles for internal details is not only slowing us
down but it has proven ineffective so far. We should accelerate with the
decoupling of projects so that we can all consider these types of breakages
a thing of the past.

> I think that we should only unblock the patch
> https://review.openstack.org/#/c/386845. I think that due to the fact
> that this patch (very big) will break all plugins, we should only approve
> it once every sub project owner has chimed in.
>
This will mean that she/he will need to understand that there may be some
> tweaks involved in getting unit tests to pass. CI may automagically work.
>

This is impractical and defeats the point of allowing us to go faster. I
have taken the proactive step of announcing this change publicly and with
ample notice. I have addressed many subprojects myself and have already
seen +2/+1 flocking in. I have moved forward without creating busy work for
myself and the review team.

> I feel that as a core reviewer my responsibility is to make sure that we
> do not break things.
>

We are not in a sane situation. It's been two years since we split the repo
up and very little progress has been made to decouple the projects via
stable interfaces. I am trying to identify ways to allow us to accelerate
and you're stifling that effort with your abuse of core rights. I was not
going to let the patch merge without a final announcement at the next team
meeting.

> In addition to this we have a responsibility to ensure that things
> continue to work. Hopefully we can find a way to do this in a more friendly
> manner.
>

I have taken such a responsibility with [1]. It takes us longer to discuss
(on something that was already widely agreed on) than either fixing the
breakage or provide a 'fake' backward compat layer which we'll lead to the
breakage as soon we take it away [2].

That said, I am happy to concede if other members of the core team agrees
with you. As PTL, I have identified a gap that needs to be filled and I am
proactively stepping up to address the gap. I can't obviously be right all
the time, but I was under the impression I had the majority of the core
team on my side.

At this point, I'd invite other neutron core members to review and vote on
the patch.

A.

[1] https://review.openstack.org/#/q/topic:plugin-directory
[2]  https://bugs.launchpad.net/vmware-nsx/+bug/1640319

> Thanks
>
> Gary
>
>
>
> *From: *"Armando M." <arma...@gmail.com>
> *Reply-To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Date: *Wednesday, November 16, 2016 at 6:51 AM
> *To: *OpenStack List <openstack-dev@lists.openstack.org>
> *Subject: *[openstack-dev] [neutron] neutron-lib impact
>
>
>
> Hi neutrinos,
>
>
>
> As mentioned during the last team meeting [1], there is a change [2] in
> the works aimed at adopting the neutron plugins directory as provided in
> neutron-lib 1.0.0 [3].
>
>
>
> As shown in [2], the switch to using the directory is relatively
> straightforward. I leave the rest of the affected repos as an exercise for
> the reader :)
>
>
>
> Cheers,
>
> Armando
>
>
>
> [1] http://eavesdrop.openstack.org/meetings/networking/2016/
> networking.2016-11-14-21.00.txt
>
> [2] https://review.openstack.org/#/q/topic:plugin-directory
>
> [3] http://docs.openstack.org/releasenotes/neutron-lib/unreleased.html#id3
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] rally failure in the gate

2016-11-17 Thread Armando M.

Hi folks,

Please do not recheck rally failures.

There was a breaking change introduced by aodh [0] that prevented rally to
work on trusty. We are switching to xenial as we speak anyway [1], so the
glitch should be short lived.

Thanks,
Armando

[0] https://review.openstack.org/#/c/372586/
[1] https://review.openstack.org/#/c/398499/
__
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] [devstack][neutron] - dropping direct route to VMs (FIXED_RANGE)

2016-11-15 Thread Armando M.

On 15 November 2016 at 15:04, Kevin Benton  wrote:

> Hi all,
>
>
> Right now, we do something in devstack that does not reflect how
> deployments are normally done. We setup a route on the parent host to the
> private tenant network that routes through the tenant's router[1]. This
> behavior originates from a very long time ago[2] and I'm not sure if it
> even works correctly right now (because the tenant router has port address
> translation enabled).
>
> I would like to stop this behavior in devstack for a couple of reasons:
>
> 1. If this works, it works by accident. Neutron doesn't have any
> guarantees of behavior when you are pointing routes to a private network
> via a router that has SNAT enabled.
> 2. This method of accessing the VMs is not how access is gained to VMs in
> normal deployments. If you want a VM to be reachable, either attach to the
> same network with a port, setup a provider network, or assign the VM a
> floating IP.
>
>
> I would like to drop the installation of this route, but I'd like to hear
> if there is anyone relying on this behavior. Reply to this email or comment
> on the patch.[3]
>

Thanks for looking into this. Let me add that this is in relation to bug
[1].

Cheers,
Armando

[1] https://bugs.launchpad.net/devstack/+bug/1629133


>
> 1. https://github.com/openstack-dev/devstack/blob/
> 29d13df1a284f8f1a5973ccc826a475156820d23/lib/neutron_
> plugins/services/l3#L378
> 2. https://review.openstack.org/#/c/13693/
> 3. https://review.openstack.org/397987
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] [vpnaas] vpnaas no longer part of the neutron governance

2016-11-15 Thread Armando M.

As of today, the project neutron-vpnaas is no longer part of the neutron
governance. This was a decision reached after the project saw a dramatic
drop in active development over a prolonged period of time.

What does this mean in practice?

- From a visibility point of view, release notes and documentation will
no longer appear on openstack.org as of Ocata going forward.
- No more releases will be published by the neutron release team.
- The neutron team will stop proposing fixes for the upstream CI, if not
solely on a voluntary basis (e.g. I still felt like proposing [2]).

How does it affect you, the user or the deployer?

- You can continue to use vpnaas and its CLI via the
python-neutronclient and expect it to work with neutron up until the newton
release/python-neutronclient 6.0.0. After this point, if you want a release
that works for Ocata or newer, you need to proactively request a release
[5], and reach out to a member of the neutron release team [3] for
approval. Assuming that the vpnaas CI is green, you can expect to have a
working vpnaas system upon release of its package in the foreseeable future.
- Outstanding bugs and new bug reports will be rejected on the basis of
lack of engineering resources interested in helping out in the typical
OpenStack review workflow.
- Since we are freezing the development of the neutron CLI in favor of
the openstack unified client (OSC), the lack of a plan to make the VPN
commands available in the OSC CLI means that at some point in the future
the neutron client CLI support for vpnaas may be dropped (though I don't
expect this to happen any time soon).

Can this be reversed?

- If you are interested in reversing this decision, now it is time to
step up. That said, we won't be reversing the decision for Ocata. There is
quite a curve to ramp up to make neutron-vpnaas worthy of being classified
as a neutron stadium project, and that means addressing all the gaps
identified in [6]. If you are interested, please reach out, and I will work
with you to add your account to [4], so that you can drive the
neutron-vpnaas agenda going forward.

Please do not hesitate to reach out to ask questions and/or clarifications.

Cheers,
Armando

[1] https://review.openstack.org/#/c/392010/
[2] https://review.openstack.org/#/c/397924/
[3] https://review.openstack.org/#/admin/groups/150,members
[4] https://review.openstack.org/#/admin/groups/502,members
[5] https://github.com/openstack/releases
[6]
http://specs.openstack.org/openstack/neutron-specs/specs/stadium/ocata/neutron-vpnaas.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Summit design summary - a heads up

2016-10-31 Thread Armando M.

Hi folks,

For those of you who missed the summit, I wanted to give a heads up that I
am working with session chairs to provide here a distilled version of any
conclusion/agreement/proposal reached in Barcelona during the Neutron track.

In the meantime, some networking related conference sessions are available
at [1].

Cheers,
Armando

[1] https://www.openstack.org/videos/search?search=networking
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] summit sessions - feedback

2016-11-03 Thread Armando M.

Hi Neutrinos,

You will be noticing a few emails getting into your inbox with subject
 summit recap or similar.

Watch out for those if you're interested in making sense of the discussions
as captured on etherpads [1].

Many thanks to the session chairs for the effort!

Cheers and happy hacking!
Armando

[1] https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Neutron
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Centralizing some config options will break many stadium projects

2016-10-28 Thread Armando M.

On 27 October 2016 at 22:18, Brandon Logan 
wrote:

> Hello Neutrinos,
> I've come across an issue that I'd like to get input/opinions on.  I've
> been reviewing some of the centralize config options reviews and have
> come across a few that would cause issues with other projects that are
> importing these options, especially stadium projects.  High level view
> of the issue:
>
> [1] would cause at least 22 projects to need to be fixed based on [2]
>
> [3] would cause at least 12 projects to need to be fixed based on [4]
>
> [5] looks to affect many other projects as well (I'm being lazy and
> not  counting them right now)
>
> Initially, the thinking was that moving the config options around would
> cause some breakage with projects outside of neutron, but that would be
> fine because projects shouldn't really be using neutron as a library
> and using it to register config options.  However, with these 3
> patches, I definitely don't feel comfortable breaking the amount of
> projects these would break.  It also makes me think that maybe these
> options should be in neutron-lib since they're consumed so widely.
> Anyway, I've come up with some possible options to deal with this, but
> would like to hear others' opinions on this:
>
> 1) Let the patches merge and break those projects as a signal that
> importing these shouldn't be done.  The affected projects can choose to
> push fixes that continue importing the neutron config options or
> defining their own config options.
> 2) Deprecate the old locations for some timeframe, and then remove
> later.
> 3) Texas Three-Step: change the neutron patches to keep pointers in the
> old locations to the new, and then push patches to the affected repos
> with Depends-On directives.  Once all patches merge, push up one more
> patch to neutron to remove the old location.
> 4) Abandon these reviews and do nothing.
> 5) Move these config options to neutron-lib so that they can be used by
> any project.  This still requires doing one of the above options,
> however.

6) Any others I can't think of?
>

Slight variation, call it option 6:

1) Identify the most impacted (coupled) project affected by these changes.
2) Fix it in order to provide folks with a recipe for how to address the
breakages.
3) Use the patch and make it needed-by the neutron changes.
4) Evangelize patch 2 one more time on the ML.
5) We'll bring this up at the team meeting, for another form or record.
6) Wait another few days for projects to catch up.
7) Merge the patch in neutron.
8) We all move on.


>
>
> [1] https://review.openstack.org/#/c/343045/
> [2] http://codesearch.openstack.org/?q=from%20neutron.agent.common%20im
> port%20config=nope==
>
> [3] https://review.openstack.org/#/c/340228/
> [4] http://codesearch.openstack.org/?q=neutron.plugins.ml2%20import%20c
> onfig=nope==
>
> [5] https://review.openstack.org/#/c/347867/
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Cloud Provider Security Groups

2016-11-01 Thread Armando M.

On 31 October 2016 at 22:28, David G. Bingham  wrote:

> Yo Neutron devs :-)
>
> I was wondering if something like the following subject has come up:
> "Cloud-provider Security Groups”.
>
> *Goal of this email*: Gauge the community’s need and see if this has come
> up in past.
> *Requirement*: Apply a provider-managed global set of network flows to all
> instances.
> *Use Case*: For our private cloud, have need to dynamically allow network
> traffic flows from other internal network sources across all instances.
> *Basic Idea*: Provide an *admin-only* accessible security group ruleset
> that would persist and apply these "cloud-provider" security group rules to
> all instances of a cloud. This *may* be in the form of new "provider" API
> or an extension to existing API only accessible via "admin". When instances
> are created, this global SG ruleset would be applied to each VM/ironic
> instance. This feature likely should be capable of being enabled/disabled
> depending on the provider's need.
>
> *Real example*: Company security team wants to audit consistent security
> software installations (i.e. HIPS) across our entire fleet of servers for
> compliance reporting. Each vm/ironic instance is required to have this
> software installed and up to date. Security audit team actually audits each
> and every server to ensure it is running, patched and up to date. These
> auditing tools source from a narrow set of internal IPs/ports and each
> instance must allow access to these auditing tools.
>
> --- What we do today to hack a "cloud-provider" flow in a private cloud ---
> 1) We've locked down the default rules (only admins can modify which makes
> effectively kills a lot of canned neutron tools).
> 2) We've written an external script that iterates over all projects in our
> private cloud (~10k projects)
> 3) For each project:
> 3a) Fetch default SGs for that project and do a comparison of its default
> rules against *target* default rules
> 3b) Create any new missing rules, delete any removed rules
> 3c) Next project
> This process is cumbersome, takes 20+ hours to run (over ~10k projects)
> and has to be throttled such that it doesn't over-hammer neutron while its
> still serving production traffic.
>
> --- What we'd like to do in future ---
> 1) Call Security Group API that would modify a "cloud-provider" ruleset.
> 2) When updated, agents on HVs detect the "cloud-provider" change and then
> apply the rules across all instances.
> Naturally there are going to be a lot of technical hurdles to make this
> happen while a cloud is currently in-flight.
>
> Other uses for “Provider SGs":
> * We want to enable new shared features (i.e. monitoring aaS) that all our
> internal projects can take advantage of. When the monitoring team
> adds/modifies IPs to scale, we'd apply these cloud-provider rules on behalf
> of all projects in the private cloud without users having concern
> themselves about the monitoring team's changes.
> * We want to allow access to some internal sites to our VPN users on
> specific ports. These VPN ranges are dynamically changed by the VPN team.
> Our teams should not need to go into individual projects to add a new rule
> when VPN team changes ranges.
> * This list could go on and on and naturally makes much more sense in a
> *private cloud* scenario, but there may be cases for public providers.
>
> I’d be happy to create a spec.
>
> Seen this before? Thoughts? Good, Bad or Ugly? :-)
>

I think this has come up before [1]. The use case is legitimate, but there
is a couple of ways in which this can be accomplished. As pointed out by
others, FWaaS is the solution we suggested to address this particular need.

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


>
> Thanks,
> David Bingham (wwriverrat on irc)
> GoDaddy
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Multinode testing with devstack and neutron broken

On 11 October 2016 at 17:05, Clark Boylan <cboy...@sapwetik.org> wrote:

> On Tue, Oct 11, 2016, at 05:01 PM, Armando M. wrote:
> > On 11 October 2016 at 16:54, Clark Boylan <cboy...@sapwetik.org> wrote:
> >
> > > On Tue, Oct 11, 2016, at 04:51 PM, Armando M. wrote:
> > > > On 11 October 2016 at 16:43, Clark Boylan <cboy...@sapwetik.org>
> wrote:
> > > >
> > > > > On Tue, Oct 11, 2016, at 04:32 PM, Armando M. wrote:
> > > > > > On 11 October 2016 at 14:09, Clark Boylan <cboy...@sapwetik.org>
> > > wrote:
> > > > > >
> > > > > > > Hello everyone,
> > > > > > >
> > > > > > > Currently multinode testing + neutron is broken in clouds that
> use
> > > > > > > portions of 10.0.0.0/8 for their networking due to route
> conflicts
> > > > > with
> > > > > > > devstack + neutron deployments. https://bugs.launchpad.net/bug
> > > > > s/1629133
> > > > > > > is tracking the issue for us. I would like to see this get
> resolved
> > > > > > > properly before we do further work on multinode testing as it
> is
> > > > > > > difficult to review and determine what failures are legit vs
> which
> > > > > > > failures are related to this bug and whether or not a specific
> > > > > multinode
> > > > > > > test has decided to workaround the issue.
> > > > > > >
> > > > > > > The change to use subnet pools in devstack is a non backward
> > > compatible
> > > > > > > change for devstack currently and it doesn't appear to have
> been
> > > > > > > documented in devstack at all. Would be great if we can
> finally fix
> > > > > this
> > > > > > > and get testing back to working and however we fix it ensure
> that
> > > > > > > devstack has the appropriate documentation.
> > > > > > >
> > > > > >
> > > > > > What is holding [1] back? Merging that would resolve the issue,
> then
> > > we
> > > > > > can
> > > > > > drill down into why subnetpools interfere with the underlying
> > > networking
> > > > > > setup. I have asked Carl to look into broken build [2]
> > > > > >
> > > > > > [1] https://review.openstack.org/#/c/379543/
> > > > > > [2]
> > > > > > http://logs.openstack.org/78/381278/2/check/gate-tempest-dsv
> > > > > m-neutron-multinode-full-ubuntu-xenial/7f82862/console.html.gz
> > > > >
> > > > > Yours is one of the two -1's on the change :) I think that devstack
> > > core
> > > > > is probably holding back due to the two -1s there. If we are ok
> with
> > > > > iterating on making it better rather than all in one shot maybe
> that
> > > > > change is good for now and we can update the reviews?
> > > > >
> > > >
> > > > Well, that means the ball is in the contributor's court, who is
> supposed
> > > > to
> > > > address reviewers' concerns :)
> > > >
> > > The comments on the change with -1's are opposed to doing what the
> > > change does. I don't know how I can possibly address them.
> > >
> >
> > Then say so on the review and I am happy to rephrase to make sure I get
> > my
> > message across correctly. If you let the review rot how can you expect it
> > to make progress? That's like Openstack 101
>
> It does say so clearly in the commit itself:
>
> "It turns out that many people have already chosen fixed ranges that
> work for their environments. They have done so to avoid conflicts with
> existing networking ranges and routing. The change to use 10.0.0.0/8 and
> apply routes for this network to neutron interfaces prevents anyone from
> using networks within that range for anything else.
>
> For example imagine you have a cloud provider that provides private IPv4
> addresses allocated out of ranges in 10.0.0.0/8 and they do all public
> networking over ipv6. This change to devstack prevents you from using
> those private networks properly after starting neutron with devstack.
> However, in situations like this FIXED_RANGE should already represent a
> safe range to use so just use it."
>
> The comments both refuse to allow FIX

Re: [openstack-dev] Multinode testing with devstack and neutron broken

On 11 October 2016 at 16:43, Clark Boylan <cboy...@sapwetik.org> wrote:

> On Tue, Oct 11, 2016, at 04:32 PM, Armando M. wrote:
> > On 11 October 2016 at 14:09, Clark Boylan <cboy...@sapwetik.org> wrote:
> >
> > > Hello everyone,
> > >
> > > Currently multinode testing + neutron is broken in clouds that use
> > > portions of 10.0.0.0/8 for their networking due to route conflicts
> with
> > > devstack + neutron deployments. https://bugs.launchpad.net/bug
> s/1629133
> > > is tracking the issue for us. I would like to see this get resolved
> > > properly before we do further work on multinode testing as it is
> > > difficult to review and determine what failures are legit vs which
> > > failures are related to this bug and whether or not a specific
> multinode
> > > test has decided to workaround the issue.
> > >
> > > The change to use subnet pools in devstack is a non backward compatible
> > > change for devstack currently and it doesn't appear to have been
> > > documented in devstack at all. Would be great if we can finally fix
> this
> > > and get testing back to working and however we fix it ensure that
> > > devstack has the appropriate documentation.
> > >
> >
> > What is holding [1] back? Merging that would resolve the issue, then we
> > can
> > drill down into why subnetpools interfere with the underlying networking
> > setup. I have asked Carl to look into broken build [2]
> >
> > [1] https://review.openstack.org/#/c/379543/
> > [2]
> > http://logs.openstack.org/78/381278/2/check/gate-tempest-dsv
> m-neutron-multinode-full-ubuntu-xenial/7f82862/console.html.gz
>
> Yours is one of the two -1's on the change :) I think that devstack core
> is probably holding back due to the two -1s there. If we are ok with
> iterating on making it better rather than all in one shot maybe that
> change is good for now and we can update the reviews?
>

Well, that means the ball is in the contributor's court, who is supposed to
address reviewers' concerns :)


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

Re: [openstack-dev] Multinode testing with devstack and neutron broken

On 11 October 2016 at 16:54, Clark Boylan <cboy...@sapwetik.org> wrote:

> On Tue, Oct 11, 2016, at 04:51 PM, Armando M. wrote:
> > On 11 October 2016 at 16:43, Clark Boylan <cboy...@sapwetik.org> wrote:
> >
> > > On Tue, Oct 11, 2016, at 04:32 PM, Armando M. wrote:
> > > > On 11 October 2016 at 14:09, Clark Boylan <cboy...@sapwetik.org>
> wrote:
> > > >
> > > > > Hello everyone,
> > > > >
> > > > > Currently multinode testing + neutron is broken in clouds that use
> > > > > portions of 10.0.0.0/8 for their networking due to route conflicts
> > > with
> > > > > devstack + neutron deployments. https://bugs.launchpad.net/bug
> > > s/1629133
> > > > > is tracking the issue for us. I would like to see this get resolved
> > > > > properly before we do further work on multinode testing as it is
> > > > > difficult to review and determine what failures are legit vs which
> > > > > failures are related to this bug and whether or not a specific
> > > multinode
> > > > > test has decided to workaround the issue.
> > > > >
> > > > > The change to use subnet pools in devstack is a non backward
> compatible
> > > > > change for devstack currently and it doesn't appear to have been
> > > > > documented in devstack at all. Would be great if we can finally fix
> > > this
> > > > > and get testing back to working and however we fix it ensure that
> > > > > devstack has the appropriate documentation.
> > > > >
> > > >
> > > > What is holding [1] back? Merging that would resolve the issue, then
> we
> > > > can
> > > > drill down into why subnetpools interfere with the underlying
> networking
> > > > setup. I have asked Carl to look into broken build [2]
> > > >
> > > > [1] https://review.openstack.org/#/c/379543/
> > > > [2]
> > > > http://logs.openstack.org/78/381278/2/check/gate-tempest-dsv
> > > m-neutron-multinode-full-ubuntu-xenial/7f82862/console.html.gz
> > >
> > > Yours is one of the two -1's on the change :) I think that devstack
> core
> > > is probably holding back due to the two -1s there. If we are ok with
> > > iterating on making it better rather than all in one shot maybe that
> > > change is good for now and we can update the reviews?
> > >
> >
> > Well, that means the ball is in the contributor's court, who is supposed
> > to
> > address reviewers' concerns :)
> >
> The comments on the change with -1's are opposed to doing what the
> change does. I don't know how I can possibly address them.
>

Then say so on the review and I am happy to rephrase to make sure I get my
message across correctly. If you let the review rot how can you expect it
to make progress? That's like Openstack 101


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

[openstack-dev] [Neutron] Design summit schedule

Neutrinos,

The design summit schedule for Neutron is getting live and into shape at
[1][2].

For questions/suggestions please feel free to reach out.

Cheers,
Armando

[1]
https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=Neutron%3A
[2] https://wiki.openstack.org/wiki/Design_Summit/Ocata/Etherpads#Neutron
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Multinode testing with devstack and neutron broken

On 11 October 2016 at 18:20, Sean M. Collins <s...@coreitpro.com> wrote:

> Armando M. wrote:
> > At this point I feel that changing the pool range is even less justified.
> > If I had seen bug [4], I would have been against its fix, because you're
> > absolutely right as the change being not backward compatible.
>
> https://review.openstack.org/#/c/356026 was written by someone on the
> Trove team to
> help them with their CI jobs IIRC.
>
> CC'ing Matthew since he has more context. I went into the Trove channel
> and asked them about reverting 356026. It doesn't seem like an option at
> this point.
>
> http://eavesdrop.openstack.org/irclogs/%23openstack-trove/%
> 23openstack-trove.2016-09-30.log.html#t2016-09-30T17:53:08


A revert with no follow up is clearly not a viable option most of the
times, and we clearly dug ourselves too deep now with [1]. Rather than
making the use of subnet pools conditional as done in [1], IMO we should
have made [2] conditional to preserve the existing provisioning behavior
and let Trove override.

[1] Ic89ceca76afda67da5545111972c3348011f294f
[2] https://review.openstack.org/#/c/356026/


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

Re: [openstack-dev] Multinode testing with devstack and neutron broken

On 11 October 2016 at 14:09, Clark Boylan  wrote:

> Hello everyone,
>
> Currently multinode testing + neutron is broken in clouds that use
> portions of 10.0.0.0/8 for their networking due to route conflicts with
> devstack + neutron deployments. https://bugs.launchpad.net/bugs/1629133
> is tracking the issue for us. I would like to see this get resolved
> properly before we do further work on multinode testing as it is
> difficult to review and determine what failures are legit vs which
> failures are related to this bug and whether or not a specific multinode
> test has decided to workaround the issue.
>
> The change to use subnet pools in devstack is a non backward compatible
> change for devstack currently and it doesn't appear to have been
> documented in devstack at all. Would be great if we can finally fix this
> and get testing back to working and however we fix it ensure that
> devstack has the appropriate documentation.
>

What is holding [1] back? Merging that would resolve the issue, then we can
drill down into why subnetpools interfere with the underlying networking
setup. I have asked Carl to look into broken build [2]

[1] https://review.openstack.org/#/c/379543/
[2]
http://logs.openstack.org/78/381278/2/check/gate-tempest-dsvm-neutron-multinode-full-ubuntu-xenial/7f82862/console.html.gz


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

Re: [openstack-dev] [Neutron] Team meeting this Monday at 2100 UTC + forthcoming schedule

2016-10-17 Thread Armando M.

On 17 October 2016 at 11:45, Dariusz Śmigiel <smigiel.dari...@gmail.com>
wrote:

> It means that next Team Meeting will have a place on November 8, Tuesday.
>
> Any cancellations for other Neutron Meetings?
>

I think those should be advertised in emails with their respective subjects.


>
> 2016-10-17 13:28 GMT-05:00 Armando M. <arma...@gmail.com>:
> > Hi neutrinos,
> >
> > A kind reminder for this week's meeting. More on the agenda [1]. Also,
> due
> > to the summit, the next occurrences will be cancelled.
> >
> > - Oct 25, Tuesday
> > - Oct 31, Monday
> >
> > Cheers,
> > Armando
> >
> > [1] https://wiki.openstack.org/wiki/Network/Meetings
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
>
> --
> Darek "dasm" Śmigiel
>
> 
> Q: Why is this email five sentences or less?
> A: http://five.sentenc.es
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] broken linuxbridge gate

2016-11-29 Thread Armando M.

Hi folks,

A recent devstack set of changes [0,1] accidentally broke the linuxbridge
job in that bridge_mappings are no longer applied correct. To add insult to
injury, this got applied to both stable and master (with the stable fix
landing first). See [2,3] for a difference.

This is not the first time we accidentally break the job, therefore I would
like to suggest that we add it to the devstack check queue. The job was is
on the experimental queue but it's hardly exercised.

Armando

[0] https://review.openstack.org/#/c/404477/
[1] https://review.openstack.org/#/c/400258/
[2]
http://logs.openstack.org/99/360799/37/check/gate-tempest-dsvm-neutron-linuxbridge-ubuntu-xenial/7a8736b/logs/etc/neutron/plugins/ml2/ml2_conf.ini.txt.gz
[3]
http://logs.openstack.org/13/397913/8/gate/gate-tempest-dsvm-neutron-linuxbridge-ubuntu-xenial/3a7c298/logs/etc/neutron/plugins/ml2/ml2_conf.ini.txt.gz
__
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] broken linuxbridge gate

2016-11-29 Thread Armando M.

On 29 November 2016 at 15:46, Armando M. <arma...@gmail.com> wrote:

> Hi folks,
>
> A recent devstack set of changes [0,1] accidentally broke the linuxbridge
> job in that bridge_mappings are no longer applied correct. To add insult to
> injury, this got applied to both stable and master (with the stable fix
> landing first). See [2,3] for a difference.
>
> This is not the first time we accidentally break the job, therefore I
> would like to suggest that we add it to the devstack check queue. The job
> was is on the experimental queue but it's hardly exercised.
>
> Armando
>
> [0] https://review.openstack.org/#/c/404477/
> [1] https://review.openstack.org/#/c/400258/
> [2] http://logs.openstack.org/99/360799/37/check/gate-tempest-
> dsvm-neutron-linuxbridge-ubuntu-xenial/7a8736b/logs/
> etc/neutron/plugins/ml2/ml2_conf.ini.txt.gz
> [3] http://logs.openstack.org/13/397913/8/gate/gate-tempest-
> dsvm-neutron-linuxbridge-ubuntu-xenial/3a7c298/logs/
> etc/neutron/plugins/ml2/ml2_conf.ini.txt.gz
>


Just to follow up:

I attempted both a revert [1,2] and a possible fix [3,4]. Either way, I
proposed moving the job to the devstack check/gate queue [5].

[1] https://review.openstack.org/#/c/404480/
[2] https://review.openstack.org/#/c/404477/
[3] https://review.openstack.org/#/c/404482/
[4] https://review.openstack.org/#/c/404484/
[5] https://review.openstack.org/#/c/404480/
__
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] trunk api performance and scale measurments

2016-12-10 Thread Armando M.

On 8 December 2016 at 20:55, Armando M. <arma...@gmail.com> wrote:

>
>
> On 5 December 2016 at 07:59, Bence Romsics <bence.roms...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I measured how the new trunk API scales with lots of subports. You can
>> find the results here:
>>
>> https://wiki.openstack.org/wiki/Neutron_Trunk_API_Performance_and_Scaling
>>
>> Hope you find it useful. There are several open ends, let me know if
>> you're interested in following up some of them.
>>
>
> I looked into [1] a little bit as it bothered me :)
>
> Here's my findings:
>
>
>- openstack port list is slower than neutron port-list as it looks
>like the command goes to Nova first [2], which is where the overhead comes
>from.
>- when you have subports the port-list response gets bigger because of
>the bigger response due to the trunk-details extension.
>- However, the bulk of the time is spent in [3], when building the
>payload for a port involved as a parent port. In no other case you will see
>the overhead as in no other case the loop over subports is executed.
>
> The hook should be optimized!
>

Follow up: Kevin and I put together a couple of patches [1,2] to fix and
validate how to speed up the lookup. We'll dig into why sqlalchemy is
acting differently when listing ports with or without filters, but this
should do for now.

Cheers,
Armando

[1] https://review.openstack.org/#/c/409267/
[2] https://review.openstack.org/#/c/408983/


> [1] https://wiki.openstack.org/wiki/Neutron_Trunk_API_Performanc
> e_and_Scaling#surprise_effect_on_filtered_port_listings
> [2] http://paste.openstack.org/show/591882/
> [3] https://github.com/openstack/neutron/blob/master/
> neutron/services/trunk/plugin.py#L42
>
>
>> Cheers,
>> Bence Romsics
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] Proposing Abhishek Raut as neutronclient core

2016-12-13 Thread Armando M.

Hi folks,

Abhishek Raut's recent involvement in OSC and python-neutronclient has
helped moving a few efforts along in the right direction. I would like to
suggest we double down on core firepower for the neutronclient repo
alongside Akihiro [1].

This not only will help speed up our transition to OSC CLI, but also
improve the number of folks who can effectively liasion with the OSC team,
and look after the needs of neutron's client repo.

Many thanks,
Armando

[1] https://review.openstack.org/#/c/410485/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] drivers meeting cancellation today

Hi folks,

Due to conflicts, we are unable to host the drivers meeting today.

Apologies for the short notice.

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

Re: [openstack-dev] [neutron] Proposing Abhishek Raut as neutronclient core

On 15 December 2016 at 09:50, Akihiro Motoki <amot...@gmail.com> wrote:

> +1
>

Welcome to the team Abhishek!


>
> 2016-12-14 10:22 GMT+09:00 Armando M. <arma...@gmail.com>:
>
>> Hi folks,
>>
>> Abhishek Raut's recent involvement in OSC and python-neutronclient has
>> helped moving a few efforts along in the right direction. I would like to
>> suggest we double down on core firepower for the neutronclient repo
>> alongside Akihiro [1].
>>
>> This not only will help speed up our transition to OSC CLI, but also
>> improve the number of folks who can effectively liasion with the OSC team,
>> and look after the needs of neutron's client repo.
>>
>> Many thanks,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/410485/
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] multinode CI jobs in the gate

Hi Neutrinos,

Infra patch proposed in [1] got me thinking again about what we shall do
when it comes to multinode testing in the gate and how to focus our testing
and CI efforts upstream going forward. My line of thinking has always been
that multinode resources should be devoted to configurations whose coverage
fully benefit from the inherent nature of the distributed deployment, and
that means giving priority to DVR+HA and demote other configurations that
use centralized routing.

I know that some of you in team have worked on this, but I am a bit behind
on the latest status update. Any good soul willing to bring a strapped (for
time) PTL up to speed?

Cheers,
Armando

[1] https://review.openstack.org/#/c/411263/
__
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] [architecture][api][Nova][Neutron][Cinder] nova-compute's architecture/API

On 16 December 2016 at 00:01, Clint Byrum  wrote:

> So, I've been quietly ranting in hallways about this for a while. I may
> be way way off base here. I want to kick the discussion off, so I've
> submitted a proposal to the arch-wg about it. Please if you're interested
> in how Nova/Neutron/Cinder interact with nova-compute, I think it might
> be worthwhile to read it and get it into a factual state, so the arch-wg
> can do a deeper analysis. Please do rip it to shreds in comments, and
> feel free to revise it and add more details. Thanks very much!
>
> https://review.openstack.org/411527
>
>
Noted! I'll bring this up at the next team meeting. Thanks for spearheading
this!


Cheers,
Armando

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

[openstack-dev] [neutron] proposing Ryan Tidwell and Nate Johnston as service LTs

 Hi neutrinos,

I would like to propose Ryan and Nate as the go-to fellows for
service-related patches.

Both are core in their repos of focus, namely neutron-dynamic-routing and
neutron-fwaas, and have a good understanding of the service framework, the
agent framework and other bits and pieces. At this point, entrusting them
with the responsibility is almost a formality.

Cheers,
Armando

[1] https://review.openstack.org/#/c/411536/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] proposing Miguel Lavalle as neutron core and Brian Haley as L3 Lt