from:"Armando M."

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

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

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] 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] Transition to Ubuntu Xenial in the gate

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

[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][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

[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] [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] 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

[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] [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

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

[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

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] Transition to Ubuntu Xenial in the gate

2016-11-10 Thread Armando M.

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
__
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] [lbaas] [octavia] Ocata LBaaS retrospective and next steps recap

2016-11-09 Thread Armando M.

On 9 November 2016 at 05:50, Gary Kotton  wrote:

> Hi,
> What about neutron-lbaas project? Is this project still alive and kicking
> to the merge is done or are we going to continue to maintain it? I feel
> like we are between a rock and a hard place here. LBaaS is in production
> and it is not clear the migration process. Will Octavia have the same DB
> models as LBaaS or will there be a migration?
> Sorry for the pessimism but I feel that things are very unclear and that
> we cannot even indicate to our community/consumers what to use/expect.
> Thanks
> Gary
>

http://specs.openstack.org/openstack/neutron-specs/specs/newton/kill-neutron-lbaas.html


>
> On 11/8/16, 1:36 AM, "Michael Johnson"  wrote:
>
> Ocata LBaaS retrospective and next steps recap
> --
>
> This session lightly touched on the work in the newton cycle, but
> primarily focused on planning for the Ocata release and the LBaaS spin
> out of neutron and merge into the octavia project [1].  Notes were
> captured on the etherpad [1].
>
> The focus of work for Ocata in neutron-lbaas and octavia will be on
> the spin out/merge and not new features.
>
> Work has started on merging neutron-lbaas into the octavia project
> with API sorting/pagination, quota support, keystone integration,
> neutron-lbaas driver shim, and documentation updates.  Work is still
> needed for policy support, the API shim to handle capability gaps
> (example: stats are by listener in octavia, but by load balancer in
> neturon-lbaas), neutron api proxy, a database migration script from
> the neutron database to the octavia database for existing non-octavia
> load balancers, and adding the "bug for bug" neutron-lbaas v2 API to
> the octavia API server.
>
> The room agreed that since we will have a shim/proxy in neutron for
> some time, updating the OpenStack client can be deferred to a future
> cycle.
>
> There is a lot of concern about Ocata being a short cycle and the
> amount of work to be done.  There is hope that additional resources
> will help out with this task to allow us to complete the spin
> out/merge for Ocata.
>
> We discussed the current state of the active/active topology patches
> and agreed that it is unlikely this will merge in Ocata.  There are a
> lot of open comments and work to do on the patches.  It appears that
> these patches may have been created against an old release and require
> significant updating.
>
> Finally there was a question about when octavia would implement
> metadata tags.  When we dug into the need for the tags we found that
> what was really wanted is a full implementation of the flavors
> framework [3] [4].  Some vendors expressed interest in finishing the
> flavors framework for Octavia.
>
> Thank you to everyone that participated in our design session and
> etherpad.
>
> Michael
>
> [1] https://specs.openstack.org/openstack/neutron-specs/specs/
> newton/kill-neutron-lbaas.html
> [2] https://etherpad.openstack.org/p/ocata-neutron-octavia-
> lbaas-session
> [3] https://specs.openstack.org/openstack/neutron-specs/specs/
> mitaka/neutron-flavor-framework-templates.html
> [4] https://specs.openstack.org/openstack/neutron-specs/specs/
> liberty/neutron-flavor-framework.html
>
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][neutron] When are subnets needed on a network to create ports?

2016-11-08 Thread Armando M.

On 8 November 2016 at 18:35, Matt Riedemann 
wrote:

> I've been looking at this nova bug:
>
> https://bugs.launchpad.net/nova/+bug/1637118
>
> And the neutronv2 API code in nova and need some help from the neutron
> team on how this should actually work.
>

If I am not mistaken [1] is what we'd need on the nova side.

As for neutron, we implemented [2], which can be leveraged by [1] in order
to implement the non-backward compatible behavior of lifting the constraint
check should a port be required without an address.

Mind you, I said port intentionally, meaning that even with [1], bug
1637118 would still manifest itself (in other words, it would be the
expected behavior). Booting off unaddressed VMs is an advanced use case and
as such it requires to boot by specifying the port ID.

[1] https://blueprints.launchpad.net/neutron/+spec/vm-without-l3-address
[2] https://blueprints.launchpad.net/nova/+spec/vm-boot-with-
unaddressed-port



> The validation code that runs from nova-api when creating a server checks
> the requested/available networks to see if they have subnets and if not
> it's a failure. The original change that added that way back in icehouse
> was because you'd get a security group could not be applied failure when
> trying to create ports on a network with port security enabled but that
> didn't have subnets.
>
> Now the code in nova that creates the port, which happens in nova-compute,
> handles this - it only fails if the network doesn't have subnets if the
> network has port security enabled. If the network doesn't have port
> security enabled, we don't care about subnets before creating the port.
>
> However, that icehouse-era validation code that happens in the API side
> before casting to the compute is still there, and that's what the bug is
> saying is a problem.
>
> So that sounds like a legitimate issue, but I wanted to get confirmation
> from the neutron team first before moving forward with a fix.
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] summit 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] 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

[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

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

[openstack-dev] [Neutron] Drivers meeting cancelled Oct 27

2016-10-20 Thread Armando M.

Folks,

Just a reminder that due to the ongoing Summit, the drivers team is
cancelled for the week.

We'll meet regularly in the next few hours.

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-dev] [Neutron] retiring python-neutron-pd-driver

2016-10-19 Thread Armando M.

To whom it may concern,

I have started the procedure [1] to retire project [2]. If you are affected
by this, this is the last opportunity to provide feedback. That said, users
should be able to use the in tree version of dibbler as documented in [3].

Cheers,
Armando

[1]
https://review.openstack.org/#/q/I77099ba826b8c7d28379a823b4dc74aa65e653d8
[2] http://git.openstack.org/cgit/openstack/python-neutron-pd-driver/
[3]
http://docs.openstack.org/newton/networking-guide/config-ipv6.html#configuring-the-dibbler-server
__
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] next upgrades meeting is Nov 7th

2016-10-17 Thread Armando M.

On 17 October 2016 at 12:29, Ihar Hrachyshka  wrote:

> Hi all,
>
> due to the summit we cancel the next two upgrades subteam meetings.
>
> We will get back Nov 7th, just in time to close any remaining gaps before
> the world as we know it is destroyed by US elections the next day.
>

Don't even joke about this, it's not funny :)


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

Re: [openstack-dev] [Neutron] 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] Team meeting this Monday at 2100 UTC + forthcoming schedule

2016-10-17 Thread Armando M.

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

[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 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: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

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

[openstack-dev] [Neutron] Stadium evolution - final stage

2016-10-07 Thread Armando M.

Neutrinos,

As some of you may have noticed, there has been a fresh batch of patches on
topic [1]. After having worked on [2][3] during the span of Newton, we are
approaching now the final stage of this consolidation effort, where I
attempt to define a procedure for transparently letting the Neutron
community assess how a subproject meets the standard of quality that any
Neutron-led effort should have.

I started with fwaas and vpnaas so far, and I'll reach out individually to
the maintainers of projects [4] to accurately capture the rest of the
picture. LBaas/Octavia will not be assessed as it's already been agreed
their spinoff [5]. Please bear in mind that the deadline for completing
this assessment effort is firmly set to be Ocata-1 (Nov 14 2016).

Many thanks,
Armando

[1] https://review.openstack.org/#/q/topic:stadium-implosion+status:open
[2] http://specs.openstack.org/openstack/neutron-specs/
specs/newton/neutron-stadium.html
[3] http://docs.openstack.org/developer/neutron/stadium/index.html
[4] http://governance.openstack.org/reference/projects/neutron.html
[5] https://specs.openstack.org/openstack/neutron-specs/
specs/newton/kill-neutron-lbaas.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][Nova] Expose trunk details over metadata API

2016-10-07 Thread Armando M.

On 7 October 2016 at 06:43, Bence Romsics  wrote:

> Hi,
>
> To follow up on the complications of bringing up trunk subports [1] I
> have written up a small proposal for a tiny new feature affecting
> neutron and nova. That is how to expose trunk details over metadata
> API. To avoid big process overhead I have opened a newton rfe ticket
> [2], plus a nova specless blueprint [3] pointing to it. Please let me
> know if I should have followed a different process.
>
>
Replied on [2]. From a Neutron's standpoint, I suspect you already have
what you need.


> Cheers,
> Bence
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2016-
> September/104848.html
> [2] https://bugs.launchpad.net/neutron/+bug/1631371
> [3] https://blueprints.launchpad.net/nova/+spec/trunk-details-meta
>
> __
> 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] Driver meeting cancelled for Thur Sept 29

2016-09-28 Thread Armando M.


__
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] Retiring stale stadium projects

2016-09-27 Thread Armando M.

Hi Neutrinos,

I wanted to double check with you the state of these following projects:

- networking-ofagent
- python-neutron-pd-driver

It's my understanding that they are ready for retirement or thereabouts.
Please confirm, and I'll kick off the countdown sequence [1].

Cheers,
Armando

[1] http://docs.openstack.org/infra/manual/drivers.html#retiring-a-project
__
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] Ocata Design Summit ideas kick-off

2016-09-27 Thread Armando M.

Hi folks,

The summit is less than a month away and it's the time of the year where we
need to plan for design summit sessions.

This time we are going for 10 fishbowl sessions, plus Friday [0].

We will break down sessions in three separate tracks as we did the last two
summits. Each track will have its own theme and more details will be
provided in due course.

I started etherpad [1] to collect inputs and ideas. Please start
brainstorming! I'll reach out to the driver team members individually to
work out a more formal agenda once we get some ideas off the ground.

Cheers,
Armando

[0] http://lists.openstack.org/pipermail/openstack-dev/
2016-September/103851.html
[1] https://etherpad.openstack.org/p/ocata-neutron-summit-ideas
__
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] dhcp 'Address already in use' errors when trying to start a dnsmasq

2016-09-27 Thread Armando M.

On 27 September 2016 at 11:29, Miguel Angel Ajo Pelayo 
wrote:

> Ack, and thanks for the summary Ihar,
>
> I will have a look on it tomorrow morning, please update this thread
> with any progress.
>
>
>
> On Tue, Sep 27, 2016 at 8:22 PM, Ihar Hrachyshka 
> wrote:
> > Hi all,
> >
> > so we started getting ‘Address already in use’ when trying to start
> dnsmasq
> > after the previous instance of the process is killed with kill -9.
> Armando
> > spotted it today in logs for: https://review.openstack.org/#/c/377626/
> but
> > as per logstash it seems like an error we saw before (the earliest I see
> is
> > 9/20), f.e.:
> >
> > http://logs.openstack.org/26/377626/1/check/gate-tempest-dsv
> m-neutron-full-ubuntu-xenial/b6953d4/logs/screen-q-dhcp.txt.gz
> >
> > Assuming I understand the flow of the failure, it runs as follows:
> >
> > - sync_state starts dnsmasq per network;
> > - after agent lock is freed, some other notification event
> > (port_update/subnet_update/...) triggers restart for one of the
> processes;
> > - the restart is done not via reload_allocations (-SIGHUP) but thru
> > restart/disable (kill -9);
> > - once the old dnsmasq is killed with -9, we attempt to start a new
> process
> > with new config files generated and fail with: “dnsmasq: failed to create
> > listening socket for 10.1.15.242: Address already in use”
> > - surprisingly, after several failing attempts to start the process, it
> > succeeds to start it after a bunch of seconds and runs fine.
> >
> > It looks like once we kill the process with -9, it may hold for the
> socket
> > resource for some time and may clash with the new process we try to
> spawn.
> > It’s a bit weird because dnsmasq should have set REUSEADDR for the
> socket,
> > so a new process should have started just fine.
> >
> > Lately, we landed several patches that touched reload logic for DHCP
> agent
> > on notifications. Among those suspicious in the context are:
> >
> > - https://review.openstack.org/#/c/372595/ - note it requests ‘disable’
> (-9)
> > where it was using ‘reload_allocations’ (-SIGHUP) before, and it also
> does
> > not unplug the port on lease release (maybe after we rip of the device,
> the
> > address clash with the old dnsmasq state is gone even though the ’new’
> port
> > will use the same address?).
> > - https://review.openstack.org/#/c/372236/6 - we were requesting
> > reload_allocations in some cases before, and now we put the network into
> > resync queue
> >
> > There were other related changes lately, you can check history of Kevin’s
> > changes for the branch, it should capture most of them.
> >
> > I wonder whether we hit some long standing restart issue with dnsmasq
> here
> > that was just never triggered before because we were not calling kill -9
> so
> > eagerly as we do now.
> >
> > Note: Jakub Libosvar validated that 'kill -9 && dnsmasq’ in loop does NOT
> > result in the failure we see in gate logs.
> >
> > We need to understand what’s going with the failure, and come up with
> some
> > plan for Newton. We either revert suspected patches as I believe Armando
> > proposed before, but then it’s not clear until which point to do it; or
> we
> > come up with some smart fix for that, that I don’t immediately grasp.
> >
> > I will be on vacation tomorrow, though I will check the email thread to
> see
> > if we have a plan to act on. I really hope folks give the issue a
> priority
> > since it seems like we buried ourselves under a pile of interleaved
> patches
> > and now we don’t have a clear view of how to get out of the pile.
>

Personally I feel there is no time left for us to do anything about this in
RC2. Nothing at this point is going to guarantee that another patch is not
gonna lead us to new potential ripple effects. I am personally okay to cut
RC2 as it stands, and let downstream players have some time vetting the
build and give us a chance to fix one more last minute "disaster".

Rest assured we'll learn from this mistake.

A.

>
> > Cheers,
> > Ihar
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.op
> enstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
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] Preparing RC2

2016-09-26 Thread Armando M.

Neutrinos,

A this point, please consider the list of fixes for RC2 [1] final. We are
no longer considering adding anything to the list unless it's critical and
preventing merges.

Zuul is pretty backed up so we need to clear the currently backlog before
considering adding anything else. We have a WIP from which we'll release.
Ihar and I will refresh it by EOB Tue Sept 27.

If there is anything else you would like to address, please reach out on
IRC.

Thanks,
Armando

[1] https://launchpad.net/neutron/+milestone/newton-rc2
[2] https://review.openstack.org/#/c/376998/
__
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][stadium] Query regarding procedure for inclusion in Neutron Stadium

2016-09-23 Thread Armando M.

On 22 September 2016 at 22:36, Takashi Yamamoto <yamam...@midokura.com>
wrote:

> hi,
>
> On Fri, Sep 23, 2016 at 4:20 AM, Armando M. <arma...@gmail.com> wrote:
> >
> >
> > On 22 September 2016 at 00:46, reedip banerjee <reedi...@gmail.com>
> wrote:
> >>
> >> Dear Neutron Core members,
> >>
> >> I have a query regarding the procedure for inclusion in the Neutron
> >> Stadium.
> >> I wanted to know if a project can apply for Big Tent and Neutron Stadium
> >> together ( means can a project be accepted in the Neutron Stadium and
> as a
> >> result into the Big Tent )
> >>
> >> I was checking out the checklist in  [1], and IMO , I think that we need
> >> to conform to the checklist to be added to the Neutron Stadium ( along
> with
> >> the other requirements  like keeping in sync with the core neutron
> concepts)
> >>
> >> But IIUC, certain items in the checklist would be completed if a project
> >> is already included in the Big Tent.
> >
> >
> > I would not worry about those, as these are rather trivial to implement
> in
> > conjunction with Stadium inclusion. I'd worry about the fork that the
> > project relies on, which is a big show stopper for Stadium inclusion.
> >
> > [1] https://github.com/openstack/tap-as-a-service/blob/master/
> setup.cfg#L50
>
> just a clarification; this is not a fork of ovs-agent. it's a separate
> agent.
>

It may not strictly be a fork, but I am not grasping the technical reason
as to why one needs yet another agent on the node. Besides, this might end
up interfering with the OVS agent as it is handling the same resources [1],
without any level of coordination.

[1]
https://github.com/openstack/tap-as-a-service/blob/master/neutron_taas/services/taas/drivers/linux/ovs_taas.py#L43:L44


> >
> >>
> >>
> >> So my doubt is ,should a project apply for the Big Tent first, and after
> >> inclusion, apply for Neutron Stadium ? Or can a project be integrated to
> >> Neutron Stadium and Big Tent simultaneously ( I am a bit sceptical about
> >> this though)?
> >
> >
> > You are confusing the two things. A project either belongs to list [1] or
> > list [2], and you can't be in both at the same time. To be part of either
> > list a project must comply with a set of criteria. As for the latter, a
> > couple of steps may sound like a catch 22: for instance you can't make
> docs
> > available on docs.o.o unless you are in [2] and you can't be in [2]
> > unless...and here's the trick, unless you are a point where you can
> > successfully demonstrate that the project has substantial documentation
> (of
> > any sort, API included). The process of 'demonstrating'/application for
> > inclusion in list [2] follows the RFE submission process that we have
> > adopted for a while, and that means submitting a spec. Since the request
> > does not require a conventional design process, I was going to prepare an
> > ad-hoc template and make it available soon. So watch the neutron-specs
> repo
> > for updates.
> >
> > In the meantime, I'd urge you to go over the checklist and make sure you
> can
> > address the hard parts.
> >
> > If you ask me, if you go with [1], it makes no sense to go and apply to
> be
> > in [2].
> >
> > HTH
> > Armando
> >
> > [1] http://governance.openstack.org/reference/projects/
> > [2] http://governance.openstack.org/reference/projects/neutron.html
> >
> >>
> >>
> >>
> >> [1]
> >> http://docs.openstack.org/developer/neutron/stadium/
> governance.html#checklist
> >> --
> >> Thanks and Regards,
> >> Reedip Banerjee
> >> IRC: reedip
> >>
> >>
> >>
> >>
> >>
> >> 
> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >
> >
> > 
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:
> unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> 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][stadium] Query regarding procedure for inclusion in Neutron Stadium

2016-09-22 Thread Armando M.

On 22 September 2016 at 00:46, reedip banerjee  wrote:

> Dear Neutron Core members,
>
> I have a query regarding the procedure for inclusion in the Neutron
> Stadium.
> I wanted to know if a project can apply for Big Tent and Neutron Stadium
> together ( means can a project be accepted in the Neutron Stadium and as a
> result into the Big Tent )
>
> I was checking out the checklist in  [1], and IMO , I think that we need
> to conform to the checklist to be added to the Neutron Stadium ( along with
> the other requirements  like keeping in sync with the core neutron concepts)
>
> But IIUC, certain items in the checklist would be completed if a project
> is already included in the Big Tent.
>

I would not worry about those, as these are rather trivial to implement in
conjunction with Stadium inclusion. I'd worry about the fork that the
project relies on, which is a big show stopper for Stadium inclusion.

[1] https://github.com/openstack/tap-as-a-service/blob/master/setup.cfg#L50

>
> So my doubt is ,should a project apply for the Big Tent first, and after
> inclusion, apply for Neutron Stadium ? Or can a project be integrated to
> Neutron Stadium and Big Tent simultaneously ( I am a bit sceptical about
> this though)?
>

You are confusing the two things. A project either belongs to list [1] or
list [2], and you can't be in both at the same time. To be part of either
list a project must comply with a set of criteria. As for the latter, a
couple of steps may sound like a catch 22: for instance you can't make docs
available on docs.o.o unless you are in [2] and you can't be in [2]
unless...and here's the trick, unless you are a point where you can
successfully demonstrate that the project has substantial documentation (of
any sort, API included). The process of 'demonstrating'/application for
inclusion in list [2] follows the RFE submission process that we have
adopted for a while, and that means submitting a spec. Since the request
does not require a conventional design process, I was going to prepare an
ad-hoc template and make it available soon. So watch the neutron-specs repo
for updates.

In the meantime, I'd urge you to go over the checklist and make sure you
can address the hard parts.

If you ask me, if you go with [1], it makes no sense to go and apply to be
in [2].

HTH
Armando

[1] http://governance.openstack.org/reference/projects/
[2] http://governance.openstack.org/reference/projects/neutron.html

>
>
> [1] http://docs.openstack.org/developer/neutron/stadium/
> governance.html#checklist
> --
> Thanks and Regards,
> Reedip Banerjee
> IRC: reedip
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Broken port rule masking: let's have it fixed?

2016-09-22 Thread Armando M.

On 22 September 2016 at 05:50, Inessa Vasilevskaya <
ivasilevsk...@mirantis.com> wrote:

> Hello,
>
> Apologies for multiple posts, forgot to set proper subject in previous one.
>
> I'd like to turn attention to the broken port rule masking problem [1],
> which affects 2 projects so far:
> neutron (mitaka+ with ovs firewall driver configuration) and
> networking-ovs-dpdk [2].
>
> To keep it short: the existing port masking implementation is broken and
> in several cases it will either leave a range of ports open (causing
> unrestricted access) or make some ports inaccessible (when they should be
> open) because of bad tp_src value being generated.
>
> 2 solutions have been proposed so far:
> * The "low-level one" with O(log n) complexity by IWAMOTO Toshihiro and me
> [2]
> * The "high-level one" with O(n^2) complexity by Jakub Libosvar [3]
>
> As long as the bug looks like a security vulnerability and is kind of
> critical for ovs firewall feature, maybe we should choose one algorithm to
> go on with and have this fixed in Newton?
>
>
We'll try to converge on a path forward during today's Neutron drivers
meeting. Watch the logs.

Cheers,
Armando


> [1] https://bugs.launchpad.net/neutron/+bug/1611991
> [2] https://review.openstack.org/#/c/353782/30
> [3] https://review.openstack.org/#/c/353782/16
>
> Best regards,
> Inessa Vasilevskaya
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][neutron] summit cross-project session

2016-09-19 Thread Armando M.

On 18 September 2016 at 11:46, Matt Riedemann 
wrote:

> I want to confirm whether or not we're going to have a nova/neutron
> cross-project fishbowl session in Barcelona, I think we are. Since Thierry
> has the draft slots out I wanted to start looking at what time is going to
> work.
>
Looking at:
>
> https://docs.google.com/spreadsheets/d/1TQ-RSlbiBBEclkonIbfU
> P7R1ExZSJylF1uiEKV2G_Cw/pubhtml?gid=1107826458=true
>
> Anytime on Thursday afternoon would work - agreed? I'd like to pencil
> something in.
>

I asked an extra session on the Neutron side to dedicate to nova/neutron,
and I was hoping to have them back to back, but it doesn't look possible
under the current arrangement. Do you think it's worth trying and tweak
things? If not I guess we can have one on Wed the other on Thu.


>
> As far as topics, I think we'll pull from the neutron midcycle report:
>
> http://lists.openstack.org/pipermail/openstack-dev/2016-August/102366.html
>
> So mainly live migration and API interaction improvements.


>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> 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] Adding ihrachys to the neutron-drivers team

2016-09-17 Thread Armando M.

Hi folks,

I would like to propose Ihar to become a member of the Neutron drivers team
[1].

Ihar wide knowledge of the Neutron codebase, and his longstanding duties as
stable core, downstream package whisperer, release and oslo liaison (I am
sure I am forgetting some other capacity he is in) is going to put him at
great comfort in the newly appointed role, and help him grow and become
wise even further.

Even though we have not been meeting regularly lately we will resume our
Thursday meetings soon [2], and having Ihar onboard by then will be highly
beneficial.

Please, join me in welcome Ihar to the team.

Cheers,
Armando

[1] http://docs.openstack.org/developer/neutron/policies/neutron-teams.html#
drivers-team
[2] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Newton Postmortem

2016-09-16 Thread Armando M.

Neutrinos,

Now that Ocata is with us, we can almost regain our ability to pronounce
Neutron without confusing it with Newton (at least I know I can).

Before doing that, there is still the postmortem to finalize [1]. I will
keep on touching it between now and the day of the official release to make
sure we captured accurately what's been accomplished in, erm, Newton.

I need your help to make sure everything is in tip-top shape, please keep
an eye and review [1] regularly.

Thanks,
Armando

[1] https://review.openstack.org/#/c/360207/
__
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] Fwd: [release][Neutron] Neutron Newton RC1 available

2016-09-16 Thread Armando M.

Neutrinos,

As per announcement below, we are now past RC1. I'll be going over the
changes that were blocked during the past week and lift the -2s. Even
though master development is open, please consider focusing on Newton with
a great deal of attention [1].

Make sure to give review priority to issues as tracked in [2,3,4].

If you have any question, please reach out to a member of the Neutron
release team [5] on IRC.

Cheers,
Armando

[1]
http://docs.openstack.org/developer/neutron/policies/release-checklist.html
[2] https://bugs.launchpad.net/neutron/+bugs?field.tag=doc
[3] https://bugs.launchpad.net/neutron/+bugs?field.tag=deprecation
[4] https://bugs.launchpad.net/neutron/+bugs?field.tag=newton-rc-potential
[5] https://review.openstack.org/#/admin/groups/150,members

-- Forwarded message --
From: Davanum Srinivas 
Date: 16 September 2016 at 09:27
Subject: [openstack-dev] [release][Neutron] Neutron Newton RC1 available
To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev@lists.openstack.org>


Hello everyone,

The release candidate for Neutron for the end of the Newton cycle
is available!  You can find the RC1 source code tarball(s) at:

https://tarballs.openstack.org/neutron/neutron-9.0.0.0rc1.tar.gz
https://tarballs.openstack.org/neutron-fwaas/neutron-fwaas-9.0.0.0rc1.tar.gz
https://tarballs.openstack.org/neutron-dynamic-routing/
neutron-dynamic-routing-9.0.0.0rc1.tar.gz
https://tarballs.openstack.org/neutron-lbaas/neutron-lbaas-9.0.0.0rc1.tar.gz
https://tarballs.openstack.org/neutron-vpnaas/neutron-
vpnaas-9.0.0.0rc1.tar.gz

Unless release-critical issues are found that warrant a release
candidate respin, this RC1 will be formally released as the final
Newton release on 6 October. You are therefore strongly
encouraged to test and validate this tarball!

Alternatively, you can directly test the stable/newton release
branch at:

http://git.openstack.org/cgit/openstack/neutron/log/?h=stable/newton

If you find an issue that could be considered release-critical,
please file it at:

https://bugs.launchpad.net/neutron/+filebug

and tag it *newton-rc-potential* to bring it to the Neutron release
crew's attention.

Note that the "master" branch of Neutron is now open for Ocata
development, and feature freeze restrictions no longer apply there!

Thanks,
Dims (On behalf of the Release Team)


--
Davanum Srinivas :: https://twitter.com/dims

__
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] Preparing to cut RC1

2016-09-15 Thread Armando M.

Neutrinos,

In the next 24 hours we will be cutting RC1. Unfortunately we're battling
with a nasty bug, that's causing some instability and we're trying to find
the root cause. Please back off rechecking and merging until we figured out
what's happening.

In the meantime, do not be surprised if patches are given a -2 and their
relative LP entries are moved over to Ocata-1. If you think it's of
paramount importance for those changes to be part of Newton, and you are
actively working on them, please use the tag 'newton-rc-potential' [2], to
draw attention from the Neutron release team.

Thanks,
Armando

[1] https://bugs.launchpad.net/bugs/1623732
[2] https://bugs.launchpad.net/neutron/+bugs?field.tag=newton-rc-potential
__
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][Nova][Infra] Linuxbridge job bump

2016-09-08 Thread Armando M.

Folks,

This morning we merged the switch to Xenial for the Linuxbridge job.
However, we overlooked the fact that the job configuration hardcodes eth0
as one of the variables needed by the Neutron linux bridge driver [2]. That
led to failures like [3].

We have a number of changes in the works to overcome this issue [2,4,5].

Many thanks,
Armando

[1] https://review.openstack.org/#/c/367014/
[2] https://review.openstack.org/#/c/367704/
[3]
http://logs.openstack.org/31/367331/1/gate/gate-tempest-dsvm-neutron-linuxbridge-ubuntu-xenial/bdba22e/logs/screen-q-agt.txt.gz
[4] https://review.openstack.org/#/c/367699/
[5] https://review.openstack.org/#/c/367693/
__
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] Feature Freeze and Feature Freeze exceptions

2016-09-07 Thread Armando M.

Hi folks,

We are about a week away from cutting our first release candidate [0]. In
preparation for that event, we need to make sure our postmortem [1] and FFE
requests are in good order.

For those of you have not had the chance of commenting on [1], please go
ahead and provide your input. Anything else that lacks feedback will very
likely be deferred to Ocata [2] or killed altogether if I am unable to
trace back any recent development. Also, bear in mind that your pending
specs should be retargeted to the new Ocata spec directory [3].

As soon as we cut RC1 and the newton stable branch is cut, master is open
again. For critical or last minute fixes, please file a bug and target for
RC1 for us to evaluate its release impact.

Many thanks for your collaboration!
Cheers,
Armando

[0]
http://lists.openstack.org/pipermail/openstack-dev/2016-September/102829.html
[1] https://review.openstack.org/#/c/360207/
[2] https://launchpad.net/neutron/ocata
[3] https://github.com/openstack/neutron-specs/tree/master/specs/ocata
[4] https://launchpad.net/neutron/+milestone/newton-rc1
__
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] Team meeting cancelled

2016-09-02 Thread Armando M.

Neutrinos,

Because of holidays in US, it's probably safer to cancel the meeting for
the week starting Monday 5th.

Ask for your FFE, as needed on [1]

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

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

Re: [openstack-dev] [Neutron] Cutting milestone 3 deliverables

2016-09-01 Thread Armando M.

Neutrinos,

Milestone 3 deliverables have been published [1].

Please, help us check the release notes to make sure everything in order
and post patches to tidy up the release notes if needed. Some of these
reminders are captured in [2], therefore please feel free to help. [3]
captures a list of documentation related bugs, please let's squash those as
much as we can.

We have time to land RC1 targeted changes between now until the 12th. I did
block a number of changes this morning but I will unblock them in the next
hour.

Be mindful of what you approve for merge (e.g. patches containing DB
migration need special attention), and double check whether it's aimed at
making RC1 solid/complete. If not, please refrain from putting it in the
gate queue.

Many thanks for your help!

Cheers,
Armando

[1] https://releases.openstack.org/newton/index.html
[2]
http://docs.openstack.org/developer/neutron/policies/release-checklist.html
[3] https://bugs.launchpad.net/neutron/+bugs?field.tag=doc

On 1 September 2016 at 11:45, Armando M. <arma...@gmail.com> wrote:

> Neutrinos,
>
> We are in the process of releasing the deliverables for Newton 3. This
> means we are in feature freeze and nothing should be approved for merging
> unless it is release critical, gate blocker, targeted for RC1[1] or has
> been granted a feature freeze exception [2] on the postmortem.
>
> For any question, please reach out on irc.
>
> Thanks,
> Armando
>
> [1] https://launchpad.net/neutron/+milestone/newton-rc1
> [2] https://review.openstack.org/#/c/360207/
>
__
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] Cutting milestone 3 deliverables

2016-09-01 Thread Armando M.

Neutrinos,

We are in the process of releasing the deliverables for Newton 3. This
means we are in feature freeze and nothing should be approved for merging
unless it is release critical, gate blocker, targeted for RC1[1] or has
been granted a feature freeze exception [2] on the postmortem.

For any question, please reach out on irc.

Thanks,
Armando

[1] https://launchpad.net/neutron/+milestone/newton-rc1
[2] https://review.openstack.org/#/c/360207/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][networking-sfc] need help on requesting release for networking-sfc

2016-08-31 Thread Armando M.

On 31 August 2016 at 17:31, Cathy Zhang  wrote:

> CC OpenStack alias.
>
>
>
> *From:* Cathy Zhang
> *Sent:* Wednesday, August 31, 2016 5:19 PM
> *To:* Armando Migliaccio; Ihar Hrachyshka; Cathy Zhang
> *Subject:* need help on requesting release for networking-sfc
>
>
>
> Hi Armando/Ihar,
>
>
>
> I would like to submit a request for a networking-sfc release. I did this for
> previous branch release by submitting a bug request in launchpad before.
> I see that other subproject, such as L2GW, did this in Launchpad for mitaka
> release too.
>
> But the Neutron stadium link http://docs.openstack.org/
> developer/neutron/stadium/sub_project_guidelines.html#sub-
> project-release-process states that “A sub-project owner proposes a patch
> to openstack/releases repository with the intended git hash. The Neutron
> release liaison should be added in Gerrit to the list of reviewers for the
> patch”.
>
>
>
> Could you advise which way I should go or should I do both?
>

Consider the developer documentation the most up to date process, so please
go ahead with a patch against the openstack/releases repo.


>
>
> Thanks,
>
> Cathy
>
__
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][Nova] Neutron mid-cycle summary report

2016-08-26 Thread Armando M.

Hi Neutrinos,

For those of you who couldn't join in person, please find a few notes below
to capture some of the highlights of the event.

I would like to thank everyone one who helped me put this report together,
and everyone who helped make this mid-cycle a fruitful one.

I would also like to thank IBM, and the individual organizers who made
everything go smoothly. In particular Martin, who put up with our moody
requests: thanks Martin!!

Feel free to reach out/add if something is unclear, incorrect or incomplete.

Cheers,
Armando

~~~

We touched on these topics (as initially proposed on
*https://etherpad.openstack.org/p/newton-neutron-midcycle-workitems
*)


   - Keystone v3 and project-id adoption:
  - dasm and amotoki have been working to making the Neutron server
  process project-id correctly [1]. Looking at the spec [2], we
are half way
  through having completed the DB migration, being Keystone v3
complaint, and
  having updated the client bindings [3].
 - [1] https://review.openstack.org/#/c/357977/
 - [2] https://review.openstack.org/#/c/257362/
 - [3] https://review.openstack.org/#/q/topic:bp/keystone-v3
  - Neutron-lib:
  - HenryG, dougwig and kevinbenton worked out a plan to get the
common_db_mixin
  into neutron-lib. Because of the risk of regression, this is
being deferred
  until Ocata opens up. However, simpler changes like the he model_base
  move to lib was agreed on and merged.
  - A plan to provide test support was discussed. The current strategy
  involves providing test base classes in lib (this reverses the stance
  conveyed in Austin). The usual steps involved require to making
  public the currently private classes, ensure the lib's copies are
  up-to-date with core neutron, and deprecate the ones located in
  Neutron.
  - rtheis and armax worked on having networking-ovn test periodically
  against neutron-lib [1,2,3].
 - [1] https://review.openstack.org/#/c/357086/
 - [2] https://review.openstack.org/#/c/359143/
 - [3] https://review.openstack.org/#/c/357079/
  - A tool (tools/migration_report.sh) helps project team determine the
  level of dependency they have with Neutron. It should be
improved to report
  the exact offending imports.
  - Right now neutron-lib 0.4.0 is released and available in
  global-requirements/upper-constraints.
   - Objects and hitless upgrades:
  - Ihar gave the team an overview and status update [1]
  - There was a fruitful discussion that hopefully set the way forward
  for Ocata. The discussed plan was to start Ocata with the
expectation that
  no new contract scripts are landing in Ocata, and to revisit the
  requirement later if for some reason we see any issue with applying the
  requirement in practice.
  - Some work was done to deliver necessary objects for
  push-notifications. Patches up for review. Some review cycles
were spent to
  work on landing patches moving model definitions under neutron/db/models
  - [1] http://lists.openstack.org/pipermail/openstack-dev/
 2016-August/101838.html
  - OSC transition:


   - rtheis gave an update to the team on the state of the transition. Core
  resources commands are all available through OSC; QoS, Metering and *-aaS
  are still not converted.
  - There is some confusion on how to tackle openstacksdk support. We
  discussed the future goal of python binding of Networking API. OSC uses
  OpenStack SDK for network commands and Neutron OSC plugin uses python
  bindings from python-neutronclient. A question is to which project
  developers who add new features implement, both, openstack SDK or
  python-neutronclient? There was no conclusion at the mid-cycle. It is not
  specific to neutron. Similar situation can happen for nova, cinder and
  other projects and we need to raise it to the community.


   - Ocata is going to be the first release where the neutronclient CLI is
  officially deprecated. It may take us more than the usual two cycles to
  remove it altogether, but that's a signal to developer and users to
  seriously develop against OSC, and report bugs against OSC.
  - Several pending contributions into osc-lib.
  - An update is available on [1,2]


   - [1] https://review.openstack.org/#/c/357844/
 - [2] https://etherpad.openstack.org/p/osc-neutron-support
  - Stability squash:
  - armax was bug deputy for the week of the mid-cycle; nothing
  critical showed up in the gate, however pluggable ipam [1] switch merged,
  which might have some unexpected repercussions down the road.
  - A number of bugs older than a year were made expirable [2].
  - kevinbenton and armax devised a strategy and started working on [3]
  to ensure DB retriable

[openstack-dev] [nova] [os-vif] [neutron] Race in setting up linux bridge

2016-08-26 Thread Armando M.

Folks,

Today I spotted [1]. It turns out Neutron and Nova might be racing trying
to set up the bridge to provide VM with connectivity/dhcp. In the observed
failure mode, os-vif fails in [2].

I suppose we might need to protect the bridge creation and make it handle
the potential exception. We would need a similar fix for Neutron in [3].

That said, knowing there is a looming deadline [4], I'd invite folks to
keep an eye on the bug.

Many thanks,
Armando

[1] https://bugs.launchpad.net/neutron/+bug/1617447
[2]
https://github.com/openstack/os-vif/blob/master/vif_plug_linux_bridge/linux_net.py#L125
[3]
http://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/linux/bridge_lib.py#n58
[4]
http://lists.openstack.org/pipermail/openstack-dev/2016-August/102339.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] Wrapping up Newton

2016-08-25 Thread Armando M.

Hi Neutrinos,

Newton-3 is almost upon us. We are now in non-client requirement freeze,
and a week away from client requirement/feature freeze. This is the time
where we switch gear...for real:

   - Start focusing on testing and documentation, if you have not done so
   already;
   - Apply for FFE on postmortem [1];
   - For pending efforts that get a FFE granted, there's time until [3].
   - Ocata opens up as soon as RC1 is cut [4], therefore those that get
   denied will have to be pushed back until then.

When in doubt, reach out!

Cheers,
Armando

[1] https://review.openstack.org/#/c/360207/
[2] https://releases.openstack.org/newton/schedule.html
[3] Newton 3 milestone, Sept 1.
[4] Newton RC-1, 15 Sept.
__
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 team cancelled

2016-08-25 Thread Armando M.

Hi folks,

We have a few absences today, apologies for the short notice but I am going
to cancel the meeting.

If there is anything release related you'd like to discuss please reach out
to me on this thread or IRC.

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

Re: [openstack-dev] [Neutron] Intermittent gate failures

2016-08-24 Thread Armando M.

On 24 August 2016 at 10:30, Armando M. <arma...@gmail.com> wrote:

>
>
> On 22 August 2016 at 18:25, Armando M. <arma...@gmail.com> wrote:
>
>>
>>
>> On 22 August 2016 at 09:51, Armando M. <arma...@gmail.com> wrote:
>>
>>> Neutrinos,
>>>
>>> Since the merge of test [1], a race has surfaced, which leads to failure
>>> as reported in [2]. A number of Neutron's jobs are affected, and even
>>> though the failure is only intermittent, it is particularly bad for the
>>> linux bridge job.
>>>
>>> If I can ask you to hold your +2/+W until [3] puts the fire out, zuul
>>> will be grateful.
>>>
>>
>> An update:
>>
>> We have [1] in the gate queue, and Kevin is going full steam with [2],
>> which will mitigate the other intermittent issues we're facing in
>> functional and unit tests. Please bear with us.
>>
>> Cheers,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/358753/
>> [2] https://review.openstack.org/#/c/356530/
>>
>>
>>>
>>> Thanks,
>>> Armando
>>>
>>> [1] https://review.openstack.org/#/c/327191/
>>> [2] https://bugs.launchpad.net/neutron/+bug/1615710
>>> [3] https://review.openstack.org/#/c/358753/
>>>
>>
>
> One more update:
>
> We're not quite out of the woods, yet so approve/recheck gently please.
>
> Things have become slightly better but we still have a pending fix for
> Neutron [1]. Recently we also observed zuul nodes dying unexpectedly on the
> OSIC cloud (that runs Neutron on IPv6) and that had an impact on the
> overall sluggishness of the gate [2]. Once all of the fixes are in, we
> should be back in business...until the next fire!
>

Another (final) update:

Changes [1] have merged. That should take care of the infra node resets.

At this point, there's [2] to wrap up, but things look largely recovered
[3,4] (though we need [5] to fully see a current picture). Please keep an
eye on [6], and help report/address critical fixes in the busy times ahead.

Cheers,
Armando

[1]
https://review.openstack.org/#/q/Ia044fff2a1731ab6c04f82aea47096b425e0c0a0,n,z
[2] https://review.openstack.org/#/c/356530/
[3]
http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelId=3
[4]
http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelId=5
[5] https://review.openstack.org/#/c/358462/
[6]
https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=NEW%3Alist=CONFIRMED=gate-failure


>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/356530/
> [2] https://bugs.launchpad.net/neutron/+bug/1616282
>
>
__
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] Intermittent gate failures

2016-08-24 Thread Armando M.

On 22 August 2016 at 18:25, Armando M. <arma...@gmail.com> wrote:

>
>
> On 22 August 2016 at 09:51, Armando M. <arma...@gmail.com> wrote:
>
>> Neutrinos,
>>
>> Since the merge of test [1], a race has surfaced, which leads to failure
>> as reported in [2]. A number of Neutron's jobs are affected, and even
>> though the failure is only intermittent, it is particularly bad for the
>> linux bridge job.
>>
>> If I can ask you to hold your +2/+W until [3] puts the fire out, zuul
>> will be grateful.
>>
>
> An update:
>
> We have [1] in the gate queue, and Kevin is going full steam with [2],
> which will mitigate the other intermittent issues we're facing in
> functional and unit tests. Please bear with us.
>
> Cheers,
> Armando
>
> [1] https://review.openstack.org/#/c/358753/
> [2] https://review.openstack.org/#/c/356530/
>
>
>>
>> Thanks,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/327191/
>> [2] https://bugs.launchpad.net/neutron/+bug/1615710
>> [3] https://review.openstack.org/#/c/358753/
>>
>

One more update:

We're not quite out of the woods, yet so approve/recheck gently please.

Things have become slightly better but we still have a pending fix for
Neutron [1]. Recently we also observed zuul nodes dying unexpectedly on the
OSIC cloud (that runs Neutron on IPv6) and that had an impact on the
overall sluggishness of the gate [2]. Once all of the fixes are in, we
should be back in business...until the next fire!

Cheers,
Armando

[1] https://review.openstack.org/#/c/356530/
[2] https://bugs.launchpad.net/neutron/+bug/1616282
__
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] Intermittent gate failures

2016-08-22 Thread Armando M.

On 22 August 2016 at 09:51, Armando M. <arma...@gmail.com> wrote:

> Neutrinos,
>
> Since the merge of test [1], a race has surfaced, which leads to failure
> as reported in [2]. A number of Neutron's jobs are affected, and even
> though the failure is only intermittent, it is particularly bad for the
> linux bridge job.
>
> If I can ask you to hold your +2/+W until [3] puts the fire out, zuul will
> be grateful.
>

An update:

We have [1] in the gate queue, and Kevin is going full steam with [2],
which will mitigate the other intermittent issues we're facing in
functional and unit tests. Please bear with us.

Cheers,
Armando

[1] https://review.openstack.org/#/c/358753/
[2] https://review.openstack.org/#/c/356530/


>
> Thanks,
> Armando
>
> [1] https://review.openstack.org/#/c/327191/
> [2] https://bugs.launchpad.net/neutron/+bug/1615710
> [3] https://review.openstack.org/#/c/358753/
>
__
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] Intermittent gate failures

2016-08-22 Thread Armando M.

Neutrinos,

Since the merge of test [1], a race has surfaced, which leads to failure as
reported in [2]. A number of Neutron's jobs are affected, and even though
the failure is only intermittent, it is particularly bad for the linux
bridge job.

If I can ask you to hold your +2/+W until [3] puts the fire out, zuul will
be grateful.

Thanks,
Armando

[1] https://review.openstack.org/#/c/327191/
[2] https://bugs.launchpad.net/neutron/+bug/1615710
[3] https://review.openstack.org/#/c/358753/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] Thoughts on testing novaclient functional with neutron

2016-08-12 Thread Armando M.

On 12 August 2016 at 08:13, Matt Riedemann 
wrote:

> I opened a bug yesterday against novaclient for running the functional
> tests against a neutron-backed devstack:
>
> https://bugs.launchpad.net/python-novaclient/+bug/1612410
>
> With neutron being the default in devstack now, people hacking on
> novaclient and running functional tests locally are going to have a hard
> time since the tests are unconditionally written with the assumption that
> the backing devstack is using nova-network.
>
> So we need to make the tests conditional, the question is what's the best
> way?
>
> We could use a config like how Tempest does it, but where does that
> happen? In the clouds.yaml, or the post_test_hook.sh, other?
>
> Another idea is the base functional test that sets up the client just
> checks the keystone service catalog for a 'network' service entry,
> somewhere in here:
>
> https://github.com/openstack/python-novaclient/blob/232711c0
> ef98baf79bcf4c8bdbae4b84003c9ab9/novaclient/tests/functional/base.py#L116
>
> Thoughts on either approach or something completely different?


Doesn't it make sense to configure the functional tests for novaclient to
make devstack work on a nova-net backend, and introduce a new non-voting
job used to flush out the new backend option, and transition over the old
job to the new one in due course?



>
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> __
> 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] Team and Driver meetings for the week of Aug 15th

2016-08-11 Thread Armando M.

Hi Neutrinos,

The meetings will be cancelled due to the mid-cycle.

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

Re: [openstack-dev] [neutron] Feature Classification

2016-08-10 Thread Armando M.

On 10 August 2016 at 10:20, Gupta, Ankur  wrote:

> Hello Neutrinos,
>
>
>
> One of the things, that is required to have ease of use, is good
> documentation.
>
> Similar to what's done for Nova [4], I've decided to prepare Feature
> Classification for Neutron.
>
> Work was already approved, and it got greenlit [1], but we still lack of
> final approval. In the light of N-3 [5] approaching, it would be nice to
> have it merged sooner than later.
>
>
>
> What's Feature Matrix Classification?
>
> The feature classification matrix will provide information about backend
> plugins and the features they support.
>
> It acts as a launching point for users to read about the intent of the
> matrix before reviewing the matrix to find features and plugins that meet
> their needs.
>
> This document will allow deployers and operators to figure out which
> backend plugins will fit their specific use case.
>
>
>
> Framework for documentation is ready [2] and can be merged. It will allow
> to render final version of Feature Matrix.
>
> Feature Matrix is also prepared to be merged [3]. It's rough, initial
> version after several iterations. There are still missing pieces of
> information, but even though, it's better to have something, where we can
> start, than nothing.
>

Thanks for working on this! I realize that I have not given the attention
this deserved, I hope to make it up to you during the mid-cycle.

Cheers,
Armando


>
>
>
>
> [1] https://launchpad.net/bugs/1580327
>
> [2] https://review.openstack.org/#/c/318192/
>
> [3] https://review.openstack.org/#/c/324048/
>
> [4] http://docs.openstack.org/developer/nova/feature_classification.html
>
> [5] http://releases.openstack.org/newton/schedule.html
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Neutron Port MAC Address Uniqueness

2016-08-09 Thread Armando M.

On 9 August 2016 at 13:53, Anil Rao  wrote:

> Is the MAC address of a Neutron port on a tenant virtual network globally
> unique or unique just within that particular tenant network?
>

The latter:

https://github.com/openstack/neutron/blob/master/neutron/db/models_v2.py#L139


>
>
> Thanks,
>
> Anil
>
> __
> 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] [all] devstack changing to neutron by default RSN - current issues with OVH

2016-08-08 Thread Armando M.

On 8 August 2016 at 08:01, Sean Dague  wrote:

> In summary, it turns out we learned a few things:
>
> 1) neutron guests in our gate runs don't have the ability to route
> outwards. For instance, if they tried to do a package update, it would
> fail.
>
> 2) adding the ability for them to route outwards (as would be expected
> for things like package updates) was deemed table stakes for the
> devstack default.
>
> 3) doing so fails one tempest test on OVH, because they seem to be
> reflecting network traffic? We see connectivity between guests when it's
> not expected.
>
>
> My proposed path forward:
>
> 1) merge https://review.openstack.org/#/c/350750/ - devstack default
> change
> 2) merge https://review.openstack.org/#/c/352463/ - skip of tempest test
> that will fail on OVH (which turns into a 10% fail rate for neutron)
> 3) look at moving something like
> https://review.openstack.org/#/c/351876/3 into devstack-gate to handle
> OVH special casing. This is going to take time, especially given that we
> get maybe 2 iterations a day due to the gate being overloaded.
> 4) revert https://review.openstack.org/#/c/352463/
>
> If we don't have the devstack default change merged by the middle of the
> week, we probably need to abandon merging in this cycle at all, because
> we need breathing space to address any possible fallout from the merge.
>

I am good with this plan, thanks for the update.


> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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] [all] devstack changing to neutron by default RSN

On 5 August 2016 at 13:05, Dan Smith  wrote:

> > I haven't been able to reproduce it either, but it's unclear how packets
> > would get into a VM on an island since there is no router interface, and
> > the VM can't respond even if it did get it.
> >
> > I do see outbound pings from the connected VM get to eth0, hit the
> > masquerade rule, and continue on their way.  But those packets get
> > dropped at my ISP since they're in the 10/8 range, so perhaps something
> > in the datacenter where this is running is responding?  Grasping at
> > straws is right until we see the results of Armando's test patch.
>
> Right, that's what I was thinking when I said "something with the
> provider" in my other reply. A provider could potentially always reflect
> 10/8 back at you to eliminate the possibility of ever escaping like
> that, which would presumably come back, hit the 10.1/20 route that we
> have and continue on in. I'm not entirely sure why that's not being hit
> right now (i.e. before this change), but I'm less familiar with the
> current state of the art than I am this patch.
>

Still digging but we have a clean pass in [0]. The multinode setup involves
br-ex [1,2], I am not quite sure how changing iptables rules fiddles with
it, if at all.

[0]
http://logs.openstack.org/76/351876/1/experimental/gate-tempest-dsvm-neutron-dvr-multinode-full/3a81575/logs/testr_results.html.gz
[1]
https://github.com/openstack-infra/devstack-gate/blob/master/functions.sh#L1108
[2]
https://github.com/openstack-infra/devstack-gate/blob/master/devstack-vm-gate.sh#L130


>
> --Dan
>
> __
> 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] [all] devstack changing to neutron by default RSN

On 5 August 2016 at 11:25, Armando M. <arma...@gmail.com> wrote:

>
>
> On 5 August 2016 at 10:21, Sean Dague <s...@dague.net> wrote:
>
>> On 08/05/2016 11:34 AM, Armando M. wrote:
>> >
>> >
>> > On 5 August 2016 at 05:59, Sean Dague <s...@dague.net
>> > <mailto:s...@dague.net>> wrote:
>> >
>> > On 08/04/2016 09:15 PM, Armando M. wrote:
>> > > So glad we are finally within the grasp of this!
>> > >
>> > > I posted [1], just to err on the side of caution and get the
>> opportunity
>> > > to see how other gate jobs for Neutron might be affected by this
>> change.
>> > >
>> > > Are there any devstack-gate changes lined up too that we should
>> be aware of?
>> > >
>> > > Cheers,
>> > > Armando
>> > >
>> > > [1] https://review.openstack.org/#/c/351450/
>> > <https://review.openstack.org/#/c/351450/>
>> >
>> > Nothing at this point. devstack-gate bypasses the service defaults
>> in
>> > devstack, so it doesn't impact that at all. Over time we'll want to
>> make
>> > neutron the default choice for all devstack-gate setups, and
>> nova-net to
>> > be the exception. But that actually can all be fully orthoginal to
>> this
>> > change.
>> >
>> >
>> > Ack
>> >
>> >
>> > The experimental results don't quite look in yet, it looks like one
>> test
>> > is failing on dvr (which is the one that tests for cross tenant
>> > connectivity) -
>> > http://logs.openstack.org/50/350750/5/experimental/gate-tem
>> pest-dsvm-neutron-dvr/4958140/
>> > <http://logs.openstack.org/50/350750/5/experimental/gate-
>> tempest-dsvm-neutron-dvr/4958140/>
>> >
>> > That test has been pretty twitchy during this patch series, and it's
>> > quite complex, so figuring out exactly why it's impacted here is a
>> bit
>> > beyond me atm. I think we need to decide if that is going to get
>> deeper
>> > inspection, we live with the fails, or we disable the test for now
>> so we
>> > can move forward and get this out to everyone.
>> >
>> >
>> > Looking at the health trend for DVR [1], the test hasn't failed in a
>> > while, so I wonder if this is induced by the proposed switch, even
>> > though I can't correlate it just yet (still waiting for caffeine to kick
>> > in). Perhaps we can give ourselves today to look into it and pull the
>> > trigger for 351450 <https://review.openstack.org/#/c/351450/> on
>> Monday?
>> >
>> > [1] http://status.openstack.org/openstack-health/#/job/gate-temp
>> est-dsvm-neutron-dvr
>>
>> The only functional difference in the new code that happens in the gate
>> is the iptables rule:
>>
>> local default_dev=""
>> default_dev=$(ip route | grep ^default | awk '{print $5}')
>> sudo iptables -t nat -A POSTROUTING -o $default_dev -s
>> $FLOATING_RANGE -j MASQUERADE
>>
>
I skipped this in [0], to give us further data pointsclasping at straws
still.

[0] https://review.openstack.org/#/c/351876/


>
>> That's the thing to consider. It is the bit that's a little janky, but
>> it was the best idea we had for making things act like we expect
>> otherwise on the single node environment (especially guests being able
>> to egress). It's worth noting, we never seem to test guest egress in the
>> gate (at least not that I could find), so this is something that might
>> just never have been working the way we expected.
>>
>
> Latest run showed that the single node passed the test [1] (though it
> failed on bug [2] for which we have a fix in place [3]). However the
> multi-node failed on the same again [4]. I'll keep on digging...
>
> [1] http://logs.openstack.org/50/350750/5/experimental/gate-
> tempest-dsvm-neutron-dvr/85f8633/logs/testr_results.html.gz
> [2] https://launchpad.net/bugs/1609693
> [3] https://review.openstack.org/#/c/340659/
> [4] http://logs.openstack.org/50/350750/5/experimental/gate-
> tempest-dsvm-neutron-dvr-multinode-full/8d9ac8f/logs/testr_results.html.gz
>
>
>> -Sean
>>
>> --
>> Sean Dague
>> http://dague.net
>>
>> 
>> __
>> 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

Re: [openstack-dev] [all] devstack changing to neutron by default RSN

On 5 August 2016 at 10:21, Sean Dague <s...@dague.net> wrote:

> On 08/05/2016 11:34 AM, Armando M. wrote:
> >
> >
> > On 5 August 2016 at 05:59, Sean Dague <s...@dague.net
> > <mailto:s...@dague.net>> wrote:
> >
> > On 08/04/2016 09:15 PM, Armando M. wrote:
> > > So glad we are finally within the grasp of this!
> > >
> > > I posted [1], just to err on the side of caution and get the
> opportunity
> > > to see how other gate jobs for Neutron might be affected by this
> change.
> > >
> > > Are there any devstack-gate changes lined up too that we should be
> aware of?
> > >
> > > Cheers,
> > > Armando
> > >
> > > [1] https://review.openstack.org/#/c/351450/
> > <https://review.openstack.org/#/c/351450/>
> >
> > Nothing at this point. devstack-gate bypasses the service defaults in
> > devstack, so it doesn't impact that at all. Over time we'll want to
> make
> > neutron the default choice for all devstack-gate setups, and
> nova-net to
> > be the exception. But that actually can all be fully orthoginal to
> this
> > change.
> >
> >
> > Ack
> >
> >
> > The experimental results don't quite look in yet, it looks like one
> test
> > is failing on dvr (which is the one that tests for cross tenant
> > connectivity) -
> > http://logs.openstack.org/50/350750/5/experimental/gate-
> tempest-dsvm-neutron-dvr/4958140/
> > <http://logs.openstack.org/50/350750/5/experimental/gate-
> tempest-dsvm-neutron-dvr/4958140/>
> >
> > That test has been pretty twitchy during this patch series, and it's
> > quite complex, so figuring out exactly why it's impacted here is a
> bit
> > beyond me atm. I think we need to decide if that is going to get
> deeper
> > inspection, we live with the fails, or we disable the test for now
> so we
> > can move forward and get this out to everyone.
> >
> >
> > Looking at the health trend for DVR [1], the test hasn't failed in a
> > while, so I wonder if this is induced by the proposed switch, even
> > though I can't correlate it just yet (still waiting for caffeine to kick
> > in). Perhaps we can give ourselves today to look into it and pull the
> > trigger for 351450 <https://review.openstack.org/#/c/351450/> on Monday?
> >
> > [1] http://status.openstack.org/openstack-health/#/job/gate-
> tempest-dsvm-neutron-dvr
>
> The only functional difference in the new code that happens in the gate
> is the iptables rule:
>
> local default_dev=""
> default_dev=$(ip route | grep ^default | awk '{print $5}')
> sudo iptables -t nat -A POSTROUTING -o $default_dev -s
> $FLOATING_RANGE -j MASQUERADE
>
> That's the thing to consider. It is the bit that's a little janky, but
> it was the best idea we had for making things act like we expect
> otherwise on the single node environment (especially guests being able
> to egress). It's worth noting, we never seem to test guest egress in the
> gate (at least not that I could find), so this is something that might
> just never have been working the way we expected.
>

Latest run showed that the single node passed the test [1] (though it
failed on bug [2] for which we have a fix in place [3]). However the
multi-node failed on the same again [4]. I'll keep on digging...

[1]
http://logs.openstack.org/50/350750/5/experimental/gate-tempest-dsvm-neutron-dvr/85f8633/logs/testr_results.html.gz
[2] https://launchpad.net/bugs/1609693
[3] https://review.openstack.org/#/c/340659/
[4]
http://logs.openstack.org/50/350750/5/experimental/gate-tempest-dsvm-neutron-dvr-multinode-full/8d9ac8f/logs/testr_results.html.gz


> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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] [all] devstack changing to neutron by default RSN

On 5 August 2016 at 07:39, Brian Haley <brian.ha...@hpe.com> wrote:

> On 08/05/2016 08:59 AM, Sean Dague wrote:
>
>> On 08/04/2016 09:15 PM, Armando M. wrote:
>>
>>> So glad we are finally within the grasp of this!
>>>
>>> I posted [1], just to err on the side of caution and get the opportunity
>>> to see how other gate jobs for Neutron might be affected by this change.
>>>
>>> Are there any devstack-gate changes lined up too that we should be aware
>>> of?
>>>
>>> Cheers,
>>> Armando
>>>
>>> [1] https://review.openstack.org/#/c/351450/
>>>
>>
>> Nothing at this point. devstack-gate bypasses the service defaults in
>> devstack, so it doesn't impact that at all. Over time we'll want to make
>> neutron the default choice for all devstack-gate setups, and nova-net to
>> be the exception. But that actually can all be fully orthoginal to this
>> change.
>>
>> The experimental results don't quite look in yet, it looks like one test
>> is failing on dvr (which is the one that tests for cross tenant
>> connectivity) -
>> http://logs.openstack.org/50/350750/5/experimental/gate-temp
>> est-dsvm-neutron-dvr/4958140/
>>
>> That test has been pretty twitchy during this patch series, and it's
>> quite complex, so figuring out exactly why it's impacted here is a bit
>> beyond me atm. I think we need to decide if that is going to get deeper
>> inspection, we live with the fails, or we disable the test for now so we
>> can move forward and get this out to everyone.
>>
>
> I took a quick look at this and can't reproduce it yet, here's what the
> test seems to do:
>
> 1a. Create a network/subnet (10.100.0.0/28)
>  b. attach a router interface to the subnet
>  c. boot VM1 on the network
>
> 2a. Create a network/subnet (10.100.0.16/28)
>  b. do NOT attach a router interface to the subnet
>  c. boot VM2 on the network
>
> 3. Ssh to VM1 and ping VM2 - it should fail since there's no route to the
> network, but it succeeds
>
> The only place you should be able to ping that VM2 IP from is the dhcp
> namespace, which does work for me.
>
> So if you are seeing it be flaky it could the VM placement (same host vs
> different host) is impacting it?  In the logs it showed the same hostId,
> but so did my test, so I don't have a good answer.


Test *test_connectivity_between_vms_on_different_networks*  failed on
single node twice in a row. I think that VM placement may have nothing to
do with it.


>
>
> -Brian
>
>
> __
> 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] [all] devstack changing to neutron by default RSN

On 5 August 2016 at 05:59, Sean Dague <s...@dague.net> wrote:

> On 08/04/2016 09:15 PM, Armando M. wrote:
> > So glad we are finally within the grasp of this!
> >
> > I posted [1], just to err on the side of caution and get the opportunity
> > to see how other gate jobs for Neutron might be affected by this change.
> >
> > Are there any devstack-gate changes lined up too that we should be aware
> of?
> >
> > Cheers,
> > Armando
> >
> > [1] https://review.openstack.org/#/c/351450/
>
> Nothing at this point. devstack-gate bypasses the service defaults in
> devstack, so it doesn't impact that at all. Over time we'll want to make
> neutron the default choice for all devstack-gate setups, and nova-net to
> be the exception. But that actually can all be fully orthoginal to this
> change.
>
>
Ack


> The experimental results don't quite look in yet, it looks like one test
> is failing on dvr (which is the one that tests for cross tenant
> connectivity) -
> http://logs.openstack.org/50/350750/5/experimental/gate-
> tempest-dsvm-neutron-dvr/4958140/
>
> That test has been pretty twitchy during this patch series, and it's
> quite complex, so figuring out exactly why it's impacted here is a bit
> beyond me atm. I think we need to decide if that is going to get deeper
> inspection, we live with the fails, or we disable the test for now so we
> can move forward and get this out to everyone.
>
>
Looking at the health trend for DVR [1], the test hasn't failed in a while,
so I wonder if this is induced by the proposed switch, even though I can't
correlate it just yet (still waiting for caffeine to kick in). Perhaps we
can give ourselves today to look into it and pull the trigger for 351450
<https://review.openstack.org/#/c/351450/> on Monday?

[1]
http://status.openstack.org/openstack-health/#/job/gate-tempest-dsvm-neutron-dvr


> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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] [all] devstack changing to neutron by default RSN

On 4 August 2016 at 11:35, Sean Dague  wrote:

> One of the cycle goals in newton was to get devstack over to neutron by
> default. Neutron is used by 90+% of our users, and nova network is
> deprecated, and is not long for this world.
>
> Because devstack is used by developers as well as by out test
> infrastructure, the major stumbling block was coming up with a good
> working default on a machine with only 1 interface, that doesn't leave
> that interface in a totally broken state if you reboot the box (noting
> that ovs changes are persistent by default, but brctl ones are not).
>
> We think we've come up with a model that works. It's here -
> https://review.openstack.org/#/c/350750/. And while it's surprisingly
> short, it took a lot of thinking this one through to get there.
>
> The crux of it is that we trust the value of PUBLIC_INTERFACE in a new
> way on the neutron side. It is now unset by default (logic was changed
> in n-net to keep things right there), and if set, then we assume you
> really want neutron to manage this physical interface.
>
> If not, that's cool. We're automatically creating a bridge interface
> (with no physical interfaces in it) and managing that. For single node
> testing this works fine. It passes all the tempest tests[1]. The only
> thing that's really weird in this setup is that because there is no
> physical interface in that bridge, there is no path to the outside world
> from guests. That means no package updates on them.
>
> We address that with an iptables masq rule. It's a little cheaty pants,
> however of the options we've got, it didn't seem so bad. (Note: if you
> have a better option and are willing to get knee deep in solving it,
> please do so. More contributors the better.)
>
> It's going to take a bit for docs to all roll over here, but I think we
> actually want this out sooner rather than later to find any other edge
> cases that it introduces. There will be some bumpiness here. However,
> being able to bring up a full neutron with only the 4 passwords
> specified in config is quite nice.
>
> 1. actually 5 tests fail for unrelated reasons, which is that tempest
> isn't probably excluding tests for services that aren't running because
> it makes some assumptions on the gate config. That will be fixed soon.
>
> -Sean
>
>
So glad we are finally within the grasp of this!

I posted [1], just to err on the side of caution and get the opportunity to
see how other gate jobs for Neutron might be affected by this change.

Are there any devstack-gate changes lined up too that we should be aware of?

Cheers,
Armando

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


> --
> Sean Dague
> http://dague.net
>
>
> __
> 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/liberty busted

On 4 August 2016 at 11:45, Brian Haley <brian.ha...@hpe.com> wrote:

> On 08/04/2016 01:36 PM, Armando M. wrote:
>
>> Hi Neutrinos,
>>
>> I have noticed that Liberty seems to be belly up [1]. I wonder if anyone
>> knows
>> anything or has the time to look into it.
>>
>> Many thanks,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/349039/
>>
>
> This could be due to this backport;
>
> https://review.openstack.org/#/c/347062/
>
> Before we were doing 'ping -c 3 -W 1 $IP', which will succeed as long as
> one packet is returned.
>
> Now there is an outer loop that runs 'ping -c 1 -W 1 $IP', so a single
> dropped packet could cause an error.  Since sometimes that first packet
> causes ARP to happen, any delay near the 1-second mark looks like a lost
> packet, but is really just transient and packets 2 and 3 are fine.
>
> I've started a revert and will recheck, but if I'm right an async issue
> like this is hard to reliably reproduce - I had to use iptables directly to
> test my theory about the return code from ping when 1/3 packets were lost.
>
> Thanks Brian,

I'll eagerly await results!


> -Brian
>
> __
> 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] stable/liberty busted

Hi Neutrinos,

I have noticed that Liberty seems to be belly up [1]. I wonder if anyone
knows anything or has the time to look into it.

Many thanks,
Armando

[1] https://review.openstack.org/#/c/349039/
__
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 - switching gear

Folks,

As some of you may be familiar with, the typical agenda for the drivers
meeting [1] involves the members of the drivers team going over triaged
RFEs. Prior to the meeting we typically process confirmed and new RFEs to
see whether some of them are worth triaging (i.e. discussed during the
weekly meeting).

The confirmed and new pipelines are pretty dry [2,3] at the moment, and the
triaged one [4] is pretty stable. For this reason I would like to switch
gear and take the drivers meeting as an opportunity to go over the Newton
backlog [5]. This means that from now until Ocata opens up we will give
priority to reviewing blueprint statuses, and other high visibility
Stadium-wide efforts like neutron-lib.

Cheers,
Armando

[1] https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
[2]
https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Confirmed=rfe
[3]
https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=New=rfe
[4]
https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged=rfe
[5] https://blueprints.launchpad.net/neutron/newton/+assignments
__
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] Can we recheck mindfully?

2016-08-03 Thread Armando M.

Folks,

I have been noticing that some of us use 'recheck' as a knee jerk reaction.
Please STOP!

Please, take the time to look into the failure mode, see if there's a bug
reported already, help the triage process, and ultimately, once you're sure
that the issue is not introduced by your patch, consider to type 'recheck
bug #' mindfully. If the gate queue is hovering over at 400 jobs [0],
we need to be conscious of the fact that the gate is busy and we should
back off.

Besides, there is no point in jamming stuff through the gate if there's a
burning issue that needs to be flushed out.

For checking gate instabilities, tools [1,2,3] are your friends. If you
don't know how to use them, please reach out to me and I'll be happy to
walk you through.

Cheers,
Armando

[0] http://status.openstack.org/zuul/
[1] http://grafana.openstack.org/dashboard/db/neutron-failure-rate
[2]
http://status.openstack.org/openstack-health/#/g/project/openstack~2Fneutron
[3] http://status.openstack.org/elastic-recheck/
__
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] Mid-cycle agenda

2016-07-30 Thread Armando M.

Neutrinos,

For those of you who are going to attend the Neutron mid-cycle [1] in
person or be engaged on IRC, please refer to [2] for a list of topics we
should give some attention and priority during our time in Cork.

The list of topics is already pretty packed, however if you would like to
include some other topic please reach out to me and we will find a
place/time for it.

As usual we'll report back on the ML on the progress made and following
steps ahead of Feature Freeze.

Many thanks,
Armando

[1] https://etherpad.openstack.org/p/newton-neutron-midcycle
[2] https://etherpad.openstack.org/p/newton-neutron-midcycle-workitems
__
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] Project mascot - propose your choice/cast your vote

2016-07-27 Thread Armando M.

On 27 July 2016 at 12:13, Armando M. <arma...@gmail.com> wrote:

>
>
> On 25 July 2016 at 10:52, Armando M. <arma...@gmail.com> wrote:
>
>> On 14 July 2016 at 10:00, Armando M. <arma...@gmail.com> wrote:
>>
>>> Hi Neutrinos,
>>>
>>> Based on proposal [1], I prepared an etherpad to allow us to choose
>>> collaboratively a set of candidates for our mascot. Propose/vote away on
>>> [2]. You have time until Friday, July 22nd.
>>>
>>
>> The deadline has passed, we have now a list of selected candidates to
>> choose from.
>>
>> Please cast your vote [1]!
>>
>> Cheers,
>> Armando
>>
>> [1]
>> https://docs.google.com/forms/d/e/1FAIpQLSevnzF9z4a9jiXy8w8MRvvmXVmexK5QCxphOoFaOhBuaj9INw/viewform?c=0=1=mail_form_link
>>
>
>
> Today is the deadline to submit mascot candidates for priority
> consideration to Heidi Joy @Foundation. If you have not voted so far and
> would like to, please do. I will close the poll [2] by the EOB (PST
> timezone), and submit the outcome of the poll later in the day.
>

Time has passed, this is the outcome of the poll:

Spider web 18 25%
Cheetah 7 9.7%
Yak 12 16.7%
Sloth 8 11.1%
Eel 2 2.8%
Banyan Tree 15 20.8%
Pigeon 10 13.9%











I suppose we're going with a spider web. Thanks for everyone who voted.

I will let you know once I have final confirmation from the foundation that
the mascot is available.

Cheers,
Armando


> [1] http://www.openstack.org/project-mascots
> <http://www.openstack.org/project-mascots>
> [2]
> https://docs.google.com/forms/d/e/1FAIpQLSevnzF9z4a9jiXy8w8MRvvmXVmexK5QCxphOoFaOhBuaj9INw/viewform?c=0=1=mail_form_link
>
>
>>
>>
>>>
>>> After the deadline the most voted ones (depending on the number) will be
>>> sent to Heidi Joy @Foundation for the next step in the selection process.
>>>
>>> Feel free to reach out if you have any questions/suggestions.
>>>
>>> Happy hacking!
>>> Armando
>>>
>>> [1] http://www.openstack.org/project-mascots
>>> [2] https://etherpad.openstack.org/p/neutron-project-mascot
>>>
>>
>> Today was the deadline for
>>
>>
>
__
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] Project mascot - propose your choice/cast your vote

2016-07-27 Thread Armando M.

On 25 July 2016 at 10:52, Armando M. <arma...@gmail.com> wrote:

> On 14 July 2016 at 10:00, Armando M. <arma...@gmail.com> wrote:
>
>> Hi Neutrinos,
>>
>> Based on proposal [1], I prepared an etherpad to allow us to choose
>> collaboratively a set of candidates for our mascot. Propose/vote away on
>> [2]. You have time until Friday, July 22nd.
>>
>
> The deadline has passed, we have now a list of selected candidates to
> choose from.
>
> Please cast your vote [1]!
>
> Cheers,
> Armando
>
> [1]
> https://docs.google.com/forms/d/e/1FAIpQLSevnzF9z4a9jiXy8w8MRvvmXVmexK5QCxphOoFaOhBuaj9INw/viewform?c=0=1=mail_form_link
>


Today is the deadline to submit mascot candidates for priority
consideration to Heidi Joy @Foundation. If you have not voted so far and
would like to, please do. I will close the poll [2] by the EOB (PST
timezone), and submit the outcome of the poll later in the day.

Cheers,
Armando

[1] http://www.openstack.org/project-mascots
<http://www.openstack.org/project-mascots>
[2]
https://docs.google.com/forms/d/e/1FAIpQLSevnzF9z4a9jiXy8w8MRvvmXVmexK5QCxphOoFaOhBuaj9INw/viewform?c=0=1=mail_form_link


>
>
>>
>> After the deadline the most voted ones (depending on the number) will be
>> sent to Heidi Joy @Foundation for the next step in the selection process.
>>
>> Feel free to reach out if you have any questions/suggestions.
>>
>> Happy hacking!
>> Armando
>>
>> [1] http://www.openstack.org/project-mascots
>> [2] https://etherpad.openstack.org/p/neutron-project-mascot
>>
>
> Today was the deadline for
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][networking-l2gw] Python 3 support

2016-07-26 Thread Armando M.

On 25 July 2016 at 04:13, Gary Kotton  wrote:

> Hi,
>
> This morning I discovered that the project does not have python 3 support.
> This was due to the fact that it broke the vmware-nsx unit tests.
>
> I have started to kick the wheels with the python 3 support:
>
> 1.   Project infra - https://review.openstack.org/346701 (currently
> non-voting)
>
> 2.   L2 gw:
>
> a.   https://review.openstack.org/#/c/346638/ - this is currently
> blocking all decomposed plugins invoking l2-gw unit tests
>
> b.   https://review.openstack.org/#/c/346658/
>
> c.   https://review.openstack.org/#/c/346697/
>
> If anyone else would like to jump in and help then please let me know.
> Hopefully we can get this done in a couple of days.
>

Thanks for doing this. Another parallel effort Henry et al. are
spearheading is elevating the bar as far as DB migrations and functional
testing go, in preparation of effort [1] and consolidation effort [2].

[1] https://etherpad.openstack.org/p/neutron-stadium-tenant2project
[2] https://review.openstack.org/#/c/335739/

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

Re: [openstack-dev] [Neutron] Project mascot - propose your choice/cast your vote

2016-07-25 Thread Armando M.

On 14 July 2016 at 10:00, Armando M. <arma...@gmail.com> wrote:

> Hi Neutrinos,
>
> Based on proposal [1], I prepared an etherpad to allow us to choose
> collaboratively a set of candidates for our mascot. Propose/vote away on
> [2]. You have time until Friday, July 22nd.
>

The deadline has passed, we have now a list of selected candidates to
choose from.

Please cast your vote [1]!

Cheers,
Armando

[1]
https://docs.google.com/forms/d/e/1FAIpQLSevnzF9z4a9jiXy8w8MRvvmXVmexK5QCxphOoFaOhBuaj9INw/viewform?c=0=1=mail_form_link


>
> After the deadline the most voted ones (depending on the number) will be
> sent to Heidi Joy @Foundation for the next step in the selection process.
>
> Feel free to reach out if you have any questions/suggestions.
>
> Happy hacking!
> Armando
>
> [1] http://www.openstack.org/project-mascots
> [2] https://etherpad.openstack.org/p/neutron-project-mascot
>

Today was the deadline for
__
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] place of subport details in the API

2016-07-21 Thread Armando M.

On 21 July 2016 at 04:56, Bence Romsics  wrote:

> Hi,
>
> Looking at all the trunk port patches nicely coming along I was
> wondering where do we want to see all the subport details in the API?
>
> In the spec a trunk object does not have a 'sub_ports' attribute:
>
>
> http://specs.openstack.org/openstack/neutron-specs/specs/newton/vlan-aware-vms.html#rest-api-impact


This was added so that you can create trunk with sub_ports at once and
avoid two API calls.


>
>
> Instead subports can be added/removed/queried via extra resource actions
> like:
>

This is not either/or, you can do both: create a trunk just with a parent
port and add sub_ports at a later date, or do both at once.


>
> PUT /v2.0/trunks/$trunk_id/add_subports
> PUT /v2.0/trunks/$trunk_id/remove_subports
> GET /v2.0/trunks/$trunk_id/get_subports
>
> IIRC the reasoning was to give control to the API user if/when he
> wants to see the subport details, because that may be huge (for up to
> 4k subports).
>

Payloads at scale can be big, have you ever tried to list a network with a
gazillion subnets?


>
> The current patches mostly go the other way, having a sub_ports
> attribute on the trunk. Consistent with that
> /v2.0/trunks/$trunk_id/get_subports is not implemented.
>
>
I don't think so, I think the rationale is to make the API less chatty than
it needs to be. The spec was particularly lax about this, and it did not
prescribe any behavior so I would not state that we went the other way.


> So which way do we want this?


I think the way it is now is what we want.


> If we stick to the currently implemented approach I guess we can drop
> the get_subports action, right?
>

The get_subports may seem redundant, but I'd avoid an overly aggressive
optimization at this point. The CLI can nicely show the ports in tabular
form when invoked.


>
> Cheers,
> Bence Romsics
>
> __
> 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][api] networking API reference clean up sprint

2016-07-19 Thread Armando M.

On 19 July 2016 at 06:49, Akihiro Motoki  wrote:

> Hi Neutron folks,
>
> As you may know, the OpenStack API references have been moved into
> individual project repositories.
> For the networking API, we have the api-ref document in neutron-lib
> repository.
> The api-ref document imported into neutron-lib repository needs to be
> cleaned up.
>
> I would like to plan a virtual sprint to clean up the networking API
> reference.
> I setup a etherpad for the sprint to share the guideline.
> (most are borrowed from nova api-ref sprint wiki)
>
> https://etherpad.openstack.org/p/neutron-api-ref-sprint
>
> I haven't set a specific period for the virtual sprint, but I would
> like to complete the sprint by Newton-3 milestone.
>

Akihiro,

Thanks for leading this effort.

With the Neutron mid-cycle approaching I think we should also take some
time to go over this aspect. I'll be sending out a draft of the mid-cycle
agenda later this week.

Cheers,
Armando


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

[openstack-dev] [Neutron] Project mascot - propose your choice/cast your vote

2016-07-14 Thread Armando M.

Hi Neutrinos,

Based on proposal [1], I prepared an etherpad to allow us to choose
collaboratively a set of candidates for our mascot. Propose/vote away on
[2]. You have time until Friday, July 22nd.

After the deadline the most voted ones (depending on the number) will be
sent to Heidi Joy @Foundation for the next step in the selection process.

Feel free to reach out if you have any questions/suggestions.

Happy hacking!
Armando

[1] http://www.openstack.org/project-mascots
[2] https://etherpad.openstack.org/p/neutron-project-mascot
__
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] MultiTenant support for VLAN-Aware-VM

2016-07-13 Thread Armando M.

On 13 July 2016 at 16:51, Kevin Benton <ke...@benton.pub> wrote:

> Sub ports are just regular ports from a logical model perspective, right?
> If so, there should be no problem attaching the port to a shared network or
> RBAC granted network.
>

True, but I don't believe it until I test it :)

On Jul 13, 2016 7:15 PM, "Armando M." <arma...@gmail.com> wrote:
>
>>
>>
>> On 13 July 2016 at 15:32, Cathy Zhang <cathy.h.zh...@huawei.com> wrote:
>>
>>> Hi Everyone,
>>>
>>> We have been discussing on multi-tenant VNF for service chain on the OVN
>>> mailing alias.
>>> We are thinking about leveraging the vlan-aware-VM for supporting this.
>>>
>>> AFAIK, with current nova, we cannot create a multi-tenant  VNF.
>>> Currently, nova checks whether the neutron port belongs to the same
>>> tenant as the VM itself.
>>> You attach a network interface (neutron port) to a VM using nova
>>> interface-attach, if the port and the VM are in different tenants, an error
>>> is given.
>>>
>>> With the introduction of the trunk-port/sub-port feature of Neutron, the
>>> sub-ports of a VM are allowed to associate with different networks. But it
>>> seems these networks need to all belong to the same tenant if we read the
>>> vlan-aware-vm spec correctly (
>>> http://specs.openstack.org/openstack/neutron-specs/specs/newton/vlan-aware-vms.html
>>> ).
>>>
>>> Is our understanding correct? Does it work properly if these networks
>>> belong to different tenants?
>>>
>>
>> At the moment this area is still WIP, but we're focusing on the single
>> tenant use case. RBAC may help us down the road to address what you need,
>> but it's premature to speculate on how the implementation looks like.
>>
>> Cheers,
>> Armando
>>
>>
>>>
>>> Thanks,
>>> Cathy
>>>
>>> -Original Message-
>>> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Farhad
>>> Sunavala
>>> Sent: Tuesday, July 12, 2016 7:59 PM
>>> To: d...@openvswitch.org
>>> Subject: Re: [ovs-dev] SFC-Summary: MultiTenant
>>>
>>> >I was thinking this could be handled with child / sub-ports.  We do
>>> >this today for containers in VMs.  We can have a single VIF for a VM
>>> >that is connected to multiple networks that are owned by separate
>>> >tenants.  Some sort of encapsulation (VLAN ID, MPLS header, whatever)
>>> >would be used to differentiate the traffic for each networking in/out
>>> >of that VIF.  I had started adding the ability to use MPLS for this in
>>> >my prototype for this reason, as that was what networking-sfc had
>>> defined.
>>> I have a quick question on the above. (multi-tenancy).Yes, I know the
>>> containers can be in different networks of the same tenant.How does it work
>>> when the containers are in different tenants ?
>>> Below is the latest spec for vlan-aware-vms
>>> https://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html
>>>
>>> The trick is to create neutron ports (for the subports) and then link
>>> them to the trunk port using neutron trunk-subport-add TRUNK \
>>>  PORT[,SEGMENTATION-TYPE,SEGMENTATION-ID] \   [PORT,...]
>>>
>>> In the above command all the neutron ports (trunk  ports and subports)
>>> must be in the same tenant.As far as I know, a tenant will not see neutron
>>> ports from another tenant.Or will this command allow neutron ports from
>>> different tenants to be attached ?
>>> E.g.  VM "X" consists of containers C1 in Tenant 1 with portID = C1
>>> (network dn1)container C2 in Tenant 2 with portID = C2 (network dn2)The
>>> trunk port of VM "X" is in tenant 100 with portID = T1 (network dt) The
>>> above command will be neutron trunk-subport-add T1 \   A  vlan 1 \
>>>  B vlan 2 Is my understanding correct? thanks,Farhad.
>>> ___
>>> dev mailing list
>>> d...@openvswitch.org
>>> http://openvswitch.org/mailman/listinfo/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] MultiTenant support for VLAN-Aware-VM

2016-07-13 Thread Armando M.

On 13 July 2016 at 15:32, Cathy Zhang  wrote:

> Hi Everyone,
>
> We have been discussing on multi-tenant VNF for service chain on the OVN
> mailing alias.
> We are thinking about leveraging the vlan-aware-VM for supporting this.
>
> AFAIK, with current nova, we cannot create a multi-tenant  VNF.
> Currently, nova checks whether the neutron port belongs to the same tenant
> as the VM itself.
> You attach a network interface (neutron port) to a VM using nova
> interface-attach, if the port and the VM are in different tenants, an error
> is given.
>
> With the introduction of the trunk-port/sub-port feature of Neutron, the
> sub-ports of a VM are allowed to associate with different networks. But it
> seems these networks need to all belong to the same tenant if we read the
> vlan-aware-vm spec correctly (
> http://specs.openstack.org/openstack/neutron-specs/specs/newton/vlan-aware-vms.html
> ).
>
> Is our understanding correct? Does it work properly if these networks
> belong to different tenants?
>

At the moment this area is still WIP, but we're focusing on the single
tenant use case. RBAC may help us down the road to address what you need,
but it's premature to speculate on how the implementation looks like.

Cheers,
Armando


>
> Thanks,
> Cathy
>
> -Original Message-
> From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Farhad
> Sunavala
> Sent: Tuesday, July 12, 2016 7:59 PM
> To: d...@openvswitch.org
> Subject: Re: [ovs-dev] SFC-Summary: MultiTenant
>
> >I was thinking this could be handled with child / sub-ports.  We do
> >this today for containers in VMs.  We can have a single VIF for a VM
> >that is connected to multiple networks that are owned by separate
> >tenants.  Some sort of encapsulation (VLAN ID, MPLS header, whatever)
> >would be used to differentiate the traffic for each networking in/out
> >of that VIF.  I had started adding the ability to use MPLS for this in
> >my prototype for this reason, as that was what networking-sfc had defined.
> I have a quick question on the above. (multi-tenancy).Yes, I know the
> containers can be in different networks of the same tenant.How does it work
> when the containers are in different tenants ?
> Below is the latest spec for vlan-aware-vms
> https://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html
>
> The trick is to create neutron ports (for the subports) and then link them
> to the trunk port using neutron trunk-subport-add TRUNK \
>  PORT[,SEGMENTATION-TYPE,SEGMENTATION-ID] \   [PORT,...]
>
> In the above command all the neutron ports (trunk  ports and subports)
> must be in the same tenant.As far as I know, a tenant will not see neutron
> ports from another tenant.Or will this command allow neutron ports from
> different tenants to be attached ?
> E.g.  VM "X" consists of containers C1 in Tenant 1 with portID = C1
> (network dn1)container C2 in Tenant 2 with portID = C2 (network dn2)The
> trunk port of VM "X" is in tenant 100 with portID = T1 (network dt) The
> above command will be neutron trunk-subport-add T1 \   A  vlan 1 \
>  B vlan 2 Is my understanding correct? thanks,Farhad.
> ___
> dev mailing list
> d...@openvswitch.org
> http://openvswitch.org/mailman/listinfo/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][infra] Switch to xenial and Neutron unit tests

2016-07-12 Thread Armando M.

 Hi Neutrinos,

OpenStack infra is in the process of testing OpenStack tests on ubuntu
Xenial so that it can be adopted as default platform for testing in the
Gate. It is likely that the switch is going to happen sometime next week.

It was noted in the channel at [1] that some unit tests are not currently
passing for the following repos: vmware-nsx, networking-cisco and
group-based-policy.

For those of you who may be affected, please make sure to read IRC logs and
stay on top of this issue.

Cheers,
Armando

[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2016-07-12.log.html#t2016-07-12T21:39:32
__
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 and Stadium evolution

2016-07-08 Thread Armando M.

On 8 July 2016 at 08:22, Neil Jerram <n...@tigera.io> wrote:

> Hi Armando,
>
> Who exactly are you addressing here?  AFAICS, [1] on its own doesn't give
> me (or anyone) any new rights for neutron-lib changes.  It appears to be
> preparatory to a planned expansion of neutron-lib-core - but looking at
> [5], the membership doesn't include me, or folk from many stadium
> projects.  So, did I misunderstand who this thread is addressed to?  Or is
> the planned expansion still to happen?
>
> Thanks,
> Neil
>
>
> [5] https://review.openstack.org/#/admin/groups/1187,members
>

Right now this is limited to the core maintainers of repos that spun out of
Neutron. We'll extend rights to other teams over time as soon as we
complete the Stadium transition plan.


>
> On Wed, Jun 29, 2016 at 8:07 PM Armando M. <arma...@gmail.com> wrote:
>
>> Hi Neutrinos,
>>
>> As some of you may have noticed, since the merge of [1] you have now +2
>> rights on neutron-lib changes. Please make yourself familiar with review
>> guidelines [2]: in general, code that targets the library should go through
>> a much greater level of scrutiny and should be targeted if and only if it
>> serves the purpose of reuse across the Stadium, and the decoupling of
>> Neutron from its consumer projects.
>>
>> Please, also bear in mind that since [3] is in effect, I'll be working
>> over the next few days to implement some of the steps outlined in the plan,
>> and that involves consolidating APIs and move them over to neutron-lib.
>> Akihiro started the effort of moving the API documentation [4] over
>> neutron-lib, and we'll continue towards the consolidation effort.
>>
>> Please become more involved, and consider neutron-lib as one of the
>> projects you take the time of reviewing on a day to day basis.
>>
>> Cheers,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/335250/
>> [2]
>> http://docs.openstack.org/developer/neutron-lib/review-guidelines.html
>> [3]
>> http://specs.openstack.org/openstack/neutron-specs/specs/newton/neutron-stadium.html
>> [4] http://developer.openstack.org/api-ref/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 Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova] Deprecated Configuration Option in Nova Mitaka Release

2016-07-01 Thread Armando M.

On 30 June 2016 at 10:55, HU, BIN  wrote:

> I see, and thank you very much Dan. Also thank you Markus for unreleased
> release notes.
>
> Now I understand that it is not a plugin and unstable interface. And there
> is a new "use_neutron" option for configuring Nova to use Neutron as its
> network backend.
>
> When we use Neutron, there are ML2 and ML3 plugins so that we can choose
> to use different backend providers to actually perform those network
> functions. For example, integration with ODL.
>

There's no such a thing as ML3, not yet anyway and not in the same shape of
ML2.


>
> Shall we foresee a situation, where user can choose another network
> backend directly, e.g. ODL, ONOS? Under this circumstance, a stable plugin
> interface seems needed which can provide end users with more options and
> flexibility in deployment.
>

The networking landscape is dramatically different from the one Nova
experiences and even though I personally share the same ideals and desire
to strive for interoperability across OpenStack clouds, the Neutron team is
generally more open to providing extensibility and integration points. One
of these integration points we currently have is the ML2 interface, which
is considered stable and to be used by third parties.

Bear in mind that we are trying to strike a better balance between wild
wild west and tight control, so my suggestion would be to stay plugged with
the Neutron community to get a sense on how things evolve over time. That
should help avoiding surprises where you end up realizing that something
you relied on was indeed taken away from you.


> What do you think?
>


daada

>
> Thanks
> Bin
>
> -Original Message-
> From: Dan Smith [mailto:d...@danplanet.com]
> Sent: Thursday, June 30, 2016 10:30 AM
> To: OpenStack Development Mailing List (not for usage questions) <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Nova] Deprecated Configuration Option in
> Nova Mitaka Release
>
> > Just curious - what is the motivation of removing the plug-ability
> > entirely? Because of significant maintenance effort?
>
> It's not a plugin interface and has never been stable. We've had a
> long-running goal of removing all of these plug points where we don't
> actually expect people to write stable plugins.
>
> If you want to write against an unstable internal-only API and chase every
> little change we make to it, then just patch the code locally.
> Using these plug points is effectively the same thing.
>
> --Dan
>
> __
> 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] Neutron-lib and Stadium evolution

2016-06-29 Thread Armando M.

Hi Neutrinos,

As some of you may have noticed, since the merge of [1] you have now +2
rights on neutron-lib changes. Please make yourself familiar with review
guidelines [2]: in general, code that targets the library should go through
a much greater level of scrutiny and should be targeted if and only if it
serves the purpose of reuse across the Stadium, and the decoupling of
Neutron from its consumer projects.

Please, also bear in mind that since [3] is in effect, I'll be working over
the next few days to implement some of the steps outlined in the plan, and
that involves consolidating APIs and move them over to neutron-lib. Akihiro
started the effort of moving the API documentation [4] over neutron-lib,
and we'll continue towards the consolidation effort.

Please become more involved, and consider neutron-lib as one of the
projects you take the time of reviewing on a day to day basis.

Cheers,
Armando

[1] https://review.openstack.org/#/c/335250/
[2] http://docs.openstack.org/developer/neutron-lib/review-guidelines.html
[3]
http://specs.openstack.org/openstack/neutron-specs/specs/newton/neutron-stadium.html
[4] http://developer.openstack.org/api-ref/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] Deprecation and release notes

Hi Neutrinos,

I would like to remind you to be extra careful when handling the
deprecation of config options.

Do not forget to associate release notes when appropriate, or even bug
reports tagged with 'deprecation' to track the deprecation cycle. Alerting
operators/deployers/packagers of impeding changes to their configuration
files makes us more friendly to our users.

I have seen instances of neglects [1,2] on this front.

Many thanks,
Armando

[1] https://review.openstack.org/#/c/330273/
[2] https://review.openstack.org/#/c/332018/
__
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] Intermittent failures on unit tests

On 21 June 2016 at 08:41, Armando M. <arma...@gmail.com> wrote:

> Neutrinos,
>
> There's been a number of intermittent failures induced by the DNS
> integration code that popped up lately. One has been reported in [1],
> another showed up in [2]. I am in the progress of digging deeper to see
> what's going on, but if someone knows or working on the issue, please let
> us know.
>
> Also, please do not recheck blindly hoping the issue goes away.
>

I spoke with Ihar on IRC and it turns out it may (or may not be) that the
issue related to [2] is induced by change [3] or even [4], see [5] for more
details.

Cheers,
Armando


> Thanks,
> Armando
>
> [1] https://bugs.launchpad.net/neutron/+bug/1593647
> [2] https://bugs.launchpad.net/neutron/+bug/1594796
>

[3] https://review.openstack.org/#/c/327413/
[4] https://review.openstack.org/#/c/330273/
[5] http://paste.openstack.org/show/520931/
__
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] Intermittent failures on unit tests

Neutrinos,

There's been a number of intermittent failures induced by the DNS
integration code that popped up lately. One has been reported in [1],
another showed up in [2]. I am in the progress of digging deeper to see
what's going on, but if someone knows or working on the issue, please let
us know.

Also, please do not recheck blindly hoping the issue goes away.

Thanks,
Armando

[1] https://bugs.launchpad.net/neutron/+bug/1593647
[2] https://bugs.launchpad.net/neutron/+bug/1594796
__
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] Elevating context to remove subnets created by admin