Re: [openstack-dev] [grenade] future direction on partial upgrade support

[Armando M.]

Thanks Sean, comments inline.

On 6 July 2015 at 16:58, Sean M. Collins  wrote:

> I'd also like to chime in - we've had some discussions on -infra today
> about the partial upgrade issue, and collected the following notes on an
> etherpad.
>
> https://etherpad.openstack.org/p/neutron-partial-upgrades
>
> One of the things identified, was the complexity of the DVR feature in
> Neutron, and an attempt to simplify the partial upgrade job by not
> enabling the DVR feature.
>

The DVR issue is entirely orthogonal to this, but I am willing to play
along.


>
>
> http://eavesdrop.openstack.org/meetings/networking/2015/networking.2015-07-06-21.00.log.html
>
> Clark Boylan has proposed a patch to create a new job that runs on
> multiple nodes, but does not have DVR enabled, in the hopes that having
> less moving parts will allow the multinode grenade work to continue on a
> parallel track,


Who is leading the Grenade effort? Is it Clark?


> with bugfixes or additional work on the Neutron DVR
> feature not blocking the overall effort. The idea would be eventually to
> enable DVR, once we have taken care of all the other work that needs to
> be done.
>
> https://review.openstack.org/#/c/198906/


I thought that's what Joe did in [1]. Am I barking up at the wrong tree?


>
>
> What is everyone's thoughts?
>

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


>
> --
> 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] [neutron] Breakage by commit 18bc67d56faef30a0f73429a5ee580e052858cb5

[Armando M.]

Hi Paul,

Let me look into it.

Thanks,
Armando

On 7 July 2015 at 08:51, Paul Michali  wrote:

> I'm seeing that neutron-vpn repo py27 tests are now failing. Did a git
> bisect in Neutron and found that this commit is causing the failure (not
> sure what's broken).
>
> commit 18bc67d56faef30a0f73429a5ee580e052858cb5
> Author: armando-migliaccio 
> Date:   Thu Jul 2 12:56:24 2015 -0700
>
> COMMON_PREFIXES cleanup - patch 5/5
>
> Get rid of COMMON_PREFIXES, as now the prefix is a service's
> declaritive property.
>
> Change-Id: I3d306131df94188f75e69edb13d262721d10bee5
> Depends-on: I0450d0b2bf409d470a3a87bfd96518939759a84e
> Depends-on: Ia34695967cbbec0a1cf0884dad82e096de8539b8
> Depends-on: Ib9517b772fe426eaf0809c439aa3ba0448c7abaa
>
>
>
> Here is the bisect log:
>
> # bad: [8b6d13012622d161774b701f3600ee401d63e5ba] Merge
> "portsecurity_db_common: Access db columns in a consistent way"
> git bisect bad 8b6d13012622d161774b701f3600ee401d63e5ba
> # good: [49774afdc111d65cd8c9e73c1c1dee04d9c9f1a8] Merge "Read vif port
> information in bulk"
> git bisect good 49774afdc111d65cd8c9e73c1c1dee04d9c9f1a8
> # good: [e9c4b6d974694e89d4a3bdefd33aea7445387490] Merge "Fall back on
> empty path if prefix is missing"
> git bisect good e9c4b6d974694e89d4a3bdefd33aea7445387490
> # good: [211c0355778c1aef0dd4a44553f604b4fa3f72b3] Merge "Add policy files
> specific to NSX plugins"
> git bisect good 211c0355778c1aef0dd4a44553f604b4fa3f72b3
> # good: [d845c6cdbd1d6d3c5800467cb8de74ac10c059de] Merge "Refactor
> IpRuleCommand to take more arguments"
> git bisect good d845c6cdbd1d6d3c5800467cb8de74ac10c059de
> # good: [26c81334988b3de567964b863e75d9d48532b25e] Merge "Devref for
> out-of-tree plugin/driver contribution"
> git bisect good 26c81334988b3de567964b863e75d9d48532b25e
> # bad: [678ddf4f18f6f3eca7ab2ce13cb4a8fdd655e0d5] Merge "COMMON_PREFIXES
> cleanup - patch 5/5"
> git bisect bad 678ddf4f18f6f3eca7ab2ce13cb4a8fdd655e0d5
> # bad: [18bc67d56faef30a0f73429a5ee580e052858cb5] COMMON_PREFIXES cleanup
> - patch 5/5
> git bisect bad 18bc67d56faef30a0f73429a5ee580e052858cb5
> # first bad commit: [18bc67d56faef30a0f73429a5ee580e052858cb5]
> COMMON_PREFIXES cleanup - patch 5/5
>
> __
> OpenStack Development Mailing 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] Breakage by commit 18bc67d56faef30a0f73429a5ee580e052858cb5

[Armando M.]

Filed [1], I think this affected more than just vpn. Fix coming shortly.

Sorry, I thought I had taken the necessary measures :)

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

On 7 July 2015 at 09:11, Armando M.  wrote:

> Hi Paul,
>
> Let me look into it.
>
> Thanks,
> Armando
>
> On 7 July 2015 at 08:51, Paul Michali  wrote:
>
>> I'm seeing that neutron-vpn repo py27 tests are now failing. Did a git
>> bisect in Neutron and found that this commit is causing the failure (not
>> sure what's broken).
>>
>> commit 18bc67d56faef30a0f73429a5ee580e052858cb5
>> Author: armando-migliaccio 
>> Date:   Thu Jul 2 12:56:24 2015 -0700
>>
>> COMMON_PREFIXES cleanup - patch 5/5
>>
>> Get rid of COMMON_PREFIXES, as now the prefix is a service's
>> declaritive property.
>>
>> Change-Id: I3d306131df94188f75e69edb13d262721d10bee5
>> Depends-on: I0450d0b2bf409d470a3a87bfd96518939759a84e
>> Depends-on: Ia34695967cbbec0a1cf0884dad82e096de8539b8
>> Depends-on: Ib9517b772fe426eaf0809c439aa3ba0448c7abaa
>>
>>
>>
>> Here is the bisect log:
>>
>> # bad: [8b6d13012622d161774b701f3600ee401d63e5ba] Merge
>> "portsecurity_db_common: Access db columns in a consistent way"
>> git bisect bad 8b6d13012622d161774b701f3600ee401d63e5ba
>> # good: [49774afdc111d65cd8c9e73c1c1dee04d9c9f1a8] Merge "Read vif port
>> information in bulk"
>> git bisect good 49774afdc111d65cd8c9e73c1c1dee04d9c9f1a8
>> # good: [e9c4b6d974694e89d4a3bdefd33aea7445387490] Merge "Fall back on
>> empty path if prefix is missing"
>> git bisect good e9c4b6d974694e89d4a3bdefd33aea7445387490
>> # good: [211c0355778c1aef0dd4a44553f604b4fa3f72b3] Merge "Add policy
>> files specific to NSX plugins"
>> git bisect good 211c0355778c1aef0dd4a44553f604b4fa3f72b3
>> # good: [d845c6cdbd1d6d3c5800467cb8de74ac10c059de] Merge "Refactor
>> IpRuleCommand to take more arguments"
>> git bisect good d845c6cdbd1d6d3c5800467cb8de74ac10c059de
>> # good: [26c81334988b3de567964b863e75d9d48532b25e] Merge "Devref for
>> out-of-tree plugin/driver contribution"
>> git bisect good 26c81334988b3de567964b863e75d9d48532b25e
>> # bad: [678ddf4f18f6f3eca7ab2ce13cb4a8fdd655e0d5] Merge "COMMON_PREFIXES
>> cleanup - patch 5/5"
>> git bisect bad 678ddf4f18f6f3eca7ab2ce13cb4a8fdd655e0d5
>> # bad: [18bc67d56faef30a0f73429a5ee580e052858cb5] COMMON_PREFIXES cleanup
>> - patch 5/5
>> git bisect bad 18bc67d56faef30a0f73429a5ee580e052858cb5
>> # first bad commit: [18bc67d56faef30a0f73429a5ee580e052858cb5]
>> COMMON_PREFIXES cleanup - patch 5/5
>>
>> __
>> OpenStack Development Mailing 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] Issue with pymysql

[Armando M.]

Hi,

Another brief update on the matter:

Failure rate trends [1] are showing that unstable (w/ multiple API workers
+ pymysql driver) and stable configurations (w/o) are virtually aligned and
I am proposing that it is time to drop the unstable infra configuration
[2,3] that allowed the team to triage/experiment and get to a solution. I'll
watch [1] a little longer before I think it's safe to claim that we're out
of the woods.

Cheers,
Armando

[1] http://goo.gl/YM7gUC
[2] https://review.openstack.org/#/c/199668/
[3] https://review.openstack.org/#/c/199672/

On 22 June 2015 at 14:10, Armando M.  wrote:

> Hi,
>
> A brief update on the issue that sparked this thread:
>
> A little over a week ago, bug [1] was filed. The gist of that was that the
> switch to pymysql unveiled a number of latent race conditions that made
> Neutron unstable.
>
> To try and nip these in the bud, the Neutron team filed a number of
> patches [2], to create an unstable configuration that would allow them to
> troubleshoot and experiment a solution, by still keeping the stability in
> check (a preliminary proposal for a fix has been available in [4]).
>
> The latest failure rate trend is shown in [3]; as you can see, we're still
> gathering data, but it seems that the instability gap between the two jobs
> (stable vs unstable) has widened, and should give us plenty of data points
> to devise a resolution strategy.
>
> I have documented the most recurrent traces in the bug report [1].
>
> Will update once we managed to get the two curves to kiss each other again
> and close to a more acceptable failure rate.
>
> Cheers,
> Armando
>
> [1] https://bugs.launchpad.net/neutron/+bug/1464612
> [2] https://review.openstack.org/#/q/topic:neutron-unstable,n,z
> [3] http://goo.gl/YM7gUC
> [4] https://review.openstack.org/#/c/191540/
>
>
> On 12 June 2015 at 11:13, Boris Pavlovic  wrote:
>
>> Sean,
>>
>> Thanks for quick fix/revert https://review.openstack.org/#/c/191010/
>> This unblocked Rally gates...
>>
>> Best regards,
>> Boris Pavlovic
>>
>> On Fri, Jun 12, 2015 at 8:56 PM, Clint Byrum  wrote:
>>
>>> Excerpts from Mike Bayer's message of 2015-06-12 09:42:42 -0700:
>>> >
>>> > On 6/12/15 11:37 AM, Mike Bayer wrote:
>>> > >
>>> > >
>>> > > On 6/11/15 9:32 PM, Eugene Nikanorov wrote:
>>> > >> Hi neutrons,
>>> > >>
>>> > >> I'd like to draw your attention to an issue discovered by rally
>>> gate job:
>>> > >>
>>> http://logs.openstack.org/96/190796/4/check/gate-rally-dsvm-neutron-rally/7a18e43/logs/screen-q-svc.txt.gz?level=TRACE
>>> > >>
>>> > >> I don't have bandwidth to take a deep look at it, but first
>>> > >> impression is that it is some issue with nested transaction support
>>> > >> either on sqlalchemy or pymysql side.
>>> > >> Also, besides errors with nested transactions, there are a lot of
>>> > >> Lock wait timeouts.
>>> > >>
>>> > >> I think it makes sense to start with reverting the patch that moves
>>> > >> to pymysql.
>>> > > My immediate reaction is that this is perhaps a concurrency-related
>>> > > issue; because PyMySQL is pure python and allows for full blown
>>> > > eventlet monkeypatching, I wonder if somehow the same PyMySQL
>>> > > connection is being used in multiple contexts. E.g. one greenlet
>>> > > starts up a savepoint, using identifier "_3" which is based on a
>>> > > counter that is local to the SQLAlchemy Connection, but then another
>>> > > greenlet shares that PyMySQL connection somehow with another
>>> > > SQLAlchemy Connection that uses the same identifier.
>>> >
>>> > reading more of the log, it seems the main issue is just that there's a
>>> > deadlock on inserting into the securitygroups table.  The deadlock on
>>> > insert can be because of an index being locked.
>>> >
>>> >
>>> > I'd be curious to know how many greenlets are running concurrently
>>> here,
>>> > and what the overall transaction looks like within the operation that
>>> is
>>> > failing here (e.g. does each transaction insert multiple rows into
>>> > securitygroups?  that would make a deadlock seem more likely).
>>>
>>> This begs two questions:
>>>
>>> 1) Are we handling deadlocks with retries? It&#x

Re: [openstack-dev] [Neutron] Issue with pymysql

[Armando M.]

On 8 July 2015 at 14:30, Salvatore Orlando  wrote:

> I agree and I would make the switch as soon as possible. The graphite
> graph you posted showed that since 6/28 the difference in failure rate is
> such that isn't even statistically significant. However, spikes in failure
> rates of the unstable job also suggest that you're starting to chase a
> moving target, and we know how painful this is from the experience we had
> when enabling the neutron full job.
>

The spike was infrastructure failure-induced, but generally speaking I
agree with you.


>
> Salvatore
>
>
>
> On 8 July 2015 at 20:21, Armando M.  wrote:
>
>> Hi,
>>
>> Another brief update on the matter:
>>
>> Failure rate trends [1] are showing that unstable (w/ multiple API
>> workers + pymysql driver) and stable configurations (w/o) are virtually
>> aligned and I am proposing that it is time to drop the unstable infra
>> configuration [2,3] that allowed the team to triage/experiment and get to a
>> solution. I'll watch [1] a little longer before I think it's safe to
>> claim that we're out of the woods.
>>
>> Cheers,
>> Armando
>>
>> [1] http://goo.gl/YM7gUC
>> [2] https://review.openstack.org/#/c/199668/
>> [3] https://review.openstack.org/#/c/199672/
>>
>> On 22 June 2015 at 14:10, Armando M.  wrote:
>>
>>> Hi,
>>>
>>> A brief update on the issue that sparked this thread:
>>>
>>> A little over a week ago, bug [1] was filed. The gist of that was that
>>> the switch to pymysql unveiled a number of latent race conditions that made
>>> Neutron unstable.
>>>
>>> To try and nip these in the bud, the Neutron team filed a number of
>>> patches [2], to create an unstable configuration that would allow them to
>>> troubleshoot and experiment a solution, by still keeping the stability in
>>> check (a preliminary proposal for a fix has been available in [4]).
>>>
>>> The latest failure rate trend is shown in [3]; as you can see, we're
>>> still gathering data, but it seems that the instability gap between the two
>>> jobs (stable vs unstable) has widened, and should give us plenty of data
>>> points to devise a resolution strategy.
>>>
>>> I have documented the most recurrent traces in the bug report [1].
>>>
>>> Will update once we managed to get the two curves to kiss each other
>>> again and close to a more acceptable failure rate.
>>>
>>> Cheers,
>>> Armando
>>>
>>> [1] https://bugs.launchpad.net/neutron/+bug/1464612
>>> [2] https://review.openstack.org/#/q/topic:neutron-unstable,n,z
>>> [3] http://goo.gl/YM7gUC
>>> [4] https://review.openstack.org/#/c/191540/
>>>
>>>
>>> On 12 June 2015 at 11:13, Boris Pavlovic  wrote:
>>>
>>>> Sean,
>>>>
>>>> Thanks for quick fix/revert https://review.openstack.org/#/c/191010/
>>>> This unblocked Rally gates...
>>>>
>>>> Best regards,
>>>> Boris Pavlovic
>>>>
>>>> On Fri, Jun 12, 2015 at 8:56 PM, Clint Byrum  wrote:
>>>>
>>>>> Excerpts from Mike Bayer's message of 2015-06-12 09:42:42 -0700:
>>>>> >
>>>>> > On 6/12/15 11:37 AM, Mike Bayer wrote:
>>>>> > >
>>>>> > >
>>>>> > > On 6/11/15 9:32 PM, Eugene Nikanorov wrote:
>>>>> > >> Hi neutrons,
>>>>> > >>
>>>>> > >> I'd like to draw your attention to an issue discovered by rally
>>>>> gate job:
>>>>> > >>
>>>>> http://logs.openstack.org/96/190796/4/check/gate-rally-dsvm-neutron-rally/7a18e43/logs/screen-q-svc.txt.gz?level=TRACE
>>>>> > >>
>>>>> > >> I don't have bandwidth to take a deep look at it, but first
>>>>> > >> impression is that it is some issue with nested transaction
>>>>> support
>>>>> > >> either on sqlalchemy or pymysql side.
>>>>> > >> Also, besides errors with nested transactions, there are a lot of
>>>>> > >> Lock wait timeouts.
>>>>> > >>
>>>>> > >> I think it makes sense to start with reverting the patch that
>>>>> moves
>>>>> > >> to pymysql.
>>>>> > > My immediate reaction is that this is perhaps a concurrency-related
>&g

Re: [openstack-dev] [Neutron] adding new vendor driver to upstream

[Armando M.]

On 10 July 2015 at 16:01, Vadivel Poonathan 
wrote:

> Hi,
>
> I have a Neutron plugin (actually a mechanism_driver under ML2) developed
> for Alcatel-Lucent Omniswitches and is currently being used. But it is not
> part of Neutron upstream, nor listed in the docs/wiki section. I tried to
> make it part of Kilo release, but that was when the decomposition proposal
> was going on. Infact i reviewed the blueprint spec and provided some
> comments too. Since i had to decompose my driver as per the Kilo's
> decomposition spec, i deferred it to make it as part of Liberty release.
>
> Now going thru some wiki pages, blueprint specs etc, i 'm not clear on the
> procedures/criteria to make my driver integrated with upstream Neutron.
> Its all scattered and some says "all vendor code" is moved out-of-tree in
> Liberty, some says only vendor library is moved, some says third-party CI
> system is no longer required, some says it is one of the key requirement.
>

This is the most up-to-date place to look for to get you started:

https://github.com/openstack/neutron/blob/master/doc/source/devref/contribute.rst

There is no wiki afaik, and only one spec that targeted the Kilo release,
so I I'd be curious to know what you mean by 'it's all scattered', as I'd
love to clean this up if possible.


>
> *So i appreciate if someone could get me the exact step-by-step  procedure
> (the most recent, applicable to Liberty release) to have my driver released
> as part of Liberty and its documentation. *
>

If you still have questions, feel free to reach us out on
#openstack-neutron.

A.


>
>
> Here is my objective...
> 1) make my mechanism driver pkg available in the Neutron repository,
> accessible by public
> 2) update my mechanism driver in the list of supported vendor
> plugin/driver page, along with some documentation
>
> Pls. advise.
>
> Thanks and Regards,
> Vad
> --
>
> __
> OpenStack Development Mailing 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] [oslo][neutron] oslo.policy: policy_dirs config option, why deprecated?

[Armando M.]

On 7 July 2015 at 11:56, Doug Hellmann  wrote:

> Excerpts from Ben Nemec's message of 2015-07-07 11:41:35 -0500:
> > On 07/04/2015 12:12 AM, Akihiro Motoki wrote:
> > > Hi Oslo and Neutron folks,
> > >
> > > Why is policy_dirs option deprecated in oslo.policy?
> > > In Neutron we have multiple repositories which consist of Neutron
> services
> > > and we would like to maintain policy.json separately.
> > > policy_dirs option looks useful for this purpose.
> > >
> > > == Detail ==
> > >
> > > Neutron project now consists of several repositories and
> > > they are imported when neutron-server runs.
> > > There are cases where it makes sense that each repository manages its
> > > policy.json
> > > and the neutron-server wants to load all related policy.json files.
> > > - advanced services have separate repositories and they evolve their
> API
> > > independently
> > > - vendor plugins/drivers in separate repositories (can) have
> > > vendor-specific extension API.
> > >   (It is not a good thing from the point of the current API discussion,
> > > but we have now.)
> > >
> > > An easy way is to put all related policy.json into a single directory
> > > lile /etc/neutron/policy.d and specify this to policy_dirs option.
> >
> > This will still work fine.  The reason policy_dirs was deprecated is
> > that we didn't see a need to allow arbitrary policy.d locations and
> > doing so caused issues in some edge cases, so after the opt is removed
> > we will simply look for policy.d in the configuration directory.
> >
> > Essentially, today the default would be to look in
> > /etc/neutron/policy.d, but you can change that if you want.  Once the
> > opt is removed, you will _only_ be able to use /etc/neutron/policy.d.
> >
> > -Ben
> >
>
> It's more subtle than that. We have 2 variables interacting right
> now, config_dirs (managed by oslo.config) and policy_dirs (managed
> by oslo.policy). Both represent multiple places to look for
> configuration files, but the policy_dirs value must be a subdirectory
> of config_dirs.
>
> So if config_dirs is ['/etc/one', '/etc/two'] and policy_dirs is
> ['policy.d', 'another.d'] then the valid locations for policy files are
> ['/etc/one/policy.d', '/etc/two/policy.d', '/etc/one/another.d',
> '/etc/two/another.d']. That set of paths is obvious, but the *order* is
> also important, and it's not obvious.
>
> If we really need to have multiple policy files, we should add that
> support explicitly somehow instead of backing into it by having
> multiple directories.
>

So long as we keep multiple policy files in a single flat directory
(default to /etc/neutron/policy.d), this is enough to load them all of them
at once after the config option policy_dirs is removed. Did I understand
this correctly?

Many thanks,
Armando


> Doug
>
> __
> OpenStack Development Mailing 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] why do we gate tempest using q-vpn not q-l3?

[Armando M.]

On 23 July 2015 at 05:25, Ihar Hrachyshka  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hi all,
>
> I've stumbled on this one. It turns out we gate neutron against
> openstack installation that runs vpn-agent instead of l3-agent [1]. Is
> it really what we want to do? I would expect that gate validates l3
> agent as is, as is usually found on usual installations that do not
> need vpn connections.
>
>
We run with q-fwaas as well (which then lead to [1] as command line for the
L3 agent execution). Same can be said for fwaas, no?

[1] + setsid /usr/local/bin/neutron-vpn-agent --config-file
/etc/neutron/neutron.conf --config-file=/etc/neutron/l3_agent.ini
--config-file=/etc/neutron/vpn_agent.ini --config-file
/etc/neutron/fwaas_driver.ini


> Or is it the neat way we make sure we don't break vpn-agent?
>

The tempest-full test suite used to exercise network core capabilities as
well as advanced services (with test_vpnaas_extensions and
test_fwaas_extensions), now that it doesn't anymore [2] we could drop both,
as coverage is ensured by the neutron-dsvm-api job.

[2] https://review.openstack.org/#/c/186559/


>
> [1]:
> https://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/test-f
> eatures.sh#n21
>
> Ihar
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJVsN1RAAoJEC5aWaUY1u57eZ0IAI9oJIikbvD5dxGPoB7wm7mX
> 9OE583CAjn+hGUIMGa0kpVSBeDQmkQdp92ginFOo1lvXQZVT30OCOJau5YVoGE77
> Nl1d9TX6xO8vDkBNT5A69vHfZGxjL620+HvOHjupTYimqWiilj6fu0oUge2DNtI7
> do8TgL7SpDx31z9pF70zxqfHbARXq3HOb/AMfTz8jBRcnZmuvOQLt4Q/Xri6KFUw
> uW8XaEZ+3xJYsaFsWna8YIEQY/R4TDqnyStGvRqzX9CGRDkzc/0gWalBSAkXewdQ
> sOwN4MhhxJcWMXRVwPp+auvBOKQJ8Bq5uIR0WRIDhAaUtDNHstDefFnCBzmX8nc=
> =kxs2
> -END PGP SIGNATURE-
>
> __
> OpenStack Development Mailing 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] The proposed "Neutron API extension for packet forwarding" has a lot of duplication to the Neutron SFC API

[Armando M.]

Hi,

Since I was quoted, I would like to take the blame on behalf on the Neutron
core reviewer/drivers team for not providing the right guidance to resolve
the apparent conflict between the two proposals.

As some reviewers mentioned, we should really strive to catch two birds
with one stone, and ensure that, if at all possible, the same API can
address both use cases presented. In this case, it sounds to me that the
API proposed by the networking-sfc sub-project is more comprehensive, it
has taken the steps to evolve independently from the Neutron core platform,
and it has been iterated on multiple times. Surely we can spin off (the
forwarding engine) from the spin off (the SFC API), but that would feel
like an overkill, especially when both have very little code to show for
(and everyone knows that code wins in OpenStack).

We should have provided Yuji Azama feedback a lot earlier in the process
but we didn't. Again, blame me!

I think that Sean raised a flag which should be seen as an acknowledgment
of a need to reconcile the two efforts; let's move past the blame game and
the language barriers, and let's figure out how to address Yuji's need
within the context of a single effort, without dismissing it. For this
reason I am going to suggest we iterate within the networking-sfc project,
and block change 186663 . Let's
figure out how the model/API has to evolve to accommodate the proposed used
need.

If you disagree, please raise your concern on the patch in review itself.

Cheers,
Armando

On 28 July 2015 at 15:01, Sean M. Collins  wrote:

> All,
>
> My suggestion was as follows:
>
> >  I'd say maybe an e-mail to the ML, with the results of this
> meeting, and say that we want to try and converge where
> > there is commonality
>
> I think there is overlap between the two APIs. Let's keep collaborating
> on both the networking-sfc and packet forwarding APIs, to see where we
> have commonality. I think Cathy's initial e-mail may have ruffled
> feathers - and I'd like to smooth them out again. I think the statement
> "we only need one API" is far too premature.
>
> Let's play nice with the other API proposals, yes?
>
>
> --
> 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] The proposed "Neutron API extension for packet forwarding" has a lot of duplication to the Neutron SFC API

[Armando M.]

On 29 July 2015 at 22:42, Anita Kuno  wrote:

> On 07/29/2015 02:37 PM, Armando M. wrote:
> > Hi,
> >
> > Since I was quoted, I would like to take the blame on behalf on the
> Neutron
> > core reviewer/drivers team for not providing the right guidance to
> resolve
> > the apparent conflict between the two proposals.
> >
> > As some reviewers mentioned, we should really strive to catch two birds
> > with one stone, and ensure that, if at all possible, the same API can
> > address both use cases presented. In this case, it sounds to me that the
> > API proposed by the networking-sfc sub-project is more comprehensive, it
> > has taken the steps to evolve independently from the Neutron core
> platform,
> > and it has been iterated on multiple times. Surely we can spin off (the
> > forwarding engine) from the spin off (the SFC API), but that would feel
> > like an overkill, especially when both have very little code to show for
> > (and everyone knows that code wins in OpenStack).
> >
> > We should have provided Yuji Azama feedback a lot earlier in the process
> > but we didn't. Again, blame me!
> >
> > I think that Sean raised a flag which should be seen as an acknowledgment
> > of a need to reconcile the two efforts; let's move past the blame game
> and
> > the language barriers, and let's figure out how to address Yuji's need
> > within the context of a single effort, without dismissing it. For this
> > reason I am going to suggest we iterate within the networking-sfc
> project,
> > and block change 186663 <https://review.openstack.org/#/c/186663/>.
> Let's
> > figure out how the model/API has to evolve to accommodate the proposed
> used
> > need.
> >
> > If you disagree, please raise your concern on the patch in review itself.
> >
> > Cheers,
> > Armando
>
> Hi Armando,
>
> If my attempts to offer some feedback on communication came across as
> blame than I failed in what I was trying to accomplish.


> My goal was and is to try to illustrate the point that competition and
> collaboration are two separate directions.
>
> While some folks come from a competitive background, I hold the vision
> of OpenStack as a collaborative experience. Some folks many need more
> time than others to understand and digest the differences in behaviour
> associated with the two styles of operating.
>
> I appreciate your email, Armando. At the very least it sets a good
> example for others who many be new to collaboration to follow.
>
> As always, it is a pleasure to work with you Armax,
> Anita.


My point was simply to encourage the people involved in both efforts to
take action after the discussion. The resolution of using one API over the
other did not translate into a patch in any of our repos to capture the
conclusion, at least not until now anyway, and without that, any
back-and-forth is moot.

That said, I think it's important that you keep us honest along our journey
:)

Thank you!


>
> >
> > On 28 July 2015 at 15:01, Sean M. Collins  wrote:
> >
> >> All,
> >>
> >> My suggestion was as follows:
> >>
> >>>  I'd say maybe an e-mail to the ML, with the results of this
> >> meeting, and say that we want to try and converge where
> >>> there is commonality
> >>
> >> I think there is overlap between the two APIs. Let's keep collaborating
> >> on both the networking-sfc and packet forwarding APIs, to see where we
> >> have commonality. I think Cathy's initial e-mail may have ruffled
> >> feathers - and I'd like to smooth them out again. I think the statement
> >> "we only need one API" is far too premature.
> >>
> >> Let's play nice with the other API proposals, yes?
> >>
> >>
> >> --
> >> 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
> >
>
>
> __
> OpenStack Development Mailing 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] till when must code land to make it in liberty

[Armando M.]

On 31 July 2015 at 20:33, Paul Carver  wrote:

> On 7/31/2015 9:47 AM, Kyle Mestery wrote:
>
> However, it's reasonable to assume the later you propose your RFE bug, the
>> less of a chance it has of making it. We do enforce the Feature Freeze
>> [2],
>> which is the week of August 31 [3]. Thus, effectively you have 4 weeks to
>> submit patches for new features.
>>
>>
> Does the feature freeze apply to "big tent" work? I certainly think we
> should try to stick as close to Neutron process as possible, but I'm
> wondering if we need to consider August 31 a hard deadline for the
> networking-sfc work.
>
> I suspect we won't be feature complete by the 31st, we will probably need
> to work well into September in order to ensure that we have something with
> all the necessary parts working.
>
>
Technically speaking the projects under the neutron folder have an
independent release schedule [1,2]; so you could go past the deadline, if
need be.

[1] http://governance.openstack.org/reference/tags/release_independent.html
[2]
http://governance.openstack.org/reference/projects/neutron.html#project-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
>
__
OpenStack Development Mailing 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] I am pleased to propose two new Neutron API/DB/RPC core reviewers!

[Armando M.]

Is this an example of +1+1=3?

On 12 August 2015 at 07:51, Doug Wiegley 
wrote:

> A big +1 to both!!
>
> Doug
>
>
>
> On Aug 12, 2015, at 6:45 AM, Kyle Mestery  wrote:
>
> It gives me great pleasure to propose Russell Bryant and Brandon Logan as
> core reviewers in the API/DB/RPC area of Neutron. Russell and Brandon have
> both been incredible contributors to Neutron for a while now. Their
> expertise has been particularly helpful in the area they are being proposed
> in. Their review stats [1] place them both comfortably in the range of
> existing Neutron core reviewers. I expect them to continue working with all
> community members to drive Neutron forward for the rest of Liberty and into
> Mitaka.
>
> Existing DB/API/RPC core reviewers (and other Neutron core reviewers),
> please vote +1/-1 for the addition of Russell and Brandon.
>
> Thanks!
> Kyle
>
> [1] http://stackalytics.com/report/contribution/neutron-group/90
>
> __
> OpenStack Development Mailing 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] Netaddr 0.7.16 and gate breakage

[Armando M.]

Hi,

If you wonder why hell broke loose, [1] will have the answer to your
questions.

Armando

[1] https://bugs.launchpad.net/neutron/+bug/1490380
__
OpenStack Development Mailing 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] Netaddr 0.7.16 and gate breakage

[Armando M.]

On 31 August 2015 at 09:33, Carl Baldwin  wrote:

> I was under the impression that we had a plan to stop allowing these
> external updates break our gate jobs.  It seems extremely unwise to
> allow these forces outside of our control to disrupt us so much
> especially in such a large project as Neutron.  We lose a lot of
> valuable time to these.


My sentiment exactly.


>   I thought that we were going to do something
> like cap all of the dependencies and introduce automated updates to
> those caps in a more controlled manner where updates can be tested in
> a review.  Is something like that still in the works?
>

If there isn't, there must be a good reason that I fail to grasp, and I
wouldn't mind if people filled me in on the rationale. I promise I'll make
a note so that I don't forget.


> Is it just me or does it seem like a breaking update like this always
> comes around the end of a cycle or a feature freeze?
>

You missed 'weekends' :)

Not that it is any consolation, at least there are always a few brave
individuals that step in to the fire!


>
> Carl
>
> On Sun, Aug 30, 2015 at 9:54 PM, Armando M.  wrote:
> > Hi,
> >
> > If you wonder why hell broke loose, [1] will have the answer to your
> > questions.
> >
> > Armando
> >
> > [1] https://bugs.launchpad.net/neutron/+bug/1490380
> >
> >
> __
> > OpenStack Development Mailing 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] Netaddr 0.7.16 and gate breakage

[Armando M.]

On 31 August 2015 at 09:53, Jeremy Stanley  wrote:

> On 2015-08-31 10:33:07 -0600 (-0600), Carl Baldwin wrote:
> > I was under the impression that we had a plan to stop allowing these
> > external updates break our gate jobs.
> [...]
>
> We do, and it succeeded in protecting master branch integration test
> jobs from this new netaddr release:
>
> https://review.openstack.org/218737
>
> This was able to get implemented fairly early because DevStack
> already contained mechanisms for relying on the requirements repo to
> define its behavior WRT dependencies. The logistics for pinning
> versions in every project's unit tests, however, are more complex
> and not yet in place (but are in progress). Also where grenade is
> concerned, the breakage is on the stable/kilo side where we don't
> have constraints pinning implemented (since that work has been
> primarily in master this cycle and targeting liberty).
>

Great...if there is any collaboration required by the individual projects,
please do not hesitate to reach out...we'd be happy to do our part.


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

Re: [openstack-dev] [neutron][gate] please stop approving patches until netaddr issue is solved

[Armando M.]

On 31 August 2015 at 06:18, Ihar Hrachyshka  wrote:

> Hi all,
>
> I see neutron folks pushing more neutron patches into the gate. They are
> all doomed to fail until [1] is resolved. So please stop approving patches,
> we only make harm by resetting the gate, with no chance to pass it.
>
> PS: it is the same for all neutron stadium projects, so *aas and
> python-networking-* folks, please also avoid +W until the situation is
> cleared.
>
> [1]: https://bugs.launchpad.net/neutron/+bug/1490380
>
> Ihar
>

Looks like the gate is clear nowplease use it with care :)



> __
> OpenStack Development Mailing 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][gate] please stop approving patches until netaddr issue is solved

[Armando M.]

On 31 August 2015 at 10:44, Edgar Magana  wrote:

> Yeah!!
>

Well don't get so excited, the check queue is hovering over the 200 mark,
so.


>
> From: "Armando M."
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> Date: Monday, August 31, 2015 at 10:26 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> Subject: Re: [openstack-dev] [neutron][gate] please stop approving
> patches until netaddr issue is solved
>
>
>
> On 31 August 2015 at 06:18, Ihar Hrachyshka  wrote:
>
>> Hi all,
>>
>> I see neutron folks pushing more neutron patches into the gate. They are
>> all doomed to fail until [1] is resolved. So please stop approving patches,
>> we only make harm by resetting the gate, with no chance to pass it.
>>
>> PS: it is the same for all neutron stadium projects, so *aas and
>> python-networking-* folks, please also avoid +W until the situation is
>> cleared.
>>
>> [1]: https://bugs.launchpad.net/neutron/+bug/1490380
>>
>> Ihar
>>
>
> Looks like the gate is clear nowplease use it with care :)
>
>
>
>> __
>> OpenStack Development Mailing 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][gate] please stop approving patches until netaddr issue is solved

[Armando M.]

On 31 August 2015 at 11:41, Armando M.  wrote:

>
> On 31 August 2015 at 10:44, Edgar Magana  wrote:
>
>> Yeah!!
>>
>
> Well don't get so excited, the check queue is hovering over the 200 mark,
> so.
>
>

well, that didn't last long:

We're failing now

raise VersionConflict(dist, req).with_context(dependent_req)2015-08-31
20:42:19.978 
<http://logs.openstack.org/72/217272/2/check/gate-grenade-dsvm-neutron/fc65317/logs/old/devstacklog.txt.gz#_2015-08-31_20_42_19_978>
| pkg_resources.ContextualVersionConflict: (pbr 0.11.0
(/usr/local/lib/python2.7/dist-packages),
Requirement.parse('pbr<2.0,>=1.3'), set(['sqlalchemy-migrate']))

On the grenade job...stay tuned.

A.


>
>> From: "Armando M."
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> Date: Monday, August 31, 2015 at 10:26 AM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> Subject: Re: [openstack-dev] [neutron][gate] please stop approving
>> patches until netaddr issue is solved
>>
>>
>>
>> On 31 August 2015 at 06:18, Ihar Hrachyshka  wrote:
>>
>>> Hi all,
>>>
>>> I see neutron folks pushing more neutron patches into the gate. They are
>>> all doomed to fail until [1] is resolved. So please stop approving patches,
>>> we only make harm by resetting the gate, with no chance to pass it.
>>>
>>> PS: it is the same for all neutron stadium projects, so *aas and
>>> python-networking-* folks, please also avoid +W until the situation is
>>> cleared.
>>>
>>> [1]: https://bugs.launchpad.net/neutron/+bug/1490380
>>>
>>> Ihar
>>>
>>
>> Looks like the gate is clear nowplease use it with care :)
>>
>>
>>
>>>
>>> __
>>> OpenStack Development Mailing 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] pushing changes through the gate

[Armando M.]

Hi,

By now you may have seen that I have taken out your change from the gate
and given it a -2: don't despair! I am only doing it to give priority to
the stuff that needs to merge in order to get [1] into a much better shape.

If you have an important fix, please target it for RC1 or talk to me or
Doug (or Kyle when he's back from his time off), before putting it in the
gate queue. If everyone is not conscious of the other, we'll only end up
stepping on each other, and nothing moves forward.

Let's give priority to gate stabilization fixes, and targeted stuff.

Happy merging...not!

Many thanks,
Armando

[1] https://launchpad.net/neutron/+milestone/liberty-3
[2] https://launchpad.net/neutron/+milestone/liberty-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

Re: [openstack-dev] [neutron] pushing changes through the gate

[Armando M.]

On 2 September 2015 at 09:40, Armando M.  wrote:

> Hi,
>
> By now you may have seen that I have taken out your change from the gate
> and given it a -2: don't despair! I am only doing it to give priority to
> the stuff that needs to merge in order to get [1] into a much better shape.
>
> If you have an important fix, please target it for RC1 or talk to me or
> Doug (or Kyle when he's back from his time off), before putting it in the
> gate queue. If everyone is not conscious of the other, we'll only end up
> stepping on each other, and nothing moves forward.
>
> Let's give priority to gate stabilization fixes, and targeted stuff.
>
> Happy merging...not!
>
> Many thanks,
> Armando
>
> [1] https://launchpad.net/neutron/+milestone/liberty-3
> [2] https://launchpad.net/neutron/+milestone/liberty-rc1
>

Download files for the milestone are available in [1]. We still have a lot
to do as there are outstanding bugs and blueprints that will have to be
merged in the RC time windows.

Please be conscious of what you approve. Give priority to:

- Targeted bugs and blueprints in [2];
- Gate stability fixes or patches that aim at helping troubleshooting;

In these busy times, please refrain from proposing/merging:

- Silly rebase generators (e.g. spelling mistakes);
- Cosmetic changes (e.g. minor doc strings/comment improvements);
- Refactoring required while dealing with the above;
- A dozen of patches stacked on top of each other;

Every rule has its own exception, so don't take this literally.

If you are unsure, please reach out to me, Kyle or your Lieutenant and
we'll target stuff that is worth targeting.

As for the rest, I am gonna be merciless and -2 anything than I can find,
in order to keep our gate lean and sane :)

Thanks and happy hacking.

A.

[1] https://launchpad.net/neutron/+milestone/liberty-3
[2] https://launchpad.net/neutron/+milestone/liberty-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

Re: [openstack-dev] [neutron] pushing changes through the gate

[Armando M.]

On 3 September 2015 at 17:55, Hirofumi Ichihara <
ichihara.hirof...@lab.ntt.co.jp> wrote:

> Good work and thank you for your help with my patch.
>
> Anyway, I don’t know when does bp owner have to merge the code by.
> I can see the following sentence in bp rule[1]
> “The PTL will create a -backlog directory during the RC window
> and move all specs which didn’t make the  there.”
> Did we have to merge the implementation by L-3? Or can we merge it in RC-1?
>
> [1]:
> http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-bp-and-spec-notes
>
>
It depends on the extent of the changes remaining to merge. There is no
hard and fast rule, because every blueprint is different: the code can be
complex and pervasive, or simple and isolated. In the former even a small
patch may be deferred, in the latter even a dozen patches could be merged
during RC. Some other blueprints are best completed during feature freeze,
because of the rebase risk they cause...

Bottom line: never leave it to last minute!


> Thanks,
> Hirofumi
>
> On 2015/09/04, at 7:00, Armando M.  wrote:
>
>
>
> On 2 September 2015 at 09:40, Armando M.  wrote:
>
>> Hi,
>>
>> By now you may have seen that I have taken out your change from the gate
>> and given it a -2: don't despair! I am only doing it to give priority to
>> the stuff that needs to merge in order to get [1] into a much better shape.
>>
>> If you have an important fix, please target it for RC1 or talk to me or
>> Doug (or Kyle when he's back from his time off), before putting it in the
>> gate queue. If everyone is not conscious of the other, we'll only end up
>> stepping on each other, and nothing moves forward.
>>
>> Let's give priority to gate stabilization fixes, and targeted stuff.
>>
>> Happy merging...not!
>>
>> Many thanks,
>> Armando
>>
>> [1] https://launchpad.net/neutron/+milestone/liberty-3
>> [2] https://launchpad.net/neutron/+milestone/liberty-rc1
>>
>
> Download files for the milestone are available in [1]. We still have a lot
> to do as there are outstanding bugs and blueprints that will have to be
> merged in the RC time windows.
>
> Please be conscious of what you approve. Give priority to:
>
> - Targeted bugs and blueprints in [2];
> - Gate stability fixes or patches that aim at helping troubleshooting;
>
> In these busy times, please refrain from proposing/merging:
>
> - Silly rebase generators (e.g. spelling mistakes);
> - Cosmetic changes (e.g. minor doc strings/comment improvements);
> - Refactoring required while dealing with the above;
> - A dozen of patches stacked on top of each other;
>
> Every rule has its own exception, so don't take this literally.
>
> If you are unsure, please reach out to me, Kyle or your Lieutenant and
> we'll target stuff that is worth targeting.
>
> As for the rest, I am gonna be merciless and -2 anything than I can find,
> in order to keep our gate lean and sane :)
>
> Thanks and happy hacking.
>
> A.
>
> [1] https://launchpad.net/neutron/+milestone/liberty-3
> [2] https://launchpad.net/neutron/+milestone/liberty-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 Development Mailing 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] [docs][networking-sfc]

[Armando M.]

On 4 September 2015 at 15:33, Paul Carver  wrote:

>
> Can someone from the Docs team take a look at why there isn't a docs URL
> for the networking-sfc repo?
>

Everything in OpenStack is code driven. And doc publishing happens through
code review as much as anything else. [1] Should provide pointers, but
another great source of recipes and clues can be found on [2]. You'll find
your answer in there somewhere.

HTH
Armando

[1]
http://docs.openstack.org/infra/manual/creators.html#add-basic-jenkins-jobs
[2] https://github.com/openstack-infra/project-config/commits/master


>
> Compare [1] vs [2]
> The first URL appears to be a rendering of the docs/source/index.rst from
> the Neutron Git repo, but the second one gives a Not Found even though
> there is a docs/source/index.rst in the networking-sfc repo.
>
> If I've guessed the wrong URL, please let me know. I just guessed that
> replacing the name of the neutron repo in the URL with the name of the
> networking-sfc repo should have given me the right URL.
>
> Compare [3] vs [4]
>
> Both of these exist and as far as I can tell [1] is rendered from [3] and
> I would just naturally expect [2] to be rendered from [4] but it isn't.
>
> [1] http://docs.openstack.org/developer/neutron/
> [2] http://docs.openstack.org/developer/networking-sfc/
> [3]
> https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/index.rst
> [4]
> https://git.openstack.org/cgit/openstack/networking-sfc/tree/doc/source/index.rst
>
> __
> OpenStack Development Mailing 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] RFE process question

[Armando M.]

On 10 September 2015 at 11:04, James Dempsey  wrote:

> Greetings Devs,
>
> I'm very excited about the new RFE process and thought I'd test it by
> requesting a feature that is very often requested by my users[1].
>
> There are some great docs out there about how to submit an RFE, but I
> don't know what should happen after the submission to launchpad. My RFE
> bug seems to have been untouched for a month and I'm unsure if I've done
> something wrong. So, here are a few questions that I have.
>
>
> 1. Should I be following up on the dev list to ask for someone to look
> at my RFE bug?
> 2. How long should I expect it to take to have my RFE acknowledged?
> 3. As an operator, I'm a bit ignorant as to whether or not there are
> times during the release cycle during which there simply won't be
> bandwidth to consider RFE bugs.
> 4. Should I be doing anything else?
>
> Would love some guidance.
>

you did nothing wrong, the team was simply busy going through the existing
schedule. Having said that, you could have spared a few more words on the
use case and what you mean by annotations.

I'll follow up on the RFE for more questions.

Cheers,
Armando


>
> Cheers,
> James
>
> [1] https://bugs.launchpad.net/neutron/+bug/1483480
>
> --
> James Dempsey
> Senior Cloud Engineer
> Catalyst IT Limited
> +64 4 803 2264
> --
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] PTL Non-Candidacy

[Armando M.]

On 12 September 2015 at 18:38, Gary Kotton  wrote:

> Thanks! You did a great job. Looking back you made some very tough and
> healthy decisions. Neutron has a new lease on life!
> It is tradition that the exiting PTL buy drinks for the community :)
>

Ok, none of these kind words make you change your mind? This project needs
you!


>
> From: "mest...@mestery.com" 
> Reply-To: OpenStack List 
> Date: Saturday, September 12, 2015 at 12:12 AM
> To: OpenStack List 
> Subject: [openstack-dev] [neutron] PTL Non-Candidacy
>
> I'm writing to let everyone know that I do not plan to run for Neutron PTL
> for a fourth cycle. Being a PTL is a rewarding but difficult job, as Morgan
> recently put it in his non-candidacy email [1]. But it goes further than
> that for me. As Flavio put it in his post about "Being a PTL" [2], it's a
> full time job. In the case of Neutron, it's more than a full time job, it's
> literally an always on job.
>
> I've tried really hard over my three cycles as PTL to build a stronger web
> of trust so the project can grow, and I feel that's been accomplished. We
> have a strong bench of future PTLs and leaders ready to go, I'm excited to
> watch them lead and help them in anyway I can.
>
> As was said by Zane in a recent email [3], while Heat may have pioneered
> the concept of rotating PTL duties with each cycle, I'd like to highly
> encourage Neutron and other projects to do the same. Having a deep bench of
> leaders supporting each other is important for the future of all projects.
>
> See you all in Tokyo!
> Kyle
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074157.html
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/073986.html
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2015-September/074242.html
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Armando M.]

On 15 September 2015 at 08:27, Mike Spreitzer  wrote:

> Monty Taylor  wrote on 09/15/2015 11:04:07 AM:
>
> > a) an update to python-novaclient to allow a named network to be passed
> > to satisfy the "you have more than one network" - the nics argument is
> > still useful for more complex things
>
> I am not using the latest, but rather Juno.  I find that in many places
> the Neutron CLI insists on a UUID when a name could be used.  Three cheers
> for any campaign to fix that.


The client is not particularly tied to a specific version of the server, so
we don't have a Juno version, or a Kilo version, etc. (even though they are
aligned, see [1] for more details).

Having said that, you could use names in place of uuids pretty much
anywhere. If your experience says otherwise, please consider filing a bug
against the client [2] and we'll get it fixed.

Thanks,
Armando

[1] https://launchpad.net/python-neutronclient/+series
[2] https://bugs.launchpad.net/python-neutronclient/+filebug


>
>
> And, yeah, creating VMs on a shared public network is good too.
>
> Thanks,
> mike
>
> __
> OpenStack Development Mailing 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][devstack] New proposed 'default' network model

[Armando M.]

On 15 September 2015 at 08:04, Monty Taylor  wrote:

> Hey all!
>
> If any of you have ever gotten drunk with me, you'll know I hate floating
> IPs more than I hate being stabbed in the face with a very angry fish.
>
> However, that doesn't really matter. What should matter is "what is the
> most sane thing we can do for our users"
>
> As you might have seen in the glance thread, I have a bunch of OpenStack
> public cloud accounts. Since I wrote that email this morning, I've added
> more - so we're up to 13.
>
> auro
> citycloud
> datacentred
> dreamhost
> elastx
> entercloudsuite
> hp
> ovh
> rackspace
> runabove
> ultimum
> unitedstack
> vexxhost
>
> Of those public clouds, 5 of them require you to use a floating IP to get
> an outbound address, the others directly attach you to the public network.
> Most of those 8 allow you to create a private network, to boot vms on the
> private network, and ALSO to create a router with a gateway and put
> floating IPs on your private ip'd machines if you choose.
>
> Which brings me to the suggestion I'd like to make.
>
> Instead of having our default in devstack and our default when we talk
> about things be "you boot a VM and you put a floating IP on it" - which
> solves one of the two usage models - how about:
>
> - Cloud has a shared: True, external:routable: True neutron network. I
> don't care what it's called  ext-net, public, whatever. the "shared" part
> is the key, that's the part that lets someone boot a vm on it directly.
>
> - Each person can then make a private network, router, gateway, etc. and
> get floating-ips from the same public network if they prefer that model.
>
> Are there any good reasons to not push to get all of the public networks
> marked as "shared"?
>

The reason is simple: not every cloud deployment is the same: private is
different from public and even within the same cloud model, the network
topology may vary greatly.

Perhaps Neutron fails in the sense that it provides you with too much
choice, and perhaps we have to standardize on the type of networking
profile expected by a user of OpenStack public clouds before making changes
that would fragment this landscape even further.

If you are advocating for more flexibility without limiting the existing
one, we're only making the problem worse.


>
> OH - well, one thing - that's that once there are two networks in an
> account you have to specify which one. This is really painful in nova
> clent. Say, for instance, you have a public network called "public" and a
> private network called "private" ...
>
> You can't just say "nova boot --network=public" - nope, you need to say
> "nova boot --nics net-id=$uuid_of_my_public_network"
>
> So I'd suggest 2 more things;
>
> a) an update to python-novaclient to allow a named network to be passed to
> satisfy the "you have more than one network" - the nics argument is still
> useful for more complex things
>
> b) ability to say "vms in my cloud should default to being booted on the
> public network" or "vms in my cloud should default to being booted on a
> network owned by the user"
>
> Thoughts?
>

As I implied earlier, I am not sure how healthy this choice is. As a user
of multiple clouds I may end up having a different user experience based on
which cloud I am using...I thought you were partially complaining about
lack of consistency?


>
> Monty
>
> __
> OpenStack Development Mailing 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][devstack] New proposed 'default' network model

[Armando M.]

On 15 September 2015 at 11:28, Matt Riedemann 
wrote:

>
>
> On 9/15/2015 10:27 AM, Mike Spreitzer wrote:
>
>> Monty Taylor  wrote on 09/15/2015 11:04:07 AM:
>>
>>  > a) an update to python-novaclient to allow a named network to be passed
>>  > to satisfy the "you have more than one network" - the nics argument is
>>  > still useful for more complex things
>>
>> I am not using the latest, but rather Juno.  I find that in many places
>> the Neutron CLI insists on a UUID when a name could be used.  Three
>> cheers for any campaign to fix that.
>>
>
> It's my understanding that network names in neutron, like security groups,
> are not unique, that's why you have to specify a UUID.
>

Last time I checked, that's true of any resource in Openstack.


>
>> And, yeah, creating VMs on a shared public network is good too.
>>
>> Thanks,
>> mike
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> --
>
> 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

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Armando M.]

On 15 September 2015 at 10:02, Doug Hellmann  wrote:

> Excerpts from Armando M.'s message of 2015-09-15 09:30:35 -0700:
> > On 15 September 2015 at 08:04, Monty Taylor 
> wrote:
> >
> > > Hey all!
> > >
> > > If any of you have ever gotten drunk with me, you'll know I hate
> floating
> > > IPs more than I hate being stabbed in the face with a very angry fish.
> > >
> > > However, that doesn't really matter. What should matter is "what is the
> > > most sane thing we can do for our users"
> > >
> > > As you might have seen in the glance thread, I have a bunch of
> OpenStack
> > > public cloud accounts. Since I wrote that email this morning, I've
> added
> > > more - so we're up to 13.
> > >
> > > auro
> > > citycloud
> > > datacentred
> > > dreamhost
> > > elastx
> > > entercloudsuite
> > > hp
> > > ovh
> > > rackspace
> > > runabove
> > > ultimum
> > > unitedstack
> > > vexxhost
> > >
> > > Of those public clouds, 5 of them require you to use a floating IP to
> get
> > > an outbound address, the others directly attach you to the public
> network.
> > > Most of those 8 allow you to create a private network, to boot vms on
> the
> > > private network, and ALSO to create a router with a gateway and put
> > > floating IPs on your private ip'd machines if you choose.
> > >
> > > Which brings me to the suggestion I'd like to make.
> > >
> > > Instead of having our default in devstack and our default when we talk
> > > about things be "you boot a VM and you put a floating IP on it" - which
> > > solves one of the two usage models - how about:
> > >
> > > - Cloud has a shared: True, external:routable: True neutron network. I
> > > don't care what it's called  ext-net, public, whatever. the "shared"
> part
> > > is the key, that's the part that lets someone boot a vm on it directly.
> > >
> > > - Each person can then make a private network, router, gateway, etc.
> and
> > > get floating-ips from the same public network if they prefer that
> model.
> > >
> > > Are there any good reasons to not push to get all of the public
> networks
> > > marked as "shared"?
> > >
> >
> > The reason is simple: not every cloud deployment is the same: private is
> > different from public and even within the same cloud model, the network
> > topology may vary greatly.
> >
> > Perhaps Neutron fails in the sense that it provides you with too much
> > choice, and perhaps we have to standardize on the type of networking
> > profile expected by a user of OpenStack public clouds before making
> changes
> > that would fragment this landscape even further.
> >
> > If you are advocating for more flexibility without limiting the existing
> > one, we're only making the problem worse.
>
> As with the Glance image upload API discussion, this is an example
> of an extremely common use case that is either complex for the end
> user or for which they have to know something about the deployment
> in order to do it at all. The usability of an OpenStack cloud running
> neutron would be enhanced greatly if there was a simple, clear, way
> for the user to get a new VM with a public IP on any cloud without
> multiple steps on their part.


I agree on this last statement wholeheartedly, but we gotta be careful on
how we do it, because there are implications on scalability and security.

Today Neutron provides a few network deployment models [1,2,3,4,5]. You can
mix and match, with the only caveat is that this stuff must be
pre-provisioned.

Now the way I understand Monty's request is that in certain deployments
you'd like automatic provisioning. We can look into that, as we have in
blueprint [6], but we must recognize that hint-less requests can be hard to
achieve because the way the network service is provided can vary from
system to system...a lot.

Defaults are useful, but wrong defaults are worse. A system can make an
educated guess as of the user's intention, in lieu of that an operator can
force the choice for the user, but if that one is hard too, then the only
choice is to defer to the user.

So this boils down to: in light of the possible ways of providing VM
connectivity, how can we make a choice on the user's behalf? Can we assume
that he/she always want a publicly facing VM connected to Internet? The
answer is 'no'.


> There are a lot of ways to im

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Armando M.]

On 15 September 2015 at 14:04, Mike Spreitzer  wrote:

> "Armando M."  wrote on 09/15/2015 03:50:24 PM:
>
> > On 15 September 2015 at 10:02, Doug Hellmann 
> wrote:
> > Excerpts from Armando M.'s message of 2015-09-15 09:30:35 -0700:
> ...
> > As with the Glance image upload API discussion, this is an example
> > of an extremely common use case that is either complex for the end
> > user or for which they have to know something about the deployment
> > in order to do it at all. The usability of an OpenStack cloud running
> > neutron would be enhanced greatly if there was a simple, clear, way
> > for the user to get a new VM with a public IP on any cloud without
> > multiple steps on their part.
>
> <<<<<>>>>>
>
> ...
> >
> > So this boils down to: in light of the possible ways of providing VM
> > connectivity, how can we make a choice on the user's behalf? Can we
> > assume that he/she always want a publicly facing VM connected to
> > Internet? The answer is 'no'.
>
> While it may be true that in some deployments there is no good way for the
> code to choose, I think that is not the end of the story here.  The
> motivation to do this is that in *some* deployments there *is* a good way
> for the code to figure out what to do.


Agreed, I wasn't dismissing this entirely. I was simply saying that if we
don't put constraints in place it's difficult to come up with a good
'default' answer.


>
>
> Regards,
> Mike
>
> __
> OpenStack Development Mailing 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][devstack] New proposed 'default' network model

[Armando M.]

On 15 September 2015 at 15:11, Mathieu Gagné  wrote:

> On 2015-09-15 2:00 PM, Fox, Kevin M wrote:
> > We run several clouds where there are multiple external networks. the
> "just run it in on THE public network" doesn't work. :/
> >
> > I also strongly recommend to users to put vms on a private network and
> use floating ip's/load balancers. For many reasons. Such as, if you don't,
> the ip that gets assigned to the vm helps it become a pet. you can't
> replace the vm and get the same IP. Floating IP's and load balancers can
> help prevent pets. It also prevents security issues with DNS and IP's.
> Also, for every floating ip/lb I have, I usually have 3x or more the number
> of instances that are on the private network. Sure its easy to put
> everything on the public network, but it provides much better security if
> you only put what you must on the public network. Consider the internet.
> would you want to expose every device in your house directly on the
> internet? No. you put them in a private network and poke holes just for the
> stuff that does. we should be encouraging good security practices. If we
> encourage bad ones, then it will bite us later when OpenStack gets a
> reputation for being associated with compromises.
> >
>
> Sorry but I feel this kind of reply explains why people are still using
> nova-network over Neutron. People want simplicity and they are denied it
> at every corner because (I feel) Neutron thinks it knows better.
>

I am sorry, but how can you associate a person's opinion to a project,
which is a collectivity? Surely everyone is entitled to his/her opinion,
but I don't honestly believe these are fair statements to make.


> The original statement by Monty Taylor is clear to me:
>
> I wish to boot an instance that is on a public network and reachable
> without madness.
>
> As of today, you can't unless you implement a deployer/provider specific
> solution (to scale said network). Just take a look at what actual public
> cloud providers are doing:
>
> - Rackspace has a "magic" public network
> - GoDaddy has custom code in their nova-scheduler (AFAIK)
> - iWeb (which I work for) has custom code in front of nova-api.
>
> We are all writing our own custom code to implement what (we feel)
> Neutron should be providing right off the bat.
>

What is that you think Neutron should be providing right off the bat? I
personally have never seen you publicly report usability issues that
developers could go and look into. Let's escalate these so that the Neutron
team can be aware.


>
> By reading the openstack-dev [1], openstack-operators [2] lists, Neutron
> specs [3] and the Large Deployment Team meeting notes [4], you will see
> that what is suggested here (a scalable public shared network) is an
> objective we wish but are struggling hard to achieve.
>

There are many ways to skin this cat IMO, and scalable public shared
network can really have multiple meanings, I appreciate the pointers
nonetheless.


>
> People keep asking for simplicity and Neutron looks to not be able to
> offer it due to philosophical conflicts between Neutron developers and
> actual public users/operators. We can't force our users to adhere to ONE
> networking philosophy: use NAT, floating IPs, firewall, routers, etc.
> They just don't buy it. Period. (see monty's list of public providers
> attaching VMs to public network)
>

Public providers networking needs are not the only needs that Neutron tries
to gather. There's a balance to be struck, and I appreciate that the
balance may need to be adjusted, but being so dismissive is being myopic of
the entire industry landscape.


>
> If we can accept and agree that not everyone wishes to adhere to the
> "full stack of networking good practices" (TBH, I don't know how to call
> this thing), it will be a good start. Otherwise I feel we won't be able
> to achieve anything.
>
> What Monty is explaining and suggesting is something we (my team) have
> been struggling with for *years* and just didn't have bandwidth (we are
> operators, not developers) or public charisma to change.
>
> I'm glad Monty brought up this subject so we can officially address it.
>
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2015-July/070028.html
> [2]
>
> http://lists.openstack.org/pipermail/openstack-operators/2015-August/007857.html
> [3]
>
> http://specs.openstack.org/openstack/neutron-specs/specs/liberty/get-me-a-network.html
> [4]
>
> http://lists.openstack.org/pipermail/openstack-operators/2015-June/007427.html
>
> --
> Mathieu
>
> __
> OpenStack Development Mailing 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-

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Armando M.]

On 15 September 2015 at 16:01, Monty Taylor  wrote:

> On 09/15/2015 06:16 PM, Armando M. wrote:
>
>>
>>
>> On 15 September 2015 at 08:27, Mike Spreitzer > <mailto:mspre...@us.ibm.com>> wrote:
>>
>> Monty Taylor mailto:mord...@inaugust.com>>
>> wrote on 09/15/2015 11:04:07 AM:
>>
>> > a) an update to python-novaclient to allow a named network to be
>> passed
>> > to satisfy the "you have more than one network" - the nics
>> argument is
>> > still useful for more complex things
>>
>> I am not using the latest, but rather Juno.  I find that in many
>> places the Neutron CLI insists on a UUID when a name could be used.
>> Three cheers for any campaign to fix that.
>>
>>
>> The client is not particularly tied to a specific version of the server,
>> so we don't have a Juno version, or a Kilo version, etc. (even though
>> they are aligned, see [1] for more details).
>>
>> Having said that, you could use names in place of uuids pretty much
>> anywhere. If your experience says otherwise, please consider filing a
>> bug against the client [2] and we'll get it fixed.
>>
>
> May just be a help-text bug in novaclient then:
>
>   --nic
> 
> Create a NIC on the server. Specify option
> multiple times to create multiple NICs.
> net-
> id: attach NIC to network with this UUID
> (either port-id or net-id must be
> provided),
> v4-fixed-ip: IPv4 fixed address for NIC
> (optional), v6-fixed-ip: IPv6 fixed address
> for NIC (optional), port-id: attach NIC to
> port with this UUID (either port-id or
> net-id
> must be provided).
>

Ok, if you're asking for the ability to boot network by name (assumed
that's unique), then that can be sorted. I filed a novaclient bug [1].
Volunteers welcome!

[1] https://bugs.launchpad.net/python-novaclient/+bug/1496180


>
>
>
> Thanks,
>> Armando
>>
>> [1] https://launchpad.net/python-neutronclient/+series
>> [2] https://bugs.launchpad.net/python-neutronclient/+filebug
>>
>>
>>
>> And, yeah, creating VMs on a shared public network is good too.
>>
>> Thanks,
>> mike
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> <http://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] [nova][neutron][devstack] New proposed 'default' network model

[Armando M.]

On 15 September 2015 at 16:08, Monty Taylor  wrote:

> On 09/15/2015 06:30 PM, Armando M. wrote:
>
>>
>>
>> On 15 September 2015 at 08:04, Monty Taylor > <mailto:mord...@inaugust.com>> wrote:
>>
>> Hey all!
>>
>> If any of you have ever gotten drunk with me, you'll know I hate
>> floating IPs more than I hate being stabbed in the face with a very
>> angry fish.
>>
>> However, that doesn't really matter. What should matter is "what is
>> the most sane thing we can do for our users"
>>
>> As you might have seen in the glance thread, I have a bunch of
>> OpenStack public cloud accounts. Since I wrote that email this
>> morning, I've added more - so we're up to 13.
>>
>> auro
>> citycloud
>> datacentred
>> dreamhost
>> elastx
>> entercloudsuite
>> hp
>> ovh
>> rackspace
>> runabove
>> ultimum
>> unitedstack
>> vexxhost
>>
>> Of those public clouds, 5 of them require you to use a floating IP
>> to get an outbound address, the others directly attach you to the
>> public network. Most of those 8 allow you to create a private
>> network, to boot vms on the private network, and ALSO to create a
>> router with a gateway and put floating IPs on your private ip'd
>> machines if you choose.
>>
>> Which brings me to the suggestion I'd like to make.
>>
>> Instead of having our default in devstack and our default when we
>> talk about things be "you boot a VM and you put a floating IP on it"
>> - which solves one of the two usage models - how about:
>>
>> - Cloud has a shared: True, external:routable: True neutron network.
>> I don't care what it's called  ext-net, public, whatever. the
>> "shared" part is the key, that's the part that lets someone boot a
>> vm on it directly.
>>
>> - Each person can then make a private network, router, gateway, etc.
>> and get floating-ips from the same public network if they prefer
>> that model.
>>
>> Are there any good reasons to not push to get all of the public
>> networks marked as "shared"?
>>
>>
>> The reason is simple: not every cloud deployment is the same: private is
>> different from public and even within the same cloud model, the network
>> topology may vary greatly.
>>
>
> Yes. Many things may be different.
>
> Perhaps Neutron fails in the sense that it provides you with too much
>> choice, and perhaps we have to standardize on the type of networking
>> profile expected by a user of OpenStack public clouds before making
>> changes that would fragment this landscape even further.
>>
>> If you are advocating for more flexibility without limiting the existing
>> one, we're only making the problem worse.
>>
>
> I am not. I am arguing for a different arbitrary 'default' deployment.
> Right now the verbiage around things is "floating IPs is the 'right' way to
> get access to public networks"
>
> I'm not arguing for code changes, or more options, or new features.
>
> I'm saying that there a set of public clouds that provide a default
> experience out of the box that is pleasing with neutron today, and we
> should have the "I don't know what I want tell me what to do" option behave
> like those clouds.
>
> Yes. You can do other things.
> Yes. You can get fancy.
> Yes. You can express all of the things.
>
> Those are things I LOVE about neutron and one of the reasons I think that
> the arguments around neutron and nova-net are insane.
>
> I'm just saying that "I want a computer on the externally facing network
> from this cloud" is almost never well served by floating-ips unless you
> know what you're doing, so rather than leading people down the road towards
> that as the default behavior, since it's the HARDER thing to deal with -
> let's lead them to the behavior which makes the simple thing simple and
> then clearly open the door to them to increasingly complex and powerful
> things over time.


I can get behind this statement, but all I am trying to say is that Neutron
gives you the toolkit. How, as a deployer you use it, it's up to you. A
deployer can today implement a shared publicly facing network on which VM's
can connect to without problems. Now the issue may come from a user point
of view: does the user may need to spe

[openstack-dev] [Neutron] PTL Candidacy

[Armando M.]

I would like to propose my candidacy for the Neutron PTL.

If you are reading this and you know me, then you probably know what I have
been up to up until now, what I have done for the project, and what I may
continue to do. If you do not know me, and you are still interested in
reading, then I will try not bore you.

As member of this project, I have been involved with it since the early
days, and I have served as core developer since Havana. If you are
wondering whether I am partially to blame for the issues that affect
Neutron, well you may have a point, but keep reading...

I believe that Neutron itself is a unique project and as such has unique
challenges. We have grown tremendously mostly propelled by a highly
opinionated vendor perspective. This has caused us some problems and we set
foot a cycle or so ago to fix these, but at the same time stay true to the
nature of our mission: define logical abstractions, and related
implementations to provide on-demand, cloud oriented networking services.

As any other project in OpenStack, we are software and we mostly implement
'stuff' in software, and because of that we are prone to all the issues
that a software project may have. To this aim, going forward I would like
us to improve the following:


   - Stability is the priority: new features are important, but complete
   and well tested existing features are more important; we gotta figure out a
   way to bring the number of bugs down to a manageable number, just like
   nations are asked to keep their sovereign debt below a certain healthy
   threshold.
   - Narrow the focus: now that the Neutron 'stadium' is here with us,
   external plugins and drivers can integrate with Neutron in a loosely
   manner, giving the core the opportunity to be more razor focus at getting
   better at what we do: logical abstractions and pluggability.
   - Consistency is paramount: having grown the review team drastically
   over the past cycle, it is easy to skew quality in one area over an other.
   We need to start defining common development and reviewer practices so
   that, even though we deal are made of many sub-projects and modules, we
   operate, feel and look like one...just like OpenStack :)
   - Define long term strategy: we need to have an idea where Neutron start
   and where Neutron end. At some point, this project will reach enough
   maturity where we feel like we are 'done' and that's okay. Some of us will
   move on to the next big thing.
   - Keep developers and reviewers _aware_: we all have to work
   collectively towards a common set of goals, defined by the release cycle.
   We will have to learn to push back on _random_ forces that keep distracting
   us.
   - I would like to promote a 'you merge it, you own it' type of
   mentality: even though we are pretty good at it already, we need a better
   balance between reviews and contributions. If you bless a patch, you got to
   be prepared to dive into the issues that it may potentially causes. If you
   bless a patch, you got to be prepared to improve the code around it, and so
   on. You will be a better reviewer if you learn to live with the pain of
   your mistakes. This is he only way to establish a virtuous cycle where
   quality improves time over time.

And last but not least:


   - Improve the relationships with other projects: Nova and QA primarily.
   We should allocate enough bandwidth to address integration issues with Nova
   and the other emerging projects, so that we stay plugged with them. QA is
   also paramount so that no-one is gonna hate us because we send the gate
   belly up. As for nova-network, I must admit I am highly skeptical by now:
   if our community were a commercial enterprise trying to solve that problem
   we would have ran out of money long time ago. We tried time and time again
   to crack this nut open, and even though we made progress in a number of
   areas, we haven't really budged where some people felt it mattered. We need
   to recognize that the problem is not just technical...it is social; no-one,
   starting from the developers and the employers behind them, seems to be
   genuinely concerned with the need of making nova-network a thing of the
   past. They have other priorities, they are chasing new customers, they want
   to disrupt Amazon. None of this nova-network deprecation drama fits with
   their agendas and furthermore, even if we found non-corporate sponsored
   developers willing to work on it, let's face it migration is a problem that
   is really not that interesting to solve. So where do we go from here? I do
   not have a clear answer yet. However, I think we all agree that the Neutron
   team wants to make Neutron a better product, more aligned with the needs of
   our users, but we must recognize that _better_ does not mean *like*
   nova-network, because the two products are not the same and they never will
   be.

Ok, now that you read this, you are ready to know whether you may want 

[openstack-dev] [gate] requirement conflict on Babel breaks grenade jobs

[Armando M.]

https://bugs.launchpad.net/grenade/+bug/1496650

HTH
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] Effective Neutron

[Armando M.]

Hi fellow developers and reviewers,

Some of you may have noticed that I put together patch [1] up for review.

The intention of this initiative is to capture/share 'pills of wisdom' when
it comes to Neutron development and reviewing. In fact, there are a number
of common patterns (or anti-patterns) that we keep stumbling on, and I came
to the realization that if we all stopped for a second and captured those
in writing for any newcomer (or veteran) to see, we would all benefit
during code reviews and development, because we'd all know what to watch
out for. The wishful thinking is that once this document reaches critical
mass, we will all have learned how to avoid common mistakes and get our
patches merged swiftly.

It is particularly aimed at the Neutron contributor and it is not meant to
replace the wealth of information that is available on doc.openstack.org,
the wiki or the Internet. This is also not meant to be a cross-project
effort, because let's face it...every project is different, and pills of
wisdom in Neutron may as well be everyone's knowledge in Heat, etc.

I aim to add more material over the next couple of days, also with the help
of some of you, so bear with me while the patch is in WIP.

Feedback welcome.

Many thanks,
Armando

[1] https://review.openstack.org/#/c/224419/
__
OpenStack Development Mailing 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-ovn][vtep] Proposal: support for vtep-gateway in ovn

[Armando M.]

On 24 September 2015 at 09:12, Russell Bryant  wrote:

> On 09/24/2015 10:18 AM, Salvatore Orlando wrote:
> > One particular issue is that the project implements the ovsdb
> protocol
> > from scratch.  The ovs project provides a Python library for this.
> Both
> > Neutron and networking-ovn use it, at least.  From some discussion,
> I've
> > gathered that the ovs Python library lacked one feature that was
> needed,
> > but has since been added because we wanted the same thing in
> > networking-ovn.
> >
> >
> > My take here is that we don't need to use the whole implementation of
> > networking-l2gw, but only the APIs and the DB management layer it
> exposes.
> > Networking-l2gw provides a VTEP network gateway solution that, if you
> > want, will eventually be part of Neutron's "reference" control plane.
> > OVN provides its implementation; I think it should be possible to
> > leverage networking-l2gw either by pushing an OVN driver there, or
> > implementing the same driver in openstack/networking-ovn.
>
> From a quick look, it seemed like networking-l2gw was doing 2 things.
>
>   1) Management of vtep switches themselves
>
>   2) Management of connectivity between Neutron networks and VTEP
>  gateways
>
> I figured the implementation of #1 would be the same whether you were
> using ML2+OVS, OVN, (or whatever else).  This part is not addressed in
> OVN.  You point OVN at VTEP gateways, but it's expected you manage the
> gateway provisioning some other way.
>
> It's #2 that has a very different implementation.  For OVN, it's just
> creating a row in OVN's northbound database.
>
> or did I mis-interpret what networking-l2gw is doing?
>

No, you did not misinterpret what the objective of the project were (which
I reinstate here):

* Provide an API to OpenStack admins to extend neutron logical networks
into unmanaged pre-existing vlans. Bear in mind that things like address
collision prevention is left in the hands on the operator. Other aspects
like L2/L3 interoperability instead should be taken care of, at least from
an implementation point of view.

* Provide a pluggable framework for multiple drivers of the API.

* Provide an PoC implementation on top of the ovsdb vtep schema. This can
be implemented both in hardware (ToR switches) and software (software L2
gateways).



>
> > The networking-l2gw route will require some pretty significant work.
> > It's still the closest existing effort, so I think we should explore
> it
> > until it's absolutely clear that it *can't* work for what we need.
>

We may have fallen short of some/all expectations, but I would like to
believe than it is nothing that can't be fixed by iterating on, especially
if active project participation raises.

I don't think there's a procedural mandate to make OVN abide by the l2gw
proposed API. As you said, it is not a clear well accepted API, but that's
only because we live in a brand new world, where people should be allowed
to experiment and reconcile later as community forces play out.

That said, should the conclusion that "it (the API) *can't* work for what
OVN needs" be reached, I would like to understand/document why for the sake
of all us involved so that lessons will yield from our mistakes.

>
> >
> > I would say that it is definitely not trivial but probably a bit less
> > than "significant". abhraut from my team has done something quite
> > similar for openstack/vmware-nsx [1]
>
> but specific to nsx.  :(
>
> Does it look like networking-l2gw could be a common API for what's
> needed for NSX?
>
> >
> >
> > > OR
> > >
> > > Should OVN pursue it’s own Neutron extension (including vtep
> gateway
> > > support).
> >
> > I don't think this option provides a lot of value over the short term
> > binding:profile solution.  Both are OVN specific.  I think I'd rather
> > just stick to binding:profile as the OVN specific stopgap because
> it's a
> > *lot* less work.
> >
> >
> > I totally agree. The solution based on the binding profile is indeed a
> > decent one in my opinion.
> > If OVN cannot converge on the extension proposed by networking-l2gw then
> > I'd keep using the binding profile for specifying gateway ports.
>
> Great, thanks for the feedback!
>
> > [1] https://review.openstack.org/#/c/210623/
>
> --
> Russell Bryant
>
> __
> OpenStack Development Mailing 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] [cinder][neutron][all] New third-party-ci testing requirements for OpenStack Compatible mark

[Armando M.]

On 25 September 2015 at 15:40, Chris Hoge  wrote:

> In November, the OpenStack Foundation will start requiring vendors
> requesting
> new "OpenStack Compatible" storage driver licenses to start passing the
> Cinder
> third-party integration tests.

The new program was approved by the Board at
> the July meeting in Austin and follows the improvement of the testing
> standards
> and technical requirements for the "OpenStack Powered" program. This is all
> part of the effort of the Foundation to use the OpenStack brand to
> guarantee a
> base-level of interoperability and consistency for OpenStack users and to
> protect the work of our community of developers by applying a trademark
> backed
> by their technical efforts.
>
> The Cinder driver testing is the first step of a larger effort to apply
> community determined standards to the Foundation marketing programs. We're
> starting with Cinder because it has a successful testing program in place,
> and
> we have plans to extend the program to network drivers and OpenStack
> applications. We're going require CI testing for new "OpenStack Compatible"
> storage licenses starting on November 1, and plan to roll out network and
> application testing in 2016.
>
> One of our goals is to work with project leaders and developers to help us
> define and implement these test programs. The standards for third-party
> drivers and applications should be determined by the developers and users
> in our community, who are experts in how to maintain the quality of the
> ecosystem.
>
> We welcome and feedback on this program, and are also happy to answer any
> questions you might have.
>

Thanks for spearheading this effort.

Do you have more information/pointers about the program, and how Cinder in
particular is
paving the way for other projects to follow?

Thanks,
Armando


> Thanks!
>
> Chris Hoge
> Interop Engineer
> OpenStack Foundation
> __
> OpenStack Development Mailing 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] congrats to armax!

[Armando M.]

On 25 September 2015 at 17:03, Ryan Moats  wrote:

> First, congratulations to armax on being elected PTL for Mitaka. Looking
> forward to Neutron improving over the next six months.
>
> Second thanks to everybody that voted in the election. Hopefully we had
> something close to 100% turnout, because that is an important
> responsibility of the population.
>

My humble thanks. I'll do my best to serve this community well, and not
disappoint the trust given.

Cheers,
Armando

>
>
> Ryan
>
> __
> OpenStack Development Mailing 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] [Openstack-operators] [neutron] [nova] Nova Network/Neutron Migration Survey - need response from folks currently using Nova Networks in their deployments

[Armando M.]

On 28 September 2015 at 18:01, Kruithof, Piet 
wrote:

> There has been a significant response to the Nova Network/Neutron
> migration survey.  However, the responses are leaning heavily on the side
> of deployments currently using Neutron.  As a result, we would like to have
> more representation from folks currently using Nova Networks.
>

Well, that in itself it's telling...


>
> If you are currently using Nova Networks, please respond to the survey!
>
> You will also be entered in a raffle for one of two $100 US Amazon gift
> cards at the end of the survey.   As always, the results from the survey
> will be shared with the OpenStack community.
>
> Please click on the following link to begin the survey.
>
> https://www.surveymonkey.com/r/osnetworking
>
>
> Piet Kruithof
> PTL, OpenStack UX project
>
> "For every complex problem, there is a solution that is simple, neat and
> wrong.”
>
> H L Menken
>
> __
> OpenStack Development Mailing 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] Defeact management

[Armando M.]

Hi folks,

One of the areas I would like to look into during the Mitaka cycle is
'stability' [1]. The team has done a great job improving test coverage, and
at the same time increasing reliability of the product.

However, regressions are always around the corner, and there is a huge
backlog of outstanding bugs (800+ of new/confirmed/triaged/in progress
actively reported) that pressure the team. Having these slip through the
cracks or leave them lingering is not cool.

To this aim, I would like to propose a number of changes in the way the
team manage defeats, and I will be going through the process of proposing
these changes via code review by editing [2] (like done in [3]).

Feedback most welcome.

Many thanks,
Armando


[1]
http://git.openstack.org/cgit/openstack/election/tree/candidates/mitaka/Neutron/Armando_Migliaccio.txt#n25
[2] http://docs.openstack.org/developer/neutron/policies/index.html
[3] https://review.openstack.org/#/c/228733/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] pypi packages for networking sub-projects

[Armando M.]

On 30 September 2015 at 16:02, Cathy Zhang  wrote:

> Hi Kyle,
>
>
>
> Is this only about the sub-projects that are ready for release? I do not
> see networking-sfc sub-project in the list. Does this mean we have done the
> pypi registrations for the networking-sfc project correctly or it is not
> checked because it is not ready for release yet?
>

Can't speak for Kyle, but with these many meaty patches in flight [1], I
think it's fair to assume that although the mechanisms are in place, Kyle
is not going to release the project at this time; networking-sfc release is
independent, we can publish the project when the time is ripe.

Cheers,
Armando

[1]
https://review.openstack.org/#/q/status:open+project:openstack/networking-sfc,n,z


>
>
> Thanks,
>
> Cathy
>
>
>
> *From:* Kyle Mestery [mailto:mest...@mestery.com]
> *Sent:* Wednesday, September 30, 2015 11:55 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [neutron] pypi packages for networking
> sub-projects
>
>
>
> Folks:
>
> In trying to release some networking sub-projects recently, I ran into an
> issue [1] where I couldn't release some projects due to them not being
> registered on pypi. I have a patch out [2] which adds pypi publishing jobs,
> but before that can merge, we need to make sure all projects have pypi
> registrations in place. The following networking sub-projects do NOT have
> pypi registrations in place and need them created following the guidelines
> here [3]:
>
> networking-calico
>
> networking-infoblox
>
> networking-powervm
>
>
>
> The following pypi registrations did not follow directions to enable
> openstackci has "Owner" permissions, which allow for the publishing of
> packages to pypi:
>
> networking-ale-omniswitch
>
> networking-arista
>
> networking-l2gw
>
> networking-vsphere
>
>
> Once these are corrected, we can merge [2] which will then allow the
> neutron-release team the ability to release pypi packages for those
> packages.
>
> Thanks!
>
> Kyle
>
>
> [1]
> http://lists.openstack.org/pipermail/openstack-infra/2015-September/003244.html
> [2] https://review.openstack.org/#/c/229564/1
> [3]
> http://docs.openstack.org/infra/manual/creators.html#give-openstack-permission-to-publish-releases
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] New cycle started. What are you up to, folks?

[Armando M.]

On 1 October 2015 at 06:45, Ihar Hrachyshka  wrote:

> Hi all,
>
> I talked recently with several contributors about what each of us plans
> for the next cycle, and found it’s quite useful to share thoughts with
> others, because you have immediate yay/nay feedback, and maybe find
> companions for next adventures, and what not. So I’ve decided to ask
> everyone what you see the team and you personally doing the next cycle, for
> fun or profit.
>
> That’s like a PTL nomination letter, but open to everyone! :) No
> commitments, no deadlines, just list random ideas you have in mind or in
> your todo lists, and we’ll all appreciate the huge pile of awesomeness no
> one will ever have time to implement even if scheduled for Xixao release.
>

You mean Xixao, once we have already rotated the alphabet? :)


>
> To start the fun, I will share my silly ideas in the next email.
>

Thanks for starting this thread. I think having people share ideas can be
useful to help us have a sense of what they are going to work on during the
next release. Obviously some of these ideas will eventually feed into
neutron-specs.

Kyle also tried to capture people's workload in [1] at one point. Perhaps
we can revisit that idea and develop it further based on your input here.

Definitely food for thought.

[1]
https://github.com/openstack/neutron-specs/blob/master/priorities/kilo-priorities.rst


>
> 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] New cycle started. What are you up to, folks?

[Armando M.]

On 1 October 2015 at 08:42, Sean M. Collins  wrote:

> On Thu, Oct 01, 2015 at 11:05:29AM EDT, Kyle Mestery wrote:
> > On Thu, Oct 1, 2015 at 9:57 AM, Sean M. Collins 
> wrote:
> >
> > > On Thu, Oct 01, 2015 at 10:02:24AM EDT, Ihar Hrachyshka wrote:
> > > > - more changes with less infra tinkering! neutron devs should not
> need
> > > to go to infra projects so often to make an impact;
> > > > -- make our little neat DevStack plugin used for qos and sr-iov only
> a
> > > huge pile of bash code that is currently stored in DevStack and is
> proudly
> > > called neutron-legacy now; and make the latter obsolete and eventually
> > > removed from DevStack;
> > >
> > > We may need to discuss this. I am currently doing a refactor of the
> > > Neutron DevStack integration in
> > >
> > > https://review.openstack.org/168438
> > >
> > > If I understand your message correctly, I disagree that we should be
> > > moving all the DevStack support for Neutron out of DevStack and making
> > > it a plugin. All that does is move the mess from one corner of the
> room,
> > > to another corner.
> > >
> > >
> > I would actually be in favor of cleaning up the mess AND moving it into
> > neutron. If it's in Neutron, we control our own destiny with regards to
> > landing patches which affect DevStack and ultimately our gate jobs. To
> me,
> > that's a huge win-win. Thus, cleanup first, then move to Neutron.
>
> Frankly we have a bad track record in DevStack, if we are to make an
> argument about controlling our own destiny. Neutron-lib is in a sad
> state of affairs because we haven't had the discipline to keep things
> simple.
>

IMO we can't make these statements otherwise what's the point in looking
forward if all we do is base our actions on some _indelible_ past?

As for the rest, I am gonna let this thread sink in a bit before I come up
with a more elaborate answer that this thread deserves.


>
> In fact, I think the whole genesis of the Neutron plugin for DevStack is
> a great example of how controlling our own destiny has started to grow
> the mess. Yes, we needed it to gate the QoS code. But now things are
> starting to get added.
>
>
> https://github.com/openstack/neutron/commit/bd07b74045d93c46483aa261b8686072d9b448e8
>
> The trend is now that people are going to throw things into the Neutron
> DevStack plugin to get their doo-dad up and running, because making a
> new repo is harder than creating a patch (which maybe shows are repo
> creation process needs streamlining). I was originally for making
> Neutron DevStack plugins that exist in their own repos, instead of
> putting them in the Neutron tree. At least that makes things small,
> manageable, and straight forward. Yes, it makes for more plugin lines in
> your DevStack configuration, but at least you know what each one does,
> instead of being an agglomeration.
>
> If we are not careful, the Neutron DevStack plugin will grow into the big
> mess that neutron-legacy is.
>
> Finally, Look at how many configuration knobs we have, and how there is
> a tendency to introduce new ones, instead of using local.conf to inject
> configuration into Neutron and the associated components. This ends up
> making it very complicated for someone to actually run Neutron in their
> DevStack, and I think a lot of people would give up and just run
> Nova-Network, which I will note is *still the default*.
>
> We need to keep our ties strong with other projects, and improve them in
> some cases. I think culturally, if we start trying to move things into
> our corner of the sandbox because working with other groups is hard, we
> send bad signals to others. This will eventually come back to bite us.
>
> /rant
>
> --
> 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] [Neutron] Defect management

[Armando M.]

Hi neutrinos,

Whilst we go down the path of revising the way we manage/process bugs in
Neutron, and transition to the proposed model [1], I was wondering if I can
solicit some volunteers to screen the bugs outlined in [2]. It's only 24
bugs so it should be quick ;)

Btw, you can play with filters and Google sheets Insights to see how well
(or bad) we've done this week.

Cheers,
Armando

[1] https://review.openstack.org/#/c/228733/
[2]
https://docs.google.com/spreadsheets/d/1UpxSOsFKQWN0IF-mN0grFJJap-j-8tnZHmG4f3JYmIQ/edit#gid=1296831500

On 28 September 2015 at 23:06, Armando M.  wrote:

> Hi folks,
>
> One of the areas I would like to look into during the Mitaka cycle is
> 'stability' [1]. The team has done a great job improving test coverage, and
> at the same time increasing reliability of the product.
>
> However, regressions are always around the corner, and there is a huge
> backlog of outstanding bugs (800+ of new/confirmed/triaged/in progress
> actively reported) that pressure the team. Having these slip through the
> cracks or leave them lingering is not cool.
>
> To this aim, I would like to propose a number of changes in the way the
> team manage defeats, and I will be going through the process of proposing
> these changes via code review by editing [2] (like done in [3]).
>
> Feedback most welcome.
>
> Many thanks,
> Armando
>
>
> [1]
> http://git.openstack.org/cgit/openstack/election/tree/candidates/mitaka/Neutron/Armando_Migliaccio.txt#n25
> [2] http://docs.openstack.org/developer/neutron/policies/index.html
> [3] https://review.openstack.org/#/c/228733/
>
__
OpenStack Development Mailing 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] AZ Support

[Armando M.]

On 4 October 2015 at 09:19, Gary Kotton  wrote:

> Hi,
> It appears that the addition has broken the vmware_nsx plugin (
> https://review.openstack.org/183369). We are still debugging. Would it be
> worthwhile considering adding this support as a feature branch and then
> when the entire feature is ready that we merge it to the tree. This will
> enable the external vendors to be alive and kicking.
>

Please let us know how we can help you to fix it. The CI hasn't voted on
this patch since May 14, so clearly the breakage flew under the radar.


> 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] Stable/liberty branches for decomposed plugins

[Armando M.]

On 4 October 2015 at 09:31, Gary Kotton  wrote:

> Hi,
> When should we start to create a stable/liberty branch for the decomposed
> plugins? My understanding is that the plugin should be in line with
> Neutron. Changes in Neutron master (now Mitaka) may require plugin changes.
> Any ideas or thoughts on the matter? I am in favour of creating the
> stable/liberty branch soon
> Thanks
>

If you are part of the Neutron subprojects, this is managed centrally by
the Neutron folks (in particular Kyle at the moment is the go-to guy). See
tips specified in [1,2].

HTH
Armando

[1]
http://docs-draft.openstack.org/33/228733/11/check/gate-neutron-docs/e423028//doc/build/html/policies/bugs.html#plugin-and-driver-repositories
[2]
http://docs.openstack.org/developer/neutron/devref/sub_project_guidelines.html


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

[Armando M.]

On 4 October 2015 at 10:00, Gary Kotton  wrote:

> The DHCP agent has the following exception:
>
> 2015-10-02 23:57:05.787 ERROR neutron.agent.dhcp.agent
> [req-17c3aa12-41fd-41f8-8e23-2f9740e50746 None None] Failed reporting state!
> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent Traceback (most
> recent call last):
> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File
> "/opt/stack/neutron/neutron/agent/dhcp/agent.py", line 572, in _report_state
> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent
> self.state_rpc.report_state(ctx, self.agent_state, self.use_call)
> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File
> "/opt/stack/neutron/neutron/agent/rpc.py", line 86, in report_state
> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent return
> method(context, 'report_state', **kwargs)
> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File
> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line
> 158, in call
> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent
> retry=self.retry)
> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File
> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/transport.py", line
> 90, in _send
> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent
> timeout=timeout, retry=retry)
> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File
> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py",
> line 431, in send
> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent retry=retry)
> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File
> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py",
> line 420, in _send
> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent result =
> self._waiter.wait(msg_id, timeout)
> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File
> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py",
> line 318, in wait
> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent message =
> self.waiters.get(msg_id, timeout=timeout)
> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent   File
> "/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py",
> line 223, in get
> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent 'to message ID
> %s' % msg_id)
> 2015-10-02 23:57:05.787 TRACE neutron.agent.dhcp.agent MessagingTimeout:
> Timed out waiting for a reply to message ID f4ed0bd26feb462c9b7b49a6d85caeae
>
> Now when I use the stable/liberty branch everything is OK
>
>
Ah, I suspect that's your culprit:

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

instead of AZ's initial support.


> Thanks
> Gary
>
> From: "Armando M." 
> Reply-To: OpenStack List 
> Date: Sunday, October 4, 2015 at 7:34 PM
> To: OpenStack List 
> Subject: Re: [openstack-dev] [Neutron] AZ Support
>
>
>
> On 4 October 2015 at 09:19, Gary Kotton  wrote:
>
>> Hi,
>> It appears that the addition has broken the vmware_nsx plugin (
>> https://review.openstack.org/183369). We are still debugging. Would it
>> be worthwhile considering adding this support as a feature branch and then
>> when the entire feature is ready that we merge it to the tree. This will
>> enable the external vendors to be alive and kicking.
>>
>
> Please let us know how we can help you to fix it. The CI hasn't voted on
> this patch since May 14, so clearly the breakage flew under the radar.
>
>
>> 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
>
>
__
OpenStack Development Mailing 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] Defect management

[Armando M.]

On 5 October 2015 at 03:14, Ihar Hrachyshka  wrote:

> > On 02 Oct 2015, at 02:37, Armando M.  wrote:
> >
> > Hi neutrinos,
> >
> > Whilst we go down the path of revising the way we manage/process bugs in
> Neutron, and transition to the proposed model [1], I was wondering if I can
> solicit some volunteers to screen the bugs outlined in [2]. It's only 24
> bugs so it should be quick ;)
>
> I am fine to be a guinea pig, though I don’t have edit access to the
> spreadsheet.
>
> Ihar
>

Thanks Ihar, the sheet is editable now. Polishing Launchpad should suffice
though.

Cheers,
Armando


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

[openstack-dev] [Neutron] Effective guide

[Armando M.]

Hi neutrinos,

One of the areas I would like to work on during the Mitaka cycle is
'consistency' [1].

We've grown quite a bit during the last cycle and we need to make sure we
are on the same page when it comes to code quality and reviews, and at the
same time speeding up review velocity without compromising stability [2].

This is the reason why I started the 'Effective Neutron' guide [3], with
the hope that we could start collating pills of wisdom that we identify
during Neutron reviews, and capture lessons learned from regressions we may
experience post merge.

To this aim, I would invite people to start collectively add content to the
guide. If you use the 'effective' tag [4], then it's easier to set them
apart from the rest, for speedy review.

If you are stumbling upon a bad pattern and you want to clean that up (like
Cedric did in [5]), adding a tip at the same time of the patch is also ok,
unless you pinky-swear you'll do that as follow up (the effective guide is
available from Liberty, so backports may cause a conflict should you want
to go back to Kilo).

Cheers,
Armando

[1]
http://git.openstack.org/cgit/openstack/election/tree/candidates/mitaka/Neutron/Armando_Migliaccio.txt#n33
[2]
http://git.openstack.org/cgit/openstack/election/tree/candidates/mitaka/Neutron/Armando_Migliaccio.txt#n25
[3]
http://docs.openstack.org/developer/neutron/devref/effective_neutron.html
[4]
https://review.openstack.org/#/q/project:openstack/neutron+topic:effective,n,z
[5] https://review.openstack.org/#/c/230823/
__
OpenStack Development Mailing 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] Remdiner: Team meeting on Tuesday at 1400 UTC

[Armando M.]

A kind reminder for tomorrow's meeting.

Please add agenda items to the meeting here [1].

See you all tomorrow!

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

Re: [openstack-dev] [cinder][neutron][all] New third-party-ci testing requirements for OpenStack Compatible mark

[Armando M.]

On 29 September 2015 at 08:28, Chris Hoge  wrote:

> On Sep 29, 2015, at 8:04 AM, Erlon Cruz  wrote:
>
>
> Hi Cris,
>
> There are some questions that came to my mind.
>
> Cinder has near zero tolerance to backends that does not have a CI
> running. So, can one assume that all drivers in Cinder will have the
> "OpenStack Compatible" seal?
>
>
> One of the reasons we started with Cinder was because they have
> have an existing program that is well maintained. Any driver passing
> CI becomes eligible for the "OpenStack Compatible” mark. It’s not
> automatic, and still needs a signed agreement with the Foundation.
>

> When you say that the driver have to 'pass' the integration tests, what
> tests do you consider? All tests in tempest? All patches? Do you have any
> criteria to determine if a backend is passing or not?
>
>
> We’re letting the project drive what tests need to be passed. So,
> taking a look at this dashboard[1] (it’s one of many that monitor
> our test systems) the drivers are running the dsvm-tempest-full
> tests. One of the things that the tests exercise, and we’re interested
> in from the driver standpoint, are both the user-facing Cinder APIs
> as well as the driver-facing APIs.
>

> For Neutron, which we would like to help roll out in the coming year,
> this would be a CI run that is defined by the Neutron development
> team. We have no interest in dictating to the developers what should
> be run. Instead, we want to adopt what the community considers
> to be the best-practices and standards for drivers.
>

We've experienced that tracking the CI's outcome on a per-commit basis can
only lead to insanity, at least as far as Neutron is concerned.

I have been mulling over the idea (I am sure I am not the only one) that
compliance should be sought and validated at specific milestones of
interest (when the stable branch is cut? When the milestone RC is ready?
etc). We can then collect the outcome of all the CI's reporting back,
vetting the output, verifying who is bogus and who isn't etc. The
post-processing will inevitably require some degree of manual intervention.
We can also ask for those results to be persistent for longer.

Is it something that would be acceptable?

Obviously the first step for us, Neutron, is to come up with a testing
suite(s) that's representative of all the various flavors of support that a
networking solution can provide when it claims to be integrated with
Neutron.


>
> About this "OpenStack Compatible" flag, how does it work? Will you hold a
> list with the Compatible vendors? Is anything a vendor need to to in order
> to use this?
>
>
> “OpenStack Compatible” is one of the trademark programs that is
> administered by the Foundation. A company that want to apply the
> OpenStack logo to their product needs to sign a licensing agreement,
> which gives them the right to use the logo in their marketing materials.
>
> We also create an entry in the OpenStack Marketplace for their
> product, which has information about the company and the product, but
> also information about tests that the product may have passed. The
> best example I can give right now is with the “OpenStack Powered”
> program, where we display which Defcore guideline a product has
> successfully passed[2].
>
> Chris
>
> [1] http://ci-watch.tintri.com/project?project=cinder&time=24+hours
> [2] For example:
> http://www.openstack.org/marketplace/public-clouds/unitedstack/uos-cloud
>
> Thanks,
> Erlon
>
> On Mon, Sep 28, 2015 at 5:55 PM, Kyle Mestery  wrote:
>
>> The Neutron team also discussed this in Vancouver, you can see the
>> etherpad here [1]. We talked about the idea of creating a validation suite,
>> and it sounds like that's something we should again discuss in Tokyo for
>> the Mitaka cycle. I think a validation suite would be a great step forward
>> for Neutron third-party CI systems to use to validate they work with a
>> release.
>>
>> [1] https://etherpad.openstack.org/p/YVR-neutron-third-party-ci-liberty
>>
>> On Sun, Sep 27, 2015 at 11:39 AM, Armando M.  wrote:
>>
>>>
>>>
>>> On 25 September 2015 at 15:40, Chris Hoge  wrote:
>>>
>>>> In November, the OpenStack Foundation will start requiring vendors
>>>> requesting
>>>> new "OpenStack Compatible" storage driver licenses to start passing the
>>>> Cinder
>>>> third-party integration tests.
>>>
>>> The new program was approved by the Board at
>>>> the July meeting in Austin and follows the improvement of the testing
>>>> standards
>>>> and technical requiremen

Re: [openstack-dev] [Neutron] Defect management

[Armando M.]

On 6 October 2015 at 06:10, Ihar Hrachyshka  wrote:

> > On 06 Oct 2015, at 10:36, Miguel Angel Ajo  wrote:
> >
> > Hi, I was trying to help a bit, for now, but I don't have access in
> launchpad to update importance,
> > etc.
> >
> > I will add comments on the bugs themselves, and set a ? in the
> spreadsheet.
>
> I believe you need to be a member of one of the following groups to have
> access to all LP fields:
>
> https://launchpad.net/~neutron-bugs
> https://launchpad.net/~neutron-drivers


No, I think only neutron-bugs should do. I saw Akihiro gave you rights, so
you should be good.

Kudos to you for helping!

Cheers,
Armando


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

[openstack-dev] [Neutron] [openstack-infra] stable changes to python-neutronclient unable to merge

[Armando M.]

Hi folks,

We are unable to merge stable changes to python-neutronclient (as shown in
[1,2]) because of the missing master fixes [3,4]. We should be able to
untangle Liberty with [5], but to unblock Kilo, I may need to squash [6]
with a cherry pick of [3] and wait [5] to merge.

Please bear with us until we get the situation sorted.

Cheers,
Armando

[1]
https://review.openstack.org/#/q/status:open+project:openstack/python-neutronclient+branch:stable/kilo,n,z
[2]
https://review.openstack.org/#/q/status:open+project:openstack/python-neutronclient+branch:stable/liberty,n,z
[3] https://review.openstack.org/#/c/231731/
[4] https://review.openstack.org/#/c/231797/
[5] https://review.openstack.org/#/c/231796/
[6] https://review.openstack.org/#/c/231797/
__
OpenStack Development Mailing 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] Prepare for expiration bugs without activity

[Armando M.]

On 7 October 2015 at 07:50, Ihar Hrachyshka  wrote:

> > On 06 Oct 2015, at 19:26, ZZelle  wrote:
> >
> > Hi everyone,
> >
> >
> > As decided during last neutron meeting[1], we try to let Launchpad
> expire outdated bugs.
> >
> > The status of every bug without activity in last year has been set to
> Incomplete and their assignee/milestone unset in order to let Launchpad
> expire them in 60 days[2].
> >
> > It gives us a 60-days window to "revive" expirable bugs[3] which are
> (sadly :)) still valid (by changing their status).
> >
>
> I went thru the whole list of expirable bugs and moved some of them back
> to Confirmed where it seems to apply, plus added tags. I believe now we
> should not loose anything valuable.
>

Thanks Ihar, much appreciated. I'll have another pass too.

>
> 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] [openstack-infra] stable changes to python-neutronclient unable to merge

[Armando M.]

On 6 October 2015 at 20:06, Armando M.  wrote:

> Hi folks,
>
> We are unable to merge stable changes to python-neutronclient (as shown in
> [1,2]) because of the missing master fixes [3,4]. We should be able to
> untangle Liberty with [5], but to unblock Kilo, I may need to squash [6]
> with a cherry pick of [3] and wait [5] to merge.
>
> Please bear with us until we get the situation sorted.
>
> Cheers,
> Armando
>
> [1]
> https://review.openstack.org/#/q/status:open+project:openstack/python-neutronclient+branch:stable/kilo,n,z
> [2]
> https://review.openstack.org/#/q/status:open+project:openstack/python-neutronclient+branch:stable/liberty,n,z
> [3] https://review.openstack.org/#/c/231731/
> [4] https://review.openstack.org/#/c/231797/
> [5] https://review.openstack.org/#/c/231796/
> [6] https://review.openstack.org/#/c/231797/
>
>
An update: Liberty is unjammed, but Kilo is still in progress.
__
OpenStack Development Mailing 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 - update

[Armando M.]

Hi folks,

As some of you may know, this summit we have 12 fishbowl sessions between
Wednesday and Thursday, and a full day on Friday for team get-together.

We broke down the 12 sessions in three separate tracks:

   - https://etherpad.openstack.org/p/mitaka-neutron-core-track
   - https://etherpad.openstack.org/p/mitaka-neutron-next-track
   - https://etherpad.openstack.org/p/mitaka-neutron-labs-track

Each track has its own theme and more details can be found on their
respective etherpads. Each session as a chair, and we'll work together to
prepare the content of the etherpad also based on the input provided in:

https://etherpad.openstack.org/p/neutron-mitaka-designsummit

The Friday's etherpad is available here:

   - https://etherpad.openstack.org/p/mitaka-neutron-unplugged-track
   

If you are planning to gather people together, please add your name and
topic to the list so that people can sign-up for attendance.

This summit, as any other summit, we'll have a lightning slot session:

   - https://etherpad.openstack.org/p/mitaka-neutron-labs-lighting-talks

Put your ideas down and 6 topics will selected for the 5 mins long talks.

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] Reminder: Team meeting on Monday at 2100 UTC

[Armando M.]

A kind reminder for today's meeting.

Please add agenda items to the meeting here [1].

See you all in a few hours!

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] liberty stable branch development

[Armando M.]

Hi folks,

A heads-up: we are currently experiencing a number of failures on the
stable/liberty for neutron [1].

Bear with us whilst we go through the painstaking process of fixing the
dependency issues that caused the recent grief.

Thanks,
Armando

[1]
https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:stable/liberty,n,z
__
OpenStack Development Mailing 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] Do not merge until further notice

[Armando M.]

Hi folks,

We are in the last hours of Liberty, let's pause for a second and consider
merging patches only if absolutely necessary. The gate is getting clogged
and we need to give priority to potential RC3 fixes or gate stability fixes.

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

Re: [openstack-dev] [Neutron] Do not merge until further notice

[Armando M.]

On 13 October 2015 at 16:55, Hirofumi Ichihara <
ichihara.hirof...@lab.ntt.co.jp> wrote:

>
>
> > On 2015/10/14, at 4:07, Armando M.  wrote:
> >
> > Hi folks,
> >
> > We are in the last hours of Liberty, let's pause for a second and
> consider merging patches only if absolutely necessary. The gate is getting
> clogged and we need to give priority to potential RC3 fixes or gate
> stability fixes.
> Gate only? Should we prevent jenkins check from running too? In other
> words, shouldn’t we upload new commit?
>

New commits are fine :)


>
>
>
> >
> > Thanks,
> > Armando
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing 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] Revision of the RFE/blueprint submission process

[Armando M.]

Hi neutrinos,

>From last cycle, the team has introduced the concept of RFE bugs [0]. I
have suggested a number of refinements over the past few days [1,2,3] to
streamline/clarify the process a bit further, also in an attempt to deal
with the focus and breadth of the project [4,5].

Having said that, I would invite not to give anything for granted, and use
the ML and/or join us on the #openstack-neutron-release irc channel to tell
us what works and what doesn't about the processes we have in place.

There's no improvement without feedback!

Cheers,
Armando

[0]
http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements
[1] https://review.openstack.org/#/c/231819/
[2] https://review.openstack.org/#/c/234491/
[3] https://review.openstack.org/#/c/234502/
[4]
http://git.openstack.org/cgit/openstack/election/tree/candidates/mitaka/Neutron/Armando_Migliaccio.txt#n29
[5]
http://git.openstack.org/cgit/openstack/election/tree/candidates/mitaka/Neutron/Armando_Migliaccio.txt#n38
[6]
http://docs.openstack.org/developer/neutron/policies/office-hours.html#neutron-ptl-office-hours
__
OpenStack Development Mailing 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] Functional job instability

[Armando M.]

Hi folks,

There are a number of outstanding stability issues that affect the
functional job [1]. No particular bug is a major offender, but taken all
together they hurt quite a bit.

If we don't get a good handle on this (even on a 'good' day there is a wide
gap between the job failure rate and the others'), this can set us back
unnecessarily to a point where we're forced to make it non-voting...and
that's a slippery slope no-one wants to go down to.

Can I ask you the following:

- be extra careful when reviewing functional tests: make sure they are not
a potential source of race conditions;
- let's take the next couple of weeks (with the summit going on etc) to use
the time carefully to review outstanding stability fixes and triaging
existing stability issues.

Cosmetic changes, or minor/trivial enhancements that cause the job to be
exercised should not take the priority out of your day-to-day Neutron
contributions.

Many thanks,
Armando

[1]
https://bugs.launchpad.net/neutron/+bugs?field.tag=functional-tests&orderby=status&start=0
[2]
http://docs.openstack.org/developer/neutron/dashboards/check.dashboard.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] [release] establishing release liaisons for mitaka

[Armando M.]

On 14 October 2015 at 08:25, Doug Hellmann  wrote:

> As with the other cross-project teams, the release management team
> relies on liaisons from each project to be available for coordination of
> work across all teams. It's the start of a new cycle, so it's time to
> find those liaison volunteers.
>
> We are working on updating the release documentation as part of the
> Project Team Guide. Release liaison responsibilities are documented in
> [0], and we will update that page with more details over time.
>
> In the past we have defaulted to having the PTL act as liaison if no
> alternate is specified, and we will continue to do that during Mitaka.
> If you plan to delegate release work to a liaison, especially for
> submitting release requests, please update the wiki [1] to provide their
> contact information. If you plan to serve as your team's liaison, please
> add your contact details to the page.
>

Just to be clear: for Neutron, Kyle Mestery has kindly volunteered to
continue to act as release liaison, so the wiki is up to date.

I am eternally grateful to Kyle for taking on this critical task, as well
as to the wider release team.


>
> Thanks,
> Doug
>
> [0]
> http://docs.openstack.org/project-team-guide/release-management.html#release-liaisons
> [1]
> https://wiki.openstack.org/wiki/CrossProjectLiaisons#Release_management
>
> __
> OpenStack Development Mailing 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] Revision of the RFE/blueprint submission process

[Armando M.]

On 14 October 2015 at 00:17, Flavio Percoco  wrote:

> On 13/10/15 18:38 -0700, Armando M. wrote:
>
>> Hi neutrinos,
>>
>> From last cycle, the team has introduced the concept of RFE bugs [0]. I
>> have
>> suggested a number of refinements over the past few days [1,2,3] to
>> streamline/
>> clarify the process a bit further, also in an attempt to deal with the
>> focus
>> and breadth of the project [4,5].
>>
>> Having said that, I would invite not to give anything for granted, and
>> use the
>> ML and/or join us on the #openstack-neutron-release irc channel to tell
>> us what
>> works and what doesn't about the processes we have in place.
>>
>> There's no improvement without feedback!
>>
>
> Thanks for sharing.
>
> In Glance, we're about to jump into a very similar workflow and I'm
> glad to know it's worked for the neutron team so far.
>
> I'll be posting this on the mailing list soon and we can share
> feedback and experiences as they happen.
>

Thanks Flavio, I'd be happy to exchange notes. Every project is different
so I would expect that you would make adjustments. I would be keen to see
what we can borrow/share.

Btw, I am still working on some fine tuning, so stay...tuned :)

Cheers,
Armando


>
> Cheers,
> Flavio
>
>
>> Cheers,
>> Armando
>>
>> [0] http://docs.openstack.org/developer/neutron/policies/blueprints.html#
>> neutron-request-for-feature-enhancements
>> [1] https://review.openstack.org/#/c/231819/
>> [2] https://review.openstack.org/#/c/234491/
>> [3] https://review.openstack.org/#/c/234502/
>> [4]
>> http://git.openstack.org/cgit/openstack/election/tree/candidates/mitaka/
>> Neutron/Armando_Migliaccio.txt#n29
>> [5]
>> http://git.openstack.org/cgit/openstack/election/tree/candidates/mitaka/
>> Neutron/Armando_Migliaccio.txt#n38
>> [6]
>> http://docs.openstack.org/developer/neutron/policies/office-hours.html#
>> neutron-ptl-office-hours
>>
>
> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> --
> @flaper87
> Flavio Percoco
>
> __
> OpenStack Development Mailing 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] Revision of the RFE/blueprint submission process

[Armando M.]

A follow-up...

On 13 October 2015 at 18:38, Armando M.  wrote:

> Hi neutrinos,
>
> From last cycle, the team has introduced the concept of RFE bugs [0]. I
> have suggested a number of refinements over the past few days [1,2,3] to
> streamline/clarify the process a bit further, also in an attempt to deal
> with the focus and breadth of the project [4,5].
>
> Having said that, I would invite not to give anything for granted, and use
> the ML and/or join us on the #openstack-neutron-release irc channel to tell
> us what works and what doesn't about the processes we have in place.
>
> There's no improvement without feedback!
>

We have 400+ blueprints lingering [1], most of them are now rotten. In
order to try and improve the situation I also refined/proposed changes
about how we register/use blueprints [2]. Comments are welcome.

I will go through the pile, and the painstaking effort of cleaning up the
list.

Cheers,
Armando

[1] https://blueprints.launchpad.net/neutron/+specs
[2] https://review.openstack.org/#/c/235640


>
> Cheers,
> Armando
>
> [0]
> http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements
> [1] https://review.openstack.org/#/c/231819/
> [2] https://review.openstack.org/#/c/234491/
> [3] https://review.openstack.org/#/c/234502/
> [4]
> http://git.openstack.org/cgit/openstack/election/tree/candidates/mitaka/Neutron/Armando_Migliaccio.txt#n29
> [5]
> http://git.openstack.org/cgit/openstack/election/tree/candidates/mitaka/Neutron/Armando_Migliaccio.txt#n38
> [6]
> http://docs.openstack.org/developer/neutron/policies/office-hours.html#neutron-ptl-office-hours
>
__
OpenStack Development Mailing 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] proactive backporting

[Armando M.]

On 16 October 2015 at 10:09, Sean M. Collins  wrote:

> On Fri, Oct 16, 2015 at 11:36:13AM EDT, Salvatore Orlando wrote:
> > It might also make sense to ask contributors to resume the habit of
> tagging
> > bugs with 'backport-potential' even if not in the RC period.
>
> I like this idea because it'll make Ihar's job easier :)
>

I am in!! I made sure the stable branch policy [1] is evangelized through
the bug report guidelines [2] so that people get more and more comfortable
tagging 'backport-potential' bugs themselves when they file reports.

[1] https://wiki.openstack.org/wiki/StableBranch#Stable_branch_policy
[2]
http://docs.openstack.org/developer/neutron/policies/bugs.html#bug-screening-best-practices


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

[openstack-dev] [Neutron] Design Summit Lighting talks

[Armando M.]

Folks,

The session [1] is planned for Thursday at 3.30pm. If you're interested,
please sign up. The time to submit ideas is running out.

Cheers,
Armando

[1] https://etherpad.openstack.org/p/mitaka-neutron-labs-lighting-talks
__
OpenStack Development Mailing 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] proactive backporting

[Armando M.]

On 16 October 2015 at 15:14, Fox, Kevin M  wrote:

> Then how about the alternate approach of:
>
> For bug fixes, copying an existing in tree unit test and tweaking it
> slightly to test for the bug is sufficient to get it accepted instead of
> forcing it to be rewritten in whatever the new hotness for testing at the
> time thing is, that no one has good examples for, nor has fully agreed on
> what a good example of that looks like, leading to long delays in the big
> fix being accepted? IMHO, bug fixes aren't the place to trail blaze unit
> tests.
>

> The unit tests can be rewritten to be "better" in a follow up review that
> doesn't necessarily need to be back ported.
>

I am pretty confident that the experience you went through was an exception
rather than the rule. We're pretty flexible and allow a patch to go in
(master) with a promise of a follow up, if it's critical backport. The
important thing is to identify that...and this is what Ihar is talking
about in this thread.

It is noteworthy that 'trail blazing' as you say makes the patch difficult
to backport, so any advice given in this direction was clearly pointing you
the wrong way.


>
> Would that work?
>

> Thanks,
> Kevin
>
> --
> *From:* Kevin Benton [blak...@gmail.com]
> *Sent:* Friday, October 16, 2015 2:32 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [neutron][stable] proactive backporting
>
> We can't put in code and just hope for testing later. The tests are even
> more important in back-ports because there could be unexpected differences
> in the stable branch that make the patch not work correctly.
>
> However, we do need to make sure that people aren't complaining about the
> testing methodology in the back-ports because it's too late for that.
>
> On Fri, Oct 16, 2015 at 2:23 PM, Fox, Kevin M  wrote:
>
>> It would also help if the process could split out bug fixes from unit
>> tests. I had a bug fix get stuck while the unit tests were bikesheded for a
>> while, and then the delay of not getting quickly backported to the stable
>> branches then kicked in. All the while I had to patch production clouds by
>> hand with a non upstreamed fix. I'm all for having unit tests to ensure the
>> bugs don't creep back in, but regression bugs should be fixed as quickly as
>> possible.
>>
>> Thanks,
>> Kevin
>> 
>> From: Edgar Magana [edgar.mag...@workday.com]
>> Sent: Friday, October 16, 2015 2:04 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [neutron][stable] proactive backporting
>>
>> + 2 and total support for it.
>>
>> Looking forward to reviewing the first set of them.
>>
>> Edgar
>>
>>
>>
>> On 10/16/15, 5:33 AM, "Ihar Hrachyshka"  wrote:
>>
>> >Hi all,
>> >
>> >I’d like to introduce a new initiative around stable branches for
>> neutron official projects (neutron, neutron-*aas, python-neutronclient)
>> that is intended to straighten our backporting process and make us more
>> proactive in fixing bugs in stable branches. ‘Proactive' meaning: don’t
>> wait until a known bug hits a user that consumes stable branches, but
>> backport fixes in advance quickly after they hit master.
>> >
>> >The idea is simple: every Fri I walk thru the new commits merged into
>> master since last check; produce lists of bugs that are mentioned in
>> Related-Bug/Closes-Bug; paste them into:
>> >
>> >https://etherpad.openstack.org/p/stable-bug-candidates-from-master
>> >
>> >Then I click thru the bug report links to determine whether it’s worth a
>> backport and briefly classify them. If I have cycles, I also request
>> backports where it’s easy (== a mere 'Cherry-Pick to' button click).
>> >
>> >After that, those interested in maintaining neutron stable branches can
>> take those bugs one by one and handle them, which means: checking where it
>> really applies for backport; creating backport reviews (solving conflicts,
>> making tests pass). After it’s up for review for all branches affected and
>> applicable, the bug is removed from the list.
>> >
>> >I started on that path two weeks ago, doing initial swipe thru all
>> commits starting from stable/liberty spin off. If enough participants join
>> the process, we may think of going back into git history to backport
>> interesting fixes from stable/liberty into stable/kilo.
>> >
>> >Don’t hesitate to ask about details of the process, and happy
>> backporting,
>> >
>> >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

[openstack-dev] [Neutron] Reminder: Team meeting on Tuesday at 1400 UTC

[Armando M.]

A kind reminder for next week's meeting. Please add agenda items to the
meeting here [1].

We'll cancel the meeting of the week of the summit and the one after that.

Also, do not get caught in the switch from daylight savings when we get
back to them.

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

Re: [openstack-dev] [Neutron] Design Summit Session - Containers Orchestration platforms Integration with Neutron

[Armando M.]

Gal,

[2] is not meant to be edited by anyone just yet. This will lead to chaos
and an unproductive session. Once the link is out is obvious that anyone
can edit, but welcoming input is a recipe for disaster!

I appreciate the initiative, but please consider running thoughts by me for
advice.

Cheers,
Armando

On 18 October 2015 at 04:09, Gal Sagie  wrote:

> Hello All,
>
> In OpenStack Tokyo summit we will have a design summit session for
> containers networking
> and containers orchestration engines integration with Neutron [1].
>
> Please feel free to edit the session etherpad [2] with relevant topics, if
> you are working
> and have any gaps or needs from Neutron in that area, please share.
>
> Even if we cant resolve everything in one session, i think it would be
> great to at least understand
> the problems and document them so we can address the needs and priorities
> during the upcoming cycle.
>
> Thanks
> Gal.
>
> [1]
> http://mitakadesignsummit.sched.org/event/9be2ec1db45ea3267f811b8d35816e1c#.ViN7rLOY7CI
> [2] https://etherpad.openstack.org/p/mitaka-neutron-labs-orchestration
>
> __
> OpenStack Development Mailing 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] Design Summit Session - Containers Orchestration platforms Integration with Neutron

[Armando M.]

Perhaps adding a section for 'collecting ideas' right at the bottom of the
etherpad will help directing input.

We should strive for keeping the session focussed, sessions are only 40
mins, and realistically we'll only have 30 mins to talk about the meaty
stuff. If we want to go through bullet by bullet, we'll need an entire
summit :)

Cheers,
Armando

On 18 October 2015 at 09:14, Armando M.  wrote:

> Gal,
>
> [2] is not meant to be edited by anyone just yet. This will lead to chaos
> and an unproductive session. Once the link is out is obvious that anyone
> can edit, but welcoming input is a recipe for disaster!
>
> I appreciate the initiative, but please consider running thoughts by me
> for advice.
>
> Cheers,
> Armando
>
> On 18 October 2015 at 04:09, Gal Sagie  wrote:
>
>> Hello All,
>>
>> In OpenStack Tokyo summit we will have a design summit session for
>> containers networking
>> and containers orchestration engines integration with Neutron [1].
>>
>> Please feel free to edit the session etherpad [2] with relevant topics,
>> if you are working
>> and have any gaps or needs from Neutron in that area, please share.
>>
>> Even if we cant resolve everything in one session, i think it would be
>> great to at least understand
>> the problems and document them so we can address the needs and priorities
>> during the upcoming cycle.
>>
>> Thanks
>> Gal.
>>
>> [1]
>> http://mitakadesignsummit.sched.org/event/9be2ec1db45ea3267f811b8d35816e1c#.ViN7rLOY7CI
>> [2] https://etherpad.openstack.org/p/mitaka-neutron-labs-orchestration
>>
>> __
>> OpenStack Development Mailing 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] Mitaka Design Summit schedule for Neutron

[Armando M.]

Hi folks,

The schedule for the Neutron project is published in [1]. We are still
going through/ironing out some details, but for the most part (especially
the order of sessions) we should be all set.

See you in Tokyo!

Cheers,
Armando

[1] http://mitakadesignsummit.sched.org/overview/type/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] Stepping down from Neutron core team

[Armando M.]

On 21 May 2015 at 08:58, Salvatore Orlando  wrote:

> After putting the whole OpenStack networking contributors community
> through almost 8 cycles of pedant comments and annoying "what if"
> questions, it is probably time for me to relieve neutron contributors from
> this burden.
>
> It has been a pleasure for me serving the Neutron community (or Quantum as
> it was called at the time), and now it feel right - and probably overdue -
> to relinquish my position as a core team member in a spirit of rotation and
> alternation between contributors.
>
> Note: Before you uncork your champagne bottles, please be aware that I
> will stay in the Neutron community as a contributors and I might still end
> up reviewing patches.
>
> Thanks for being so understanding with my pedant remarks,
> Salvatore
>

+1


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

Re: [openstack-dev] [Neutron] Stepping down from Neutron core team

[Armando M.]

On 21 May 2015 at 09:58, Kyle Mestery  wrote:

> On Thu, May 21, 2015 at 9:51 AM, Doug Wiegley <
> doug...@parksidesoftware.com> wrote:
>
>>
>> On May 21, 2015, at 9:14 AM, Armando M.  wrote:
>>
>>
>>
>> On 21 May 2015 at 08:58, Salvatore Orlando  wrote:
>>
>>> After putting the whole OpenStack networking contributors community
>>> through almost 8 cycles of pedant comments and annoying "what if"
>>> questions, it is probably time for me to relieve neutron contributors from
>>> this burden.
>>>
>>> It has been a pleasure for me serving the Neutron community (or Quantum
>>> as it was called at the time), and now it feel right - and probably overdue
>>> - to relinquish my position as a core team member in a spirit of rotation
>>> and alternation between contributors.
>>>
>>> Note: Before you uncork your champagne bottles, please be aware that I
>>> will stay in the Neutron community as a contributors and I might still end
>>> up reviewing patches.
>>>
>>> Thanks for being so understanding with my pedant remarks,
>>> Salvatore
>>>
>>
>> +1
>>
>>
>> +2
>>
>>
> +2
>

+A


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

Re: [openstack-dev] Why need br-int and br-tun in openstack neutron

[Armando M.]

On 23 May 2015 at 04:43, Assaf Muller  wrote:

> There's no real reason as far as I'm aware, just an implementation
> decision.
>

This is inaccurate. There is a reason(s), and this has been asked before:

http://lists.openstack.org/pipermail/openstack/2014-March/005950.html
http://lists.openstack.org/pipermail/openstack/2014-April/006865.html

In a nutshell, the design decision that led to the existing architecture is
due to the way OVS handles packets and interact with netfilter.

The fact that we keep asking the same question clearly shows lack of
documentation, both developer and user facing.

I'll get this fixed once and for all.

Thanks,
Armando


>
>
>
> On 21 במאי 2015, at 01:48, Na Zhu  wrote:
>
> Dear,
>
>
> When OVS plugin is used with GRE option in Neutron, I see that each
> compute
> node has br-tun and br-int bridges created.
>
> I'm trying to understand why we need the additional br-tun bridge here.
> Can't we create tunneling ports in br-int bridge, and have br-int relay
> traffic between VM ports and tunneling ports directly? Why do we have to
> introduce another br-tun bridge?
>
>
> Regards,
> Juno Zhu
> Staff Software Engineer, System Networking
> China Systems and Technology Lab (CSTL), IBM Wuxi
> Email: na...@cn.ibm.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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][DB] neutron DB migration scripts

[Armando M.]

On 25 May 2015 at 08:23, Mike Bayer  wrote:

>
>
> On 5/25/15 10:24 AM, Henry Gessau wrote:
>
>> Yes, unfortunately the autogenerate currently generates commands to drop
>> all the FWaaS, LBaaS and VPNaaS tables since their models are not in the
>> neutron tree. You can and should delete all these commands that are not
>> related to your new models. We have been meaning to fix the autogeneration
>> so that it handles the *aaS tables correctly, but it is a little tricky.
>>
> I'm sure you know this already, but when you do this you should be using
> the Alembic include_object hook:
>
>
> http://alembic.readthedocs.org/en/latest/api.html?highlight=include_object#alembic.environment.EnvironmentContext.configure.params.include_object
>
> implementing this function will give you complete control over every
> object considered by autogenerate.I'm assuming the "tricky" part here
> has to do with some unpredictability on the part of the Neutron schema.  On
> the Alembic side it should be straightforward (e.g. there's no need to
> manipulate the MetaData or anything like that).
>
> Feel free to point me to a review dealing with this.
>
>
>
One thing I would like to point out is that in this cycle we'll be working
extensively in this area to make the very task you are working on easier to
deal with, and better documented. This will fall under the umbrella of the
blueprint [1].

HTH
Armando

[1] https://blueprints.launchpad.net/neutron/+spec/core-vendor-decomposition


>
>
>
> __
> OpenStack Development Mailing 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][DB] neutron DB migration scripts

[Armando M.]

On 25 May 2015 at 09:46, Mike Bayer  wrote:

>
>
> On 5/25/15 12:34 PM, Armando M. wrote:
>
>
>
>
>
> One thing I would like to point out is that in this cycle we'll be working
> extensively in this area to make the very task you are working on easier to
> deal with, and better documented. This will fall under the umbrella of the
> blueprint [1].
>
>  HTH
> Armando
>
>  [1]
> https://blueprints.launchpad.net/neutron/+spec/core-vendor-decomposition
>
>
> took a look at https://review.openstack.org/#/c/134680/17, can I have
> some clarification on what "currently alembic requires extra work to
> support multiple db migration paths onto a single database"?   Want to make
> sure you're aware that Alembic supports this fully (and my job has been to
> try to get Openstack projects to notice); see
> http://alembic.readthedocs.org/en/latest/branches.html#working-with-multiple-bases
> .
>
>

The wording might be confusing, my bad.

What I intended there was that neutron's logic to handle alembic migrations
required some work in order to simplify the support of out-of-tree DB
migrations. Past experiences, like the one that triggered this thread, have
shown that we can improve neutron's tooling (neutron-db-manage), as well as
documentation.

Cheers,
Armando


>

>
>
>>
>>
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://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] Impressions from Vancouver Neutron Design Summits

[Armando M.]

On 28 May 2015 at 03:09, Ihar Hrachyshka  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> I've heard that other projects come up with actual action lists and
> work assignments. I've heard Nova, Ironic, Oslo do it, and I witnessed
> just that in those Oslo sessions I had a chance to visit. So Neutron
> can be special in this regard and may not reflect the general
> openstack way of doing design sessions.
>
> I won't judge whether it's good or bad though. It may be the case that
> Neutron is actually different (lots of vendors and stakeholders to
> talk to and convince? a project that started as a vendor initiative
> and only now untangles itself from pure vendor matters?)
>
> Note that sessions that did not have clear vendor interest
> (give-me-a-network, nova-network migration, port health checks)
> actually got some kind of resolution and a plan (though often in oral
> form).
>
> While I agree most of decisions are not (yet?) properly documented or
> discussed with broader community, and it would be great to see those
> random etherpad notes structured in email threads. (btw on lots of
> sessions during the summit etherpad was just broken; in those cases
> it's especially important to store the oral knowledge of those who had
> a chance to attend those sessions in some written form, asap).
>
> Ihar
>

I think we all agree that dealing with OpenStack entropy can be
challenging, especially for newcomers :)

I think that Gal's suggestion is somewhat sensible, and it already happens
in one form or another (like specs/bug submissions, ML threads, and/or
IRC). Gathering and defining work items can be a shared effort that takes
place using the tools we have to collaborate. The seasoned folks can
provide guidance to less experienced folks via the typical remote
interaction.

Also bear in mind, that what is discussed at the Summit is only a fraction
of the workload proposed during the cycle.

So, what's the real value of coming up with an action list and task
assignments (quick-to-become stale) via email? Being more prescriptive
about the process would only provide marginal value IMO. Do we really need
yet another rule in place? I fear we are becoming a bureaucratic machine.

Cheers,
Armando


>
> On 05/28/2015 10:12 AM, Gal Sagie wrote:
> > Hello All,
> >
> > I wanted to very briefly share my thoughts and a suggestion
> > regarding the Neutron design summits (maybe only for the next one,
> > but still..)
> >
> > I would first like to say that i was amazed by the number of people
> > that attended the summit, it was really great to see it and it was
> > very nice meeting most of you and linking the person with the IRC
> > nick.
> >
> > Anyone that knows me, or talked with me in the past knows that i
> > wanted to get involved with Open Source for quite some time and i
> > really feel fortunate to be able to contribute and join OpenStack,
> > and hope to continue with this efforts going forward.
> >
> > I have to share that i was expecting the design summits to be
> > completely different then what went on, and although some issues
> > were interesting i feel they were not use full to go forward but
> > rather were just a stage for people to express opinions/ideas
> > without a distinct decision.
> >
> > Since i am new and never been in one of these i don’t want to judge
> > or declare if that’s good or bad :), i do think that its hard to
> > actually achieve something with so many people but i also
> > understand and appreciate the great interest of so many people with
> > Neutron.
> >
> > A small suggestion i think might improve is if the session
> > moderator will write (or any other volunteer) a follow up email
> > with Action Items that needs to be addressed and people actually
> > taking and volunteering to take some of those action items. This
> > can and should be live in the meeting where anyone requesting or
> > making a suggestion would take it on him/her self to push it
> > forward and report status. (I think every point in the agenda must
> > be converted into an action item)
> >
> > We can also do this before the actual summit on the agenda points
> > and hopefully gets a discussion going before the actual session.
> >
> > I also think we should try to re-write the agenda points into a
> > more lower level points before the summit rather then try to tackle
> > the high level stuff (for example trying to discuss the pro's and
> > con's in the mailing lists/IRC before the summit and have a more
> > concrete discussion in the session it self)
> >
> >
> > I do hope that’s the right place to express this, and again that’s
> > only my impression, i could be completely wrong here as i don’t
> > consider my self experienced enough with the Open Source way of
> > doing things. Would love to help in the future with some of the
> > points i raised here.
> >
> > Thanks Gal.
> >
> >
> >
> > __
> 
> >
> >
> OpenStack Developmen

[openstack-dev] [Neutron] Missing "allowed address pairs"?

[Armando M.]

You have better chances of getting an answer if you asked the -dev list and
add [Neutron] to the subject (done here).

That said, can you tell us a bit more about your deployment? You can also
hop on #openstack-neutron on Freenode to look for neutron developers who
can help you more interactively.

Cheers,
Armando

On 4 June 2015 at 14:03, Ken D'Ambrosio  wrote:

> Hi, all.  I've got two instances -- a Juno and an Icehouse -- both set up
> via Ubuntu/Juju.  And neither of them shows "allowed address pairs" when I
> do a "neutron ext-list" (I've tried on both the neutron-gateway and
> nova-cloud-controller).  From everything my co-worker and I have read, it
> seems like it *should* be in both of them, leading us to assume that we've
> somehow disabled that particular functionality.
>
> Any ideas on what to look at?
>
> Thanks much,
>
> -Ken
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
__
OpenStack Development Mailing 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] Service Chain project IRC meeting minutes - 06/04/2015

[Armando M.]

On 4 June 2015 at 14:17, Cathy Zhang  wrote:

>  Thanks for joining the service chaining meeting today! Sorry for the
> time confusion. We will correct the weekly meeting time to 1700UTC (10am
> pacific time) Thursday #openstack-meeting-4 on the OpenStack meeting
> page.
>
>
>

Cathy, thanks for driving this. I took the liberty to carry out one of the
actions identified in the meeting: the creation of repo to help folks
collaborate over code/documentation/testing etc [1]. As for the core team
definition, we'll start with a single member who can add new folks as more
docs/code gets poured in.

One question I had when looking at the minutes, was regarding slides [2].
Not sure if discussing deployment architectures when the API is still
baking is premature, but I wonder if you had given some thoughts into
having a pure agentless architecture even for the OVS path.

Having said that, as soon as the repo is up and running, I'd suggest to
move any relevant document (e.g. API proposal, use cases, etc) over to the
repo and reboot the review process so that everyone can be on the same page.

Cheers,
Armando

[1] https://review.openstack.org/#/c/188637/
[2]
https://docs.google.com/presentation/d/1SpVyLBCMRFBpMh7BsHmpENbSY6qh1s5NRsAS68ykd_0/edit#slide=id.p


>  Meeting Minutes:
> http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.html
>
> Meeting Minutes (text):
> http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.txt
>
> Meeting Log:
> http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.log.html
>
>
>
> The next meeting is scheduled for June 11 (same place and time).
>
>
>
> 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 Development Mailing 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] Service Chain project IRC meeting minutes - 06/04/2015

[Armando M.]

On 4 June 2015 at 19:32, Vikram Choudhary  wrote:

> Hi Cathy,
>
> Thanks for heading up this meeting. No worries about the timing, time
> zones are really difficult to handle ;)
>
> I do agree with Armando that finalization of the API is important and must
> be done at the earliest. As discussed over the last meeting I will start
> working on this and hope by the next meeting we have something in the kitty.
>

Are you going to use a polished up version of spec [1] (which needs a
rebase and a transition to the networking-sfc repo when that's ready)?

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


>
> Thanks
> Vikram
>
>
> On Fri, Jun 5, 2015 at 6:36 AM, Armando M.  wrote:
>
>>
>> On 4 June 2015 at 14:17, Cathy Zhang  wrote:
>>
>>>  Thanks for joining the service chaining meeting today! Sorry for the
>>> time confusion. We will correct the weekly meeting time to 1700UTC (10am
>>> pacific time) Thursday #openstack-meeting-4 on the OpenStack meeting
>>> page.
>>>
>>>
>>>
>>
>> Cathy, thanks for driving this. I took the liberty to carry out one of
>> the actions identified in the meeting: the creation of repo to help folks
>> collaborate over code/documentation/testing etc [1]. As for the core team
>> definition, we'll start with a single member who can add new folks as more
>> docs/code gets poured in.
>>
>> One question I had when looking at the minutes, was regarding slides [2].
>> Not sure if discussing deployment architectures when the API is still
>> baking is premature, but I wonder if you had given some thoughts into
>> having a pure agentless architecture even for the OVS path.
>>
>> Having said that, as soon as the repo is up and running, I'd suggest to
>> move any relevant document (e.g. API proposal, use cases, etc) over to the
>> repo and reboot the review process so that everyone can be on the same page.
>>
>> Cheers,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/188637/
>> [2]
>> https://docs.google.com/presentation/d/1SpVyLBCMRFBpMh7BsHmpENbSY6qh1s5NRsAS68ykd_0/edit#slide=id.p
>>
>>
>>>  Meeting Minutes:
>>> http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.html
>>>
>>> Meeting Minutes (text):
>>> http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.txt
>>>
>>> Meeting Log:
>>> http://eavesdrop.openstack.org/meetings/service_chaining/2015/service_chaining.2015-06-04-16.59.log.html
>>>
>>>
>>>
>>> The next meeting is scheduled for June 11 (same place and time).
>>>
>>>
>>>
>>> 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 Development Mailing 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] Mechanism drivers and Neutron server forking?

[Armando M.]

Interestingly, [1] was filed a few moments ago:

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

On 2 June 2015 at 22:48, Salvatore Orlando  wrote:

> I'm not sure if you can test this behaviour on your own because it
> requires the VMware plugin and the eventlet handling of backend response.
>
> But the issue was manifesting and had to be fixed with this mega-hack [1].
> The issue was not about several workers executing the same code - the
> loopingcall was always started on a single thread. The issue I witnessed
> was that the other API workers just hang.
>
> There's probably something we need to understand about how eventlet can
> work safely with a os.fork (I just think they're not really made to work
> together!).
> Regardless, I did not spent too much time on it, because I thought that
> the multiple workers code might have been rewritten anyway by the pecan
> switch activities you're doing.
>
> Salvatore
>
>
> [1] https://review.openstack.org/#/c/180145/
>
> On 3 June 2015 at 02:20, Kevin Benton  wrote:
>
>> Sorry about the long delay.
>>
>> >Even the LOG.error("KEVIN PID=%s network response: %s" % (os.getpid(),
>> r.text)) line?  Surely the server would have forked before that line was
>> executed - so what could prevent it from executing once in each forked
>> process, and hence generating multiple logs?
>>
>> Yes, just once. I wasn't able to reproduce the behavior you ran into.
>> Maybe eventlet has some protection for this? Can you provide small sample
>> code for the logging driver that does reproduce the issue?
>>
>> On Wed, May 13, 2015 at 5:19 AM, Neil Jerram 
>> wrote:
>>
>>> Hi Kevin,
>>>
>>> Thanks for your response...
>>>
>>> On 08/05/15 08:43, Kevin Benton wrote:
>>>
 I'm not sure I understand the behavior you are seeing. When your
 mechanism driver gets initialized and kicks off processing, all of that
 should be happening in the parent PID. I don't know why your child
 processes start executing code that wasn't invoked. Can you provide a
 pointer to the code or give a sample that reproduces the issue?

>>>
>>> https://github.com/Metaswitch/calico/tree/master/calico/openstack
>>>
>>> Basically, our driver's initialize method immediately kicks off a green
>>> thread to audit what is now in the Neutron DB, and to ensure that the other
>>> Calico components are consistent with that.
>>>
>>>  I modified the linuxbridge mech driver to try to reproduce it:
 http://paste.openstack.org/show/216859/

 In the output, I never received any of the init code output I added more
 than once, including the function spawned using eventlet.

>>>
>>> Interesting.  Even the LOG.error("KEVIN PID=%s network response: %s" %
>>> (os.getpid(), r.text)) line?  Surely the server would have forked before
>>> that line was executed - so what could prevent it from executing once in
>>> each forked process, and hence generating multiple logs?
>>>
>>> Thanks,
>>> Neil
>>>
>>>  The only time I ever saw anything executed by a child process was actual
 API requests (e.g. the create_port method).

>>>
>>>
>>>
>>>  On Thu, May 7, 2015 at 6:08 AM, Neil Jerram >>> > wrote:

 Is there a design for how ML2 mechanism drivers are supposed to cope
 with the Neutron server forking?

 What I'm currently seeing, with api_workers = 2, is:

 - my mechanism driver gets instantiated and initialized, and
 immediately kicks off some processing that involves communicating
 over the network

 - the Neutron server process then forks into multiple copies

 - multiple copies of my driver's network processing then continue,
 and interfere badly with each other :-)

 I think what I should do is:

 - wait until any forking has happened

 - then decide (somehow) which mechanism driver is going to kick off
 that processing, and do that.

 But how can a mechanism driver know when the Neutron server forking
 has happened?

 Thanks,
  Neil


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




 --
 Kevin Benton



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


>>>
>>> __

Re: [openstack-dev] [Neutron] Proposing Ann Kamyshnikova for the API & DB core reviewer team

[Armando M.]

+1

On 11 June 2015 at 09:27, Carl Baldwin  wrote:

> +1!
>
> On Thu, Jun 11, 2015 at 8:34 AM, Henry Gessau  wrote:
> > As one of the Lieutenants [1] for the API and DB areas under the PTL, I
> would
> > like to propose Ann Kamyshnikova as a member of the Neutron API and DB
> core
> > reviewer team.
> >
> > Ann has been a long time contributor in Neutron showing expertise
> particularly
> > in database matters. She has also worked with and contributed code to the
> > oslo.db and sqlalchemy/alembic projects. Ann was a critical contributor
> to the
> > Neutron "database healing" effort that was completed in the Juno cycle.
> >
> > Her deep knowledge of databases and backends, and her expertise with
> oslo.db,
> > sqlalchemy and alembic will be very important in this area. Ann is a
> trusted
> > member of our community and her review stats [2][3][4] place her
> comfortably
> > with other Neutron core reviewers. She consistently catches database
> issues
> > early when patches are submitted for review, and shows dedication to
> helping
> > developers understand and perfect their database-related changes.
> >
> > Existing Neutron core reviewers from the API and DB area of focus,
> please vote
> > +1/-1 for the addition of Ann to the core reviewer team. Specifically,
> I'm
> > looking for votes from Akihiro (co-Lieutenant), Mark, Maru, Armando and
> Carl.
> >
> >
> > [1]
> >
> http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#adding-or-removing-core-reviewers
> > [2]
> >
> https://review.openstack.org/#/q/reviewer:%22Ann+Kamyshnikova+%253Cakamyshnikova%2540mirantis.com%253E%22,n,z
> > [3] http://stackalytics.com/report/contribution/neutron-group/90
> > [4] http://stackalytics.com/?user_id=akamyshnikova&metric=marks
> >
> >
> >
> >
> >
> __
> > OpenStack Development Mailing 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] Proposing YAMAMOTO Takashi for the Control Plane core team

[Armando M.]

+1

On 11 June 2015 at 12:42, Carl Baldwin  wrote:

> +1
>
> On Thu, Jun 11, 2015 at 12:15 PM, Kevin Benton  wrote:
> > Hello all!
> >
> > As the Lieutenant of the built-in control plane[1], I would like YAMAMOTO
> > Takashi to be a member of the control plane core reviewer team.
> >
> > He has been extensively reviewing the entire codebase[2] and his
> feedback on
> > patches related to the reference implementation has been very useful.
> This
> > includes everything ranging from the AMPQ API to OVS flows.
> >
> > Existing cores that have spent time working on the reference
> implementation
> > (agents and AMQP code), please vote +1/-1 for his addition to the team.
> > Aaron, Gary, Assaf, Maru, Kyle, Armando, Carl and Oleg; you have all been
> > reviewing things in these areas recently so I would like to hear from you
> > specifically.
> >
> > 1.
> >
> http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy
> > 2. http://stackalytics.com/report/contribution/neutron-group/90
> >
> >
> > Cheers
> > --
> > Kevin Benton
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] Issue with pymysql

[Armando M.]

This is exactly what I did in [1].

Cheers,
Armando

[1]
https://review.openstack.org/#/q/status:open+branch:master+topic:neutron-unstable,n,z

On 12 June 2015 at 09:00, Clint Byrum  wrote:

> Excerpts from Chris Dent's message of 2015-06-12 03:47:02 -0700:
> > On Fri, 12 Jun 2015, Joe Gordon wrote:
> >
> > > Glad to see us catch these issues early.
> >
> > Yes! CI is doing exactly the job it is supposed to be doing here. It
> > is finding bugs in code. When that happens we should fix the bugs,
> > not revert. Even if it stalls other stuff.
> >
>
> I'd like to offer an alternative path. Please do remember that people
> deploy OpenStack from trunk, and we want them to do that, because if an
> organization is focused and prepared, continuous deployment will produce
> a vibrant OpenStack experience for users, and will keep those operators
> in a position to contribute.
>
> We also have hundreds of developers who need the system to work well.
> There are maybe only a handful who will work on this issue. It does not
> make any sense to me to stall hundreds of developers while a handful
> work through something that may take weeks.
>
> So, consider reverting _quickly_, landing a test that fails at least more
> reliably with the current patch, and then have that handful of users who
> are capable of fixing it work in their own branch until the problem is
> resolved to a level that it won't stand in the way of progress for CD
> operators and the development community at large.
>
> __
> OpenStack Development Mailing 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] Proposing Rossella Sblendido for the Control Plane core team

[Armando M.]

+1

On 12 June 2015 at 13:49, Edgar Magana  wrote:

>  Excellent news! +1
>
>  Cheers,
>
>  Edgar
>
>
> On Jun 12, 2015, at 12:50 PM, Kevin Benton  wrote:
>
>   Hello!
>
>  As the Lieutenant of the built-in control plane[1], I would
> like Rossella Sblendido to be a member of the control plane core reviewer
> team.
>
>  Her review stats are in line with other cores[2] and her feedback on
> patches related to the agents has been great. Additionally, she has been
> working quite a bit on the blueprint to restructure the L2 agent code so
> she is very familiar with the agent code and the APIs it leverages.
>
>  Existing cores that have spent time working on the reference
> implementation (agents and AMQP code), please vote +1/-1 for her addition
> to the team. Aaron, Gary, Assaf, Maru, Kyle, Armando, Carl and Oleg; you
> have all been reviewing things in these areas recently so I would like to
> hear from you specifically.
>
>  1.
> http://docs.openstack.org/developer/neutron/policies/core-reviewers.html#core-review-hierarchy
>  2. http://stackalytics.com/report/contribution/neutron-group/30
>
>  Cheers
> --
>  Kevin Benton
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing 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-operators] [nova] [neutron] Re: How do your end users use networking?

[Armando M.]

On 16 June 2015 at 17:31, Sam Morrison  wrote:

> We at NeCTAR are starting the transition to neutron from nova-net and
> neutron almost does what we want.
>
> We have 10 “public" networks and 10 “service" networks and depending on
> which compute node you land on you get attached to one of them.
>
> In neutron speak we have multiple shared externally routed provider
> networks. We don’t have any tenant networks or any other fancy stuff yet.
> How I’ve currently got this set up is by creating 10 networks and
> subsequent subnets eg. public-1, public-2, public-3 … and service-1,
> service-2, service-3 and so on.
>
> In nova we have made a slight change in allocate for instance [1] whereby
> the compute node has a designated hardcoded network_ids for the public and
> service network it is physically attached to.
> We have also made changes in the nova API so users can’t select a network
> and the neutron endpoint is not registered in keystone.
>
> That all works fine but ideally I want a user to be able to choose if they
> want a public and or service network. We can’t let them as we have 10
> public networks, we almost need something in neutron like a "network group”
> or something that allows a user to select “public” and it allocates them a
> port in one of the underlying public networks.
>
> I tried going down the route of having 1 public and 1 service network in
> neutron then creating 10 subnets under each. That works until you get to
> things like dhcp-agent and metadata agent although this looks like it could
> work with a few minor changes. Basically I need a dhcp-agent to be spun up
> per subnet and ensure they are spun up in the right place.
>
> I’m not sure what the correct way of doing this. What are other people
> doing in the interim until this kind of use case can be done in Neutron?
>

Would something like [1] be adequate to address your use case? If not, I'd
suggest you to file an RFE bug (more details in [2]), so that we can keep
the discussion focused on this specific case.

HTH
Armando

[1] https://blueprints.launchpad.net/neutron/+spec/rbac-networks
[2]
https://github.com/openstack/neutron/blob/master/doc/source/policies/blueprints.rst#neutron-request-for-feature-enhancements



>
> Cheers,
> Sam
>
> [1]
> https://github.com/NeCTAR-RC/nova/commit/1bc2396edc684f83ce471dd9dc9219c4635afb12
>
>
>
> > On 17 Jun 2015, at 12:20 am, Jay Pipes  wrote:
> >
> > Adding -dev because of the reference to the Neutron "Get me a network
> spec". Also adding [nova] and [neutron] subject markers.
> >
> > Comments inline, Kris.
> >
> > On 05/22/2015 09:28 PM, Kris G. Lindgren wrote:
> >> During the Openstack summit this week I got to talk to a number of other
> >> operators of large Openstack deployments about how they do networking.
> >>  I was happy, surprised even, to find that a number of us are using a
> >> similar type of networking strategy.  That we have similar challenges
> >> around networking and are solving it in our own but very similar way.
> >>  It is always nice to see that other people are doing the same things
> >> as you or see the same issues as you are and that "you are not crazy".
> >> So in that vein, I wanted to reach out to the rest of the Ops Community
> >> and ask one pretty simple question.
> >>
> >> Would it be accurate to say that most of your end users want almost
> >> nothing to do with the network?
> >
> > That was my experience at AT&T, yes. The vast majority of end users
> could not care less about networking, as long as the connectivity was
> reliable, performed well, and they could connect to the Internet (and have
> others connect from the Internet to their VMs) when needed.
> >
> >> In my experience what the majority of them (both internal and external)
> >> want is to consume from Openstack a compute resource, a property of
> >> which is it that resource has an IP address.  They, at most, care about
> >> which "network" they are on.  Where a "network" is usually an arbitrary
> >> definition around a set of real networks, that are constrained to a
> >> location, in which the company has attached some sort of policy.  For
> >> example, I want to be in the production network vs's the xyz lab
> >> network, vs's the backup network, vs's the corp network.  I would say
> >> for Godaddy, 99% of our use cases would be defined as: I want a compute
> >> resource in the production network zone, or I want a compute resource in
> >> this other network zone.  The end user only cares that the IP the vm
> >> receives works in that zone, outside of that they don't care any other
> >> property of that IP.  They do not care what subnet it is in, what vlan
> >> it is on, what switch it is attached to, what router its attached to, or
> >> how data flows in/out of that network.  It just needs to work. We have
> >> also found that by giving the users a floating ip address that can be
> >> moved between vm's (but still constrained within a "network" zone) we
> >> can solve almost all of our u

Re: [openstack-dev] [Openstack] What code structure is recommended for a Neutron plugin( L2 and L3)?

[Armando M.]

On 15 June 2015 at 19:34, Sam Su  wrote:

> Hi stackers,
>
>
>
> I am going to implement a Neutron plugin, however when I checked the
> current Neutron code(master) structure, I found there are two way to
> organize a Neutron plugin:
>
> 1.   The first one is implement all L2 and L3 functions under the
> folder ../neutron/plugins/xxx, e.g. vmware, plumgrid, and ibm…
>
> 2.   The second way is put L2 functions on the folder
> ../neutron/plugins/ml2/drivers/xxx and put L3 funtions on the folder
> ../neutron/services/l3_router/xxx, e.g. brocade, cisco.
>
>
>
> If my understanding is correct, which way is more desirable for a neutron
> plugin? If I am wrong, what is a neutron plugin code structure?
>
>
>
> Any help will be much appreciated!
>

These requests are better directed to the -dev ML. Anyway, both structures
are perfectly fine, and they both have pros and cons. Check out these
resources that might help you decide:

[1]
https://www.openstack.org/summit/openstack-summit-hong-kong-2013/session-videos/presentation/how-to-write-a-neutron-plugin-if-you-really-need-to
[2]
https://github.com/openstack/neutron/blob/master/doc/source/devref/contribute.rst

HTH
Armando


>
>
> Thanks,
>
> Sam
>
>
>
> ___
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openst...@lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>
__
OpenStack Development Mailing 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-operators] [nova] [neutron] Re: How do your end users use networking?

[Armando M.]

On 16 June 2015 at 22:36, Sam Morrison  wrote:

>
> On 17 Jun 2015, at 10:56 am, Armando M.  wrote:
>
>
>
> On 16 June 2015 at 17:31, Sam Morrison  wrote:
>
>> We at NeCTAR are starting the transition to neutron from nova-net and
>> neutron almost does what we want.
>>
>> We have 10 “public" networks and 10 “service" networks and depending on
>> which compute node you land on you get attached to one of them.
>>
>> In neutron speak we have multiple shared externally routed provider
>> networks. We don’t have any tenant networks or any other fancy stuff yet.
>> How I’ve currently got this set up is by creating 10 networks and
>> subsequent subnets eg. public-1, public-2, public-3 … and service-1,
>> service-2, service-3 and so on.
>>
>> In nova we have made a slight change in allocate for instance [1] whereby
>> the compute node has a designated hardcoded network_ids for the public and
>> service network it is physically attached to.
>> We have also made changes in the nova API so users can’t select a network
>> and the neutron endpoint is not registered in keystone.
>>
>> That all works fine but ideally I want a user to be able to choose if
>> they want a public and or service network. We can’t let them as we have 10
>> public networks, we almost need something in neutron like a "network group”
>> or something that allows a user to select “public” and it allocates them a
>> port in one of the underlying public networks.
>>
>> I tried going down the route of having 1 public and 1 service network in
>> neutron then creating 10 subnets under each. That works until you get to
>> things like dhcp-agent and metadata agent although this looks like it could
>> work with a few minor changes. Basically I need a dhcp-agent to be spun up
>> per subnet and ensure they are spun up in the right place.
>>
>> I’m not sure what the correct way of doing this. What are other people
>> doing in the interim until this kind of use case can be done in Neutron?
>>
>
> Would something like [1] be adequate to address your use case? If not, I'd
> suggest you to file an RFE bug (more details in [2]), so that we can keep
> the discussion focused on this specific case.
>
> HTH
> Armando
>
> [1] https://blueprints.launchpad.net/neutron/+spec/rbac-networks
>
>
> That’s not applicable in this case. We don’t care about what tenants are
> when in this case.
>
> [2]
> https://github.com/openstack/neutron/blob/master/doc/source/policies/blueprints.rst#neutron-request-for-feature-enhancements
>
>
> The bug Kris mentioned outlines all I want too I think.
>

I don't know what you're referring to.


>
> Sam
>
>
>
>
>
>>
>> Cheers,
>> Sam
>>
>> [1]
>> https://github.com/NeCTAR-RC/nova/commit/1bc2396edc684f83ce471dd9dc9219c4635afb12
>>
>>
>>
>> > On 17 Jun 2015, at 12:20 am, Jay Pipes  wrote:
>> >
>> > Adding -dev because of the reference to the Neutron "Get me a network
>> spec". Also adding [nova] and [neutron] subject markers.
>> >
>> > Comments inline, Kris.
>> >
>> > On 05/22/2015 09:28 PM, Kris G. Lindgren wrote:
>> >> During the Openstack summit this week I got to talk to a number of
>> other
>> >> operators of large Openstack deployments about how they do networking.
>> >>  I was happy, surprised even, to find that a number of us are using a
>> >> similar type of networking strategy.  That we have similar challenges
>> >> around networking and are solving it in our own but very similar way.
>> >>  It is always nice to see that other people are doing the same things
>> >> as you or see the same issues as you are and that "you are not crazy".
>> >> So in that vein, I wanted to reach out to the rest of the Ops Community
>> >> and ask one pretty simple question.
>> >>
>> >> Would it be accurate to say that most of your end users want almost
>> >> nothing to do with the network?
>> >
>> > That was my experience at AT&T, yes. The vast majority of end users
>> could not care less about networking, as long as the connectivity was
>> reliable, performed well, and they could connect to the Internet (and have
>> others connect from the Internet to their VMs) when needed.
>> >
>> >> In my experience what the majority of them (both internal and external)
>> >> want is to consume from Openstack a compute resource, a property of
>> >> which is it that resourc

[openstack-dev] [neutron] [networking-sfc] Project repo setup and ready to roll

[Armando M.]

Hi,

The infrastructure jobs are completed. The project repository [1] has been
provisioned, and it is ready to go. Spec [2] is being moved to the new
repo, with patch [3]. Any documentation/specification effort that pertains,
and/or is solely focused on SFC, should target the new repo from now on.

I imagine we'll talk more on next steps during the weekly call on SFC.

HTH,
Armando

[1] https://github.com/openstack/networking-sfc
[2] https://review.openstack.org/#/c/177946/
[3] https://review.openstack.org/#/c/192933/
__
OpenStack Development Mailing 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] Change in openstack/neutron-specs[master]: Neutron API for Service Chaining

[Armando M.]

On 18 June 2015 at 04:30, Jay Pipes  wrote:

> On 06/17/2015 02:24 PM, Cathy Zhang wrote:
>
>> Hi Nicolas,
>>
>> Thanks for your suggestion. Yes, we can add Application ID to the
>> parameter of the flow classifier/filter. The next updated version will
>> reflect this. Actually in its existing design, the parameter field of
>> the flow classifier can be extended in the future to include more flow
>> descriptors for more granular differentiation of flows.
>>
>> Per earlier suggestion from Isaku etc., we can also add a “context”
>> field to the service chain API. The context field will include
>> information such as “the encapsulation mechanism” used by the service
>> functions in the chain, which can be NSH, VLAN, none etc. so that the
>> Service Function Forwarder (the vSwcitch) knows whether it should act as
>> a SFC proxy or not and if acting as a Proxy, what is the chain
>> correlation mechanism between the Service Function Forwarder and the
>> Service Function.
>>
>> Any comments/questions/suggestions?
>>
>
> My only comment is the same as the one I placed on the telco-wg service
> function chaining spec [1]. That is, I don't believe this work should be
> done in the Neutron API at all.
>
> Rather, I believe these concepts belong in an entirely separate (from
> Neutron) API endpoint and project. Of course, the reference implementation
> of service function chaining would make calls out to the Neutron API for
> "plumbing" purposes -- e.g. make me a port on this L2 network, etc.
>
> I strongly believe having a separate project for service function chaining
> is the right long-term strategy for this, since the SFC concepts are not
> the same as Neutron's. SFC isn't really about networking (in terms of
> connectivity). Instead, SFC is about the *orchestration* of virtual (and
> sometimes non-virtual) resources into a hot-reconfigurable pipeline for
> directing packets across the network.
>
>
That's along the same lines of the comments I made on the same spec [1].
Having said that, in my opinion to realize Service Function Chaining use
cases more than one API (extension) is required, because more than one
component needs to be involved (from compute all the way to networking
elements). And yes, you do need an orchestrator for that and I don't
believe this orchestrator is Neutron.

The effort initiated here is an acknowledgement of this fact. The API (and
following PoC's) underpinning this effort will be solely focused on the
chaining/traffic classification/flow handling aspect of the broad SFC
universe. Once it is done, it won't be complete, in the sense that
something else needs to tell us how to create and managed the (and I quote
you) hot-reconfigurable pipeline for directing packets across the network.
After all, Neutron needs to understand how to direct packets across the
network, and we cannot do that today (at least in a flexible and API driven
manner). This is what this effort is about.

Perhaps we should make this clearer. There a WIP proposal defined in [2],
and it is still taking shape. It would be great if you could provide your
input along the way.

Do you think we're aligning in the thinking process?

Thanks,
Armando


> Thoughts?
> -jay
>
> [1] https://review.openstack.org/#/c/169201/


[2] https://review.openstack.org/#/c/192933/
__
OpenStack Development Mailing 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] Change in openstack/neutron-specs[master]: Neutron API for Service Chaining

[Armando M.]

On 18 June 2015 at 09:54, Jay Pipes  wrote:

> On 06/18/2015 12:46 PM, Armando M. wrote:
>
>> On 18 June 2015 at 04:30, Jay Pipes > <mailto:jaypi...@gmail.com>> wrote:
>>
>> On 06/17/2015 02:24 PM, Cathy Zhang wrote:
>>
>> Hi Nicolas,
>>
>> Thanks for your suggestion. Yes, we can add Application ID to the
>> parameter of the flow classifier/filter. The next updated
>> version will
>> reflect this. Actually in its existing design, the parameter
>> field of
>> the flow classifier can be extended in the future to include
>> more flow
>> descriptors for more granular differentiation of flows.
>>
>> Per earlier suggestion from Isaku etc., we can also add a
>> “context”
>> field to the service chain API. The context field will include
>> information such as “the encapsulation mechanism” used by the
>> service
>> functions in the chain, which can be NSH, VLAN, none etc. so
>> that the
>> Service Function Forwarder (the vSwcitch) knows whether it
>> should act as
>> a SFC proxy or not and if acting as a Proxy, what is the chain
>> correlation mechanism between the Service Function Forwarder and
>> the
>> Service Function.
>>
>> Any comments/questions/suggestions?
>>
>>
>> My only comment is the same as the one I placed on the telco-wg
>> service function chaining spec [1]. That is, I don't believe this
>> work should be done in the Neutron API at all.
>>
>> Rather, I believe these concepts belong in an entirely separate
>> (from Neutron) API endpoint and project. Of course, the reference
>> implementation of service function chaining would make calls out to
>> the Neutron API for "plumbing" purposes -- e.g. make me a port on
>> this L2 network, etc.
>>
>> I strongly believe having a separate project for service function
>> chaining is the right long-term strategy for this, since the SFC
>> concepts are not the same as Neutron's. SFC isn't really about
>> networking (in terms of connectivity). Instead, SFC is about the
>> *orchestration* of virtual (and sometimes non-virtual) resources
>> into a hot-reconfigurable pipeline for directing packets across the
>> network.
>>
>>
>> That's along the same lines of the comments I made on the same spec [1].
>> Having said that, in my opinion to realize Service Function Chaining use
>> cases more than one API (extension) is required, because more than one
>> component needs to be involved (from compute all the way to networking
>> elements). And yes, you do need an orchestrator for that and I don't
>> believe this orchestrator is Neutron.
>>
>> The effort initiated here is an acknowledgement of this fact. The API
>> (and following PoC's) underpinning this effort will be solely focused on
>> the chaining/traffic classification/flow handling aspect of the broad
>> SFC universe. Once it is done, it won't be complete, in the sense that
>> something else needs to tell us how to create and managed the (and I
>> quote you) hot-reconfigurable pipeline for directing packets across the
>> network. After all, Neutron needs to understand how to direct packets
>> across the network, and we cannot do that today (at least in a flexible
>> and API driven manner). This is what this effort is about.
>>
>> Perhaps we should make this clearer. There a WIP proposal defined in
>> [2], and it is still taking shape. It would be great if you could
>> provide your input along the way.
>>
>> Do you think we're aligning in the thinking process?
>>
>
> OK, cool, glad to hear this. Yes, that would work for me.
>
> And yeah, I'll review the [2] proposal.
>
>
Sweet!

Cheers,
Armando


> Best,
> -jay
>
__
OpenStack Development Mailing 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] Issue with pymysql

[Armando M.]

Hi,

A brief update on the issue that sparked this thread:

A little over a week ago, bug [1] was filed. The gist of that was that the
switch to pymysql unveiled a number of latent race conditions that made
Neutron unstable.

To try and nip these in the bud, the Neutron team filed a number of patches
[2], to create an unstable configuration that would allow them to
troubleshoot and experiment a solution, by still keeping the stability in
check (a preliminary proposal for a fix has been available in [4]).

The latest failure rate trend is shown in [3]; as you can see, we're still
gathering data, but it seems that the instability gap between the two jobs
(stable vs unstable) has widened, and should give us plenty of data points
to devise a resolution strategy.

I have documented the most recurrent traces in the bug report [1].

Will update once we managed to get the two curves to kiss each other again
and close to a more acceptable failure rate.

Cheers,
Armando

[1] https://bugs.launchpad.net/neutron/+bug/1464612
[2] https://review.openstack.org/#/q/topic:neutron-unstable,n,z
[3] http://goo.gl/YM7gUC
[4] https://review.openstack.org/#/c/191540/


On 12 June 2015 at 11:13, Boris Pavlovic  wrote:

> Sean,
>
> Thanks for quick fix/revert https://review.openstack.org/#/c/191010/
> This unblocked Rally gates...
>
> Best regards,
> Boris Pavlovic
>
> On Fri, Jun 12, 2015 at 8:56 PM, Clint Byrum  wrote:
>
>> Excerpts from Mike Bayer's message of 2015-06-12 09:42:42 -0700:
>> >
>> > On 6/12/15 11:37 AM, Mike Bayer wrote:
>> > >
>> > >
>> > > On 6/11/15 9:32 PM, Eugene Nikanorov wrote:
>> > >> Hi neutrons,
>> > >>
>> > >> I'd like to draw your attention to an issue discovered by rally gate
>> job:
>> > >>
>> http://logs.openstack.org/96/190796/4/check/gate-rally-dsvm-neutron-rally/7a18e43/logs/screen-q-svc.txt.gz?level=TRACE
>> > >>
>> > >> I don't have bandwidth to take a deep look at it, but first
>> > >> impression is that it is some issue with nested transaction support
>> > >> either on sqlalchemy or pymysql side.
>> > >> Also, besides errors with nested transactions, there are a lot of
>> > >> Lock wait timeouts.
>> > >>
>> > >> I think it makes sense to start with reverting the patch that moves
>> > >> to pymysql.
>> > > My immediate reaction is that this is perhaps a concurrency-related
>> > > issue; because PyMySQL is pure python and allows for full blown
>> > > eventlet monkeypatching, I wonder if somehow the same PyMySQL
>> > > connection is being used in multiple contexts. E.g. one greenlet
>> > > starts up a savepoint, using identifier "_3" which is based on a
>> > > counter that is local to the SQLAlchemy Connection, but then another
>> > > greenlet shares that PyMySQL connection somehow with another
>> > > SQLAlchemy Connection that uses the same identifier.
>> >
>> > reading more of the log, it seems the main issue is just that there's a
>> > deadlock on inserting into the securitygroups table.  The deadlock on
>> > insert can be because of an index being locked.
>> >
>> >
>> > I'd be curious to know how many greenlets are running concurrently here,
>> > and what the overall transaction looks like within the operation that is
>> > failing here (e.g. does each transaction insert multiple rows into
>> > securitygroups?  that would make a deadlock seem more likely).
>>
>> This begs two questions:
>>
>> 1) Are we handling deadlocks with retries? It's important that we do
>> that to be defensive.
>>
>> 2) Are we being careful to sort the table order in any multi-table
>> transactions so that we minimize the chance of deadlocks happening
>> because of any cross table deadlocks?
>>
>> __
>> OpenStack Development Mailing 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] - Proposing Miguel Angel Ajo for the Control Plane core team

[Armando M.]

O(1)

(some of computational complexities achieved after Miguel optimizations)

On 6 July 2015 at 09:24, Carl Baldwin  wrote:

> +1!
>
> On Mon, Jul 6, 2015 at 4:02 AM, Kevin Benton  wrote:
> > Hello!
> >
> > As the Lieutenant of the built-in control plane[1], I am proposing to add
> > Miguel Angel Ajo to the control plane core reviewer team.
> >
> > His review stats are inline with the other core reviewers[2], and his
> work
> > on improving the stability/performance of the agents over the last year
> has
> > been important in making the reference implementation reliable.
> >
> > Existing cores, please vote +1/-1 for his addition to the team.
> >
> > Cheers!
> >
> > 1.
> http://docs.openstack.org/developer/neutron/policies/core-reviewers.html
> > 2. http://stackalytics.com/report/contribution/neutron/30
> > http://stackalytics.com/report/contribution/neutron/60
> > http://stackalytics.com/report/contribution/neutron/90
> >
> > --
> > Kevin Benton
> >
> >
> >
> __
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing 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] [grenade] future direction on partial upgrade support

[Armando M.]

Hi,

Not sure if we reached any conclusion with this thread, and I would like to
resume it so that we don't derail the initial plan set forth by Russell and
agreed during the Liberty summit, among other things.

If I look at the thread I think this can be summarized as follow. Please
correct me if I am wrong:

   1. There is a desire for making Grenade more modular by relying on
   multi-node support. This is beneficial for all the projects that aim at
   testing partial upgrades.
   2. There are a number of steps required to achieve 1. The work required
   is not overly complicated, but it requires some discipline and good
   understanding of the overall OpenStack machine to get it to completion.
   3. Should this effort be given priority, it can impact stuff that is
   currently in flight, like the patches from Russell on Neutron partial
   upgrade, and Dan on improvements for nova-net upgrades.
   4. With minor tweaks single-node Grenade can be useful in the interim,
   while everything gets ported over a more robust multi-node Grenade job
   configuration.

Have we identified a volunteer for activity 1? For what I can tell, Joe was
kind to set the infra to start gathering data on the reliability of the
multi-node jobs, but they are clearly flaky [1], and currently broken. I
have seen nothing else. If I am mistaken, please fill me in.

Now, in terms of a resolution for this, would it be fair to say that until
we get 1) bootstrapped, Russell and Dan's efforts are a low-hanging fruit
worth taking? I would personally think so: after all patches [2,3,4] seem
trivial enough:

   - they don't add much complexity
   - they are fairly self-contained, and
   - can be easily swept away with the other grenade 'odd conditionals' in
   the context of 1.

Thoughts?

Thanks,
Armando

[1] http://goo.gl/NPkeZh
[2] https://review.openstack.org/#/q/topic:partial-neutron-upgrade,n,z
[3] https://review.openstack.org/#/q/topic:neutron-agent-control,n,z
[4] https://review.openstack.org/#/c/189478/


On 26 June 2015 at 15:54, Joe Gordon  wrote:

> No
>
> On Fri, Jun 26, 2015 at 10:15 AM, Joe Gordon 
> wrote:
>
>>
>>
>> On Wed, Jun 24, 2015 at 11:44 AM, Joe Gordon 
>> wrote:
>>
>>>
>>>
>>> On Wed, Jun 24, 2015 at 11:03 AM, Sean Dague  wrote:
>>>
 On 06/24/2015 01:41 PM, Russell Bryant wrote:
 > On 06/24/2015 01:31 PM, Joe Gordon wrote:
 >>
 >>
 >> On Tue, Jun 16, 2015 at 9:58 AM, Sean Dague >>> >> > wrote:
 >>
 >> Back when Nova first wanted to test partial upgrade, we did a
 bunch of
 >> slightly odd conditionals inside of grenade and devstack to make
 it so
 >> that if you were very careful, you could just not stop some of
 the old
 >> services on a single node, upgrade everything else, and as long
 as the
 >> old services didn't stop, they'd be running cached code in
 memory, and
 >> it would look a bit like a 2 node worker not upgraded model. It
 worked,
 >> but it was weird.
 >>
 >> There has been some interest by the Nova team to expand what's
 not being
 >> touched, as well as the Neutron team to add partial upgrade
 testing
 >> support. Both are great initiatives, but I think going about it
 the old
 >> way is going to add a lot of complexity in weird places, and not
 be as
 >> good of a test as we really want.
 >>
 >> Nodepool now supports allocating multiple nodes. We have a
 multinode job
 >> in Nova regularly testing live migration using this.
 >>
 >> If we slice this problem differently, I think we get a better
 >> architecture, a much easier way to add new configs, and a much
 more
 >> realistic end test.
 >>
 >> Conceptually, use devstack-gate multinode support to set up 2
 nodes, an
 >> all in one, and a worker. Let grenade upgrade the all in one,
 leave the
 >> worker alone.
 >>
 >> I think the only complexity here is the fact that grenade.sh
 implicitly
 >> drives stack.sh. Which means one of:
 >>
 >> 1) devstack-gate could build the worker first, then run
 grenade.sh
 >>
 >> 2) we make it so grenade.sh can execute in parts more easily, so
 it can
 >> hand something else running stack.sh for it.'
 >>
 >> 3) we make grenade understand the subnode for partial upgrade,
 so it
 >> will run the stack phase on the subnode itself (given
 credentials).
 >>
 >> This kind of approach means deciding which services you don't
 want to
 >> upgrade doesn't require devstack changes, it's just a change of
 the
 >> services on the worker.
 >>
 >> We need a volunteer for taking this on, but I think all the
 follow on
 >> partial upgrade support will be much much ea

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

[Armando M.]

On 12 February 2016 at 09:15, Matt Riedemann 
wrote:

> Forgive me for thinking out loud, but I'm trying to sort out how nova
> would use a microversion in the nova API for the get-me-a-network feature
> recently added to neutron [1] and planned to be leveraged in nova (there
> isn't a spec yet for nova, I'm trying to sort this out for a draft).
>
> Originally I was thinking that a network is required for nova boot, so
> we'd simply check for a microversion and allow not specifying a network,
> easy peasy.
>
> Turns out you can boot an instance in nova (with neutron as the network
> backend) without a network. All you get is a measly debug log message in
> the compute logs [2]. That's kind of useless though and seems silly.
>

Incidentally, I was checking this out with Horizon, and the dashboard
instance boot workflow doesn't let you proceed without specifying a network
(irrespective of the network backend). So if the user has no networks,
he/she is stuck and has to flip to the CLI. Nice, uh?


>
> I haven't tested this out yet to confirm, but I suspect that if you create
> a nova instance w/o a network, you can latter try to attach a network using
> the os-attach-interfaces API as long as you either provide a network ID
> *or* there is a public shared network or the tenant has a network at that
> point (nova looks those up if a specific network ID isn't provided).
>

Just to make sure we're on the same page: if you're referring to 'public
shared network' as the devstack's provisioned network called 'public',
that's technically not shared and it represent your floating IP pool. A
user can explicitly boot VM's on it, but that's not to be confused with a
'shared' provider network.

That said, I tried the workflow of booting a vm without networks and trying
to attach an interface without specifying anything and I got a 500 [1].
Error aside, I think it's it would be erroneous to expect the attach
command to accept no networks (and still pick one), when the boot command
doesn't.

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


> The high-level plan for get-me-a-network in nova was simply going to be if
> the user tries to boot an instance and doesn't provide a network, and there
> isn't a tenant network or public shared network

to default to, then nova would call neutron's new auto-allocated-topology
> API to get a network. This, however, is a behavior change.
>

I assume that for you 'public shared network' it's not the public network
as available in DevStack because, because I don't believe that user can
boot VM's on that network automatically.


> So I guess the question now is how do we handle that behavior change in
> the nova API?
>
> We could add an auto-create-net boolean to the boot server request which
> would only be available in a microversion, then we could check that boolean
> in the compute API when we're doing network validation.
>
> Today if you don't specify a network and don't have a network available,
> then the validation in the API is basically just quota checking that you
> can get at least one port in your tenant [3]. With a flag on a
> microversion, we could also validate some other things about auto-creating
> a network (if we know that's going to be the case once we hit the compute).
>
> Anyway, this is mostly me getting thoughts out of my head before the
> weekend so I don't forget it and am looking for other ideas here or things
> I might be missing.
>

John and I just finished talking about this a bit more and I think the the
thought process led us to this conclusion:

>From Horizon, we could provide a 'get-me-a-network' button on the Networks
wizard for the boot workflow. If the user doesn't see any Networks
available he/she can hit the button, see the network being pre-populated
and choose to proceed, instead of going back to the Network panel and do
the entire workflow.

As for Nova, we could introduce a new micro-version that changes the
behavior of nova boot without networks. In this case, if the tenant has
access to no networks, one will be created for him/her and the VM will boot
off of it.

On the other end, if the user does want a VM without nics, he/she should be
explicit about this and specify 'no-nic' boolean, e.g.

  nova boot  --flavor  --image 
--no-nics

John and I think this would be preferable because the output of the command
becomes more predictable: the user doesn't end up having VM's connected to
NICs accidentally if some net-create sneaks underneath.

Anyhow, food for thought.

Thanks for starting this thread.

Cheers,
Armando


> [1] https://blueprints.launchpad.net/neutron/+spec/get-me-a-network
> [2]
> https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L594-L595
> [3]
> https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L1107
>
> --
>
> Thanks,
>
> Matt Riedemann
>
>
> _

Re: [openstack-dev] [nova][neutron] How would nova microversion get-me-a-network in the API?

[Armando M.]

On 12 February 2016 at 11:08, Matt Riedemann 
wrote:

>
>
> On 2/12/2016 12:44 PM, Armando M. wrote:
>
>>
>>
>> On 12 February 2016 at 09:15, Matt Riedemann > <mailto:mrie...@linux.vnet.ibm.com>> wrote:
>>
>> Forgive me for thinking out loud, but I'm trying to sort out how
>> nova would use a microversion in the nova API for the
>> get-me-a-network feature recently added to neutron [1] and planned
>> to be leveraged in nova (there isn't a spec yet for nova, I'm trying
>> to sort this out for a draft).
>>
>> Originally I was thinking that a network is required for nova boot,
>> so we'd simply check for a microversion and allow not specifying a
>> network, easy peasy.
>>
>> Turns out you can boot an instance in nova (with neutron as the
>> network backend) without a network. All you get is a measly debug
>> log message in the compute logs [2]. That's kind of useless though
>> and seems silly.
>>
>>
>> Incidentally, I was checking this out with Horizon, and the dashboard
>> instance boot workflow doesn't let you proceed without specifying a
>> network (irrespective of the network backend). So if the user has no
>> networks, he/she is stuck and has to flip to the CLI. Nice,
>> uh?
>>
>>
>> I haven't tested this out yet to confirm, but I suspect that if you
>> create a nova instance w/o a network, you can latter try to attach a
>> network using the os-attach-interfaces API as long as you either
>> provide a network ID *or* there is a public shared network or the
>> tenant has a network at that point (nova looks those up if a
>> specific network ID isn't provided).
>>
>>
>> Just to make sure we're on the same page: if you're referring to 'public
>> shared network' as the devstack's provisioned network called 'public',
>> that's technically not shared and it represent your floating IP pool. A
>> user can explicitly boot VM's on it, but that's not to be confused with
>> a 'shared' provider network.
>>
>
> I was referring to this code:
>
>
> https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L217-L223
>
>
Ok I am with you: the public in the comment is somewhat misleading because
there's nothing 'public' about a shared network and as a matter of fact
RBAC [1] allows for networks to be shared only to a subset of tenants.

[1]
https://specs.openstack.org/openstack/neutron-specs/specs/liberty/rbac-networks.html


>
>> That said, I tried the workflow of booting a vm without networks and
>> trying to attach an interface without specifying anything and I got a
>> 500 [1]. Error aside, I think it's it would be erroneous to expect the
>> attach command to accept no networks (and still pick one), when the boot
>> command doesn't.
>>
>> [1] http://paste.openstack.org/show/486856/
>>
>
> Cool, yeah, I was totally expecting an IndexError because of the code here:
>
>
> https://github.com/openstack/nova/blob/30ba0c5eb19a9c9628957ac8e617ae78c0c1fa84/nova/network/neutronv2/api.py#L610
>
>
>
>>
>> The high-level plan for get-me-a-network in nova was simply going to
>> be if the user tries to boot an instance and doesn't provide a
>> network, and there isn't a tenant network or public shared network
>>
>> to default to, then nova would call neutron's new
>> auto-allocated-topology API to get a network. This, however, is a
>> behavior change.
>>
>>
>> I assume that for you 'public shared network' it's not the public
>> network as available in DevStack because, because I don't believe that
>> user can boot VM's on that network automatically.
>>
>>
>> So I guess the question now is how do we handle that behavior change
>> in the nova API?
>>
>> We could add an auto-create-net boolean to the boot server request
>> which would only be available in a microversion, then we could check
>> that boolean in the compute API when we're doing network validation.
>>
>> Today if you don't specify a network and don't have a network
>> available, then the validation in the API is basically just quota
>> checking that you can get at least one port in your tenant [3]. With
>> a flag on a microversion, we could also validate some other things
>> about auto-creating

[openstack-dev] [Neutron] Check queue broken on master

[Armando M.]

Hi folks,

It looks like something slipped in and how we got persistent failures on
functional/fullstack jobs [1]. Has anyone triaged? I couldn't find anything
in [2].

The effect for this: we can't merge anything until this gets resolved. Some
might argue this is not necessarily a bad thing...

Cheers,
Armando

[1]
http://docs.openstack.org/developer/neutron/dashboards/check.dashboard.html
[2]
https://bugs.launchpad.net/neutron/+bugs?field.tag=gate-failure&orderby=-datecreated&start=0
__
OpenStack Development Mailing 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] Check queue broken on master

[Armando M.]

On 17 February 2016 at 11:12, Armando M.  wrote:

> Hi folks,
>
> It looks like something slipped in and how we got persistent failures on
> functional/fullstack jobs [1]. Has anyone triaged? I couldn't find anything
> in [2].
>

Looks like [1] fixed it. Thanks Assaf.

Be safe outta there. It's a scary world.


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


> The effect for this: we can't merge anything until this gets resolved.
> Some might argue this is not necessarily a bad thing...
>
> Cheers,
> Armando
>
> [1]
> http://docs.openstack.org/developer/neutron/dashboards/check.dashboard.html
> [2]
> https://bugs.launchpad.net/neutron/+bugs?field.tag=gate-failure&orderby=-datecreated&start=0
>
__
OpenStack Development Mailing 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] Check queue broken on master

[Armando M.]

On 17 February 2016 at 11:22, Assaf Muller  wrote:

> On Wed, Feb 17, 2016 at 2:16 PM, Armando M.  wrote:
> >
> >
> > On 17 February 2016 at 11:12, Armando M.  wrote:
> >>
> >> Hi folks,
> >>
> >> It looks like something slipped in and how we got persistent failures on
> >> functional/fullstack jobs [1]. Has anyone triaged? I couldn't find
> anything
> >> in [2].
> >
> >
> > Looks like [1] fixed it. Thanks Assaf.
>
> You mean thanks Jakub!
>

Indeed, sorry I am clearly still sleeping this morning.


>
> >
> > Be safe outta there. It's a scary world.
> >
> >
> > [1] https://bugs.launchpad.net/neutron/+bug/1546506
> >
> >>
> >> The effect for this: we can't merge anything until this gets resolved.
> >> Some might argue this is not necessarily a bad thing...
> >>
> >> Cheers,
> >> Armando
> >>
> >> [1]
> >>
> http://docs.openstack.org/developer/neutron/dashboards/check.dashboard.html
> >> [2]
> >>
> https://bugs.launchpad.net/neutron/+bugs?field.tag=gate-failure&orderby=-datecreated&start=0
> >
> >
> >
> >
> __
> > OpenStack Development Mailing 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