Re: [openstack-dev] [neutron] Please opt-in for neutron-lib patches

[Boden Russell]

On 10/3/18 10:16 AM, Eric Fried wrote:
> We would like networking-powervm to be included, and have proposed [5],
> but are wondering why we weren't picked up in [6]. Your email [1] says
>
> "If your project isn't in [3][4],
> but you think it should be; it maybe missing a recent neutron-lib
> version in your requirements.txt."
>
> What's "recent"? I see the latest (per the requirements project) is
> 1.19.0 and we have 1.18.0. Should we bump?
I must've accidentally missed powervm; thanks for following up.
The fact that you're not using neutron-lib 1.19.0 has nothing to do with it;
this was a user error.

It's probably a good idea to move up to 1.19.0 once neutron does [1].
Typically I will propose the bump for all such projects, but I was waiting
for the list of opt-in consumers before doing so.

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


__
OpenStack Development Mailing List (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] Please opt-in for neutron-lib patches

[Boden Russell]

Just a friendly reminder that networking projects now need to opt-in for
neutron-lib consumption patches [1].

Starting next week (September 8) I'd like to start basing consumption
patches on those projects that have opted-in. If there are exceptions
please let me know so we can track them accordingly.

Thanks

[1]
http://lists.openstack.org/pipermail/openstack-dev/2018-September/135063.html

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

[openstack-dev] [neutron] Opting-in to receive neutron-lib consumption patches

[Boden Russell]

Please read on if your project uses neutron-lib.


During the PTG [1] we decided that projects wanting to receive
neutron-lib consumption patches [2] (for free) need to explicitly opt-in
by adding the string "neutron-lib-current" to a comment in their
requirements.txt.

Based on the list of identified current networking projects [3], I've
submitted an opt-in patch for each [4]. If your project isn't in [3][4],
but you think it should be; it maybe missing a recent neutron-lib
version in your requirements.txt.

By landing the opt-in patch for your project's repo [4], you are
effectively agreeing to:
- Stay current with neutron, TC and infra initiatives thereby allowing
consumption patches to work with the latest and greatest.
- Help review and land consumption patches when they come into your
review queue. As we've discussed before there's about a 2 week window to
land such patches [5].

For project's that don't opt-in, you can continue to consume older
versions of neutron-lib from PyPI manually updating your project to
consume as you go.

Thanks

[1] https://etherpad.openstack.org/p/neutron-stein-ptg
[2]
https://docs.openstack.org/neutron-lib/latest/contributor/contributing.html#phase-4-consume
[3] https://etherpad.openstack.org/p/neutron-sibling-setup
[4]
https://review.openstack.org/#/q/topic:neutron-lib-current-optin+(status:open+OR+status:merged)
[5] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131841.html

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

[openstack-dev] [neutron] Bug deputy report week of Sept 17

[Boden Russell]

Below is a summary of last weeks bug activity.
I've tried to organize the summary to highlight those bugs that still
need attention.
Thanks


Needs additional technical triage:
- [dvr][ha][dataplane down] router_gateway port binding host goes wrong
after the 'master' host down/up
https://bugs.launchpad.net/neutron/+bug/1793529
- q-dhcp crashes with guru meditation on ironic's grenade
https://bugs.launchpad.net/neutron/+bug/1792925
- [RFE] Enable other projects to extend l2pop fdb information
https://bugs.launchpad.net/neutron/+bug/1793653

Under discussion:
- Egress UDP traffic is dropped
https://bugs.launchpad.net/neutron/+bug/1793244
- ha_vrrp_health_check_interval causes constantly VRRP transitions
https://bugs.launchpad.net/neutron/+bug/1793102
- subnet pool can not delete prefixes
https://bugs.launchpad.net/neutron/+bug/1792901
- external_gateway_info enable_snat attribute should be owner-modifiable
https://bugs.launchpad.net/neutron/+bug/1793207

Triaged, but no assignee:
- DB deadlock when delete subnet
https://bugs.launchpad.net/neutron/+bug/1793516
- public-subnet not explained
https://bugs.launchpad.net/neutron/+bug/1793103
- adding 0.0.0.0/0 address pair to a port bypasses all other vm security
groups https://bugs.launchpad.net/neutron/+bug/1793029
- The user can delete a security group which is used as remote-group-id
https://bugs.launchpad.net/neutron/+bug/1792890

In progress:
- [dvr_no_external][ha][dataplane down]centralized floating IP nat rules
not install in every HA node https://bugs.launchpad.net/neutron/+bug/1793527
- Subnet update with the subnet's current segment_id fail with:
NoUpdateSubnetWhenMultipleSegmentsOnNetwork
https://bugs.launchpad.net/neutron/+bug/1793391
- Changing of_interface between native and ovs-ofctl causes packet drops
https://bugs.launchpad.net/neutron/+bug/1793354
- Router: add port doesn't take IP from allocation pool
https://bugs.launchpad.net/neutron/+bug/1793094

__
OpenStack Development Mailing 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] tox-siblings alternative for local testing

[Boden Russell]

On 8/30/18 5:49 AM, Michel Peterson wrote:
> 
> There are pre releases available in PyPI [1]. You can use those from
> your requirements like we did in n-odl [2].
> 
> That might be an acceptable solution.
> 
> [1] https://pypi.org/project/neutron/#history
> [2] https://review.openstack.org/#/c/584791/
> 

IIUC, I don't think consuming pre-releases is really a solution; it's a
work-around for this particular case.

Any solution should be pulling the appropriate dependencies from source;
mimicking what tox-siblings does. This ensures the local testing is done
on the latest source regardless of what's on PYPI (a point-in-time
snapshot of the code).

I believe the same applies to [2] in your email; things aren't going to
work as expected locally until you account for pulling from source.

We can discuss this more at the PTG, but moving forward I think any
projects wanting to get the neutron-lib consumption patches (for free)
will need to make sure they have tox/zuul setup properly for both local
and gate testing.

__
OpenStack Development Mailing 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] tox-siblings alternative for local testing

[Boden Russell]

On 8/29/18 12:06 AM, Takashi Yamamoto wrote:
> is there any preferred solution for this?
> i guess the simplest solution is to make an intermediate release of neutron
> and publish it on pypi.  i wonder if it's acceptable or not.

What we've been doing to date is adding tox target(s) to the respective
repo for local testing. These local targets install the dependencies
from source where necessary (in place tox siblings). For more details
see the "How to setup dependencies for local tox targets" of [1]. This
is also a topic I wanted to bring up at the neutron PTG [2].

There maybe other solutions, but I'm unaware of them.


[1] https://etherpad.openstack.org/p/neutron-sibling-setup
[2] https://etherpad.openstack.org/p/neutron-stein-ptg

__
OpenStack Development Mailing 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] Old patches cleaning

[Boden Russell]

On 8/22/18 2:10 AM, Slawomir Kaplonski wrote:> I will run it only for
projects like:
> * neutron-lib
> 
> If You have any concerns about running this script, please raise Your hand 
> now :)

Thanks for this.
Personally I don't see a need to cleanup old reviews for neutron-lib;
it's a pretty small list and a few oldies are still being discussed in
some form or another. But if you think there's a need, that's fine as well.

Neutron is a whole different story.

__
OpenStack Development Mailing 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] Please use neutron-lib 1.18.0 for Rocky

[Boden Russell]

On 7/23/18 9:46 PM, Sangho Shin wrote:
> It applies also to the networking- projects. Right?

Yes. It should apply to any project that's using/depending-on
neutron/master today.

Note that I "think" the neutron-lib version required by neutron will
trump the project's required version anyway, but it would be ideal if
all such projects required the same/proper version.

__
OpenStack Development Mailing List (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] Please use neutron-lib 1.18.0 for Rocky

[Boden Russell]

If you're a networking project that uses neutron/neutron-lib, please
read on.

We recently created the stable/rocky branch for neutron-lib based on
neutron-lib 1.18.0 and neutron is now using 1.18.0 as well [1]. If
you're a networking project that depends on (uses) neutron/master then
it's probably best your project is also using 1.18.0.

Action items if you project uses neutron/master for Rocky:
- If your project is covered in the existing patches to use neutron-lib
1.18.0 [2], please help verify/review.
- If your project is not covered in [2], please update your requirements
to use neutron-lib 1.18.0 in prep for Rocky.

If you run into any issues with neutron-lib 1.18.0 please report them
immediately and/or find me on #openstack-neutron

Thanks

[1] https://review.openstack.org/#/c/583671/
[2] https://review.openstack.org/#/q/topic:rocky-neutronlib

__
OpenStack Development Mailing 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 review

[Boden Russell]

On 7/12/18 4:10 AM, Takashi Yamamoto wrote:
> On Thu, Jul 12, 2018 at 6:13 PM, Tony Breeds  wrote:
>>
>> No we need more contributors to stable and extended maintenance periods.
>> This is not a new problem, and one we're trying to correct.
> 
> actually it is a new problem. at least worse than before.
> 

I'm no expert, but wanted to add my $0.02 as a developer who's invested
substantial time in trying to keep a different networking project up to
date with all the underpinning changes; some of which are noted in your
midonet stable/queens patch.

IMHO it's not realistic to think an OpenStack project (master or stable)
can go without routine maintenance for extended period of time in this
day and age; there are just too many dynamic underpinnings. A case in
point are the changes required for the Zuul v3 workstream that don't
appear to be fully propagated into a number of networking projects yet
[1], midonet included.

With that in mind I'm not sure we can just point at the neutron stable
team; there are community wide initiatives that ultimate drive
underpinning changes across many projects. I've found that you either
have to invest the time to "keep up", or "die". For reference I've been
spending nearly 4 person weeks per release just on such "maintenance"
items. It certainly takes time away from functionality that can be
delivered per release, but it seems it's just part of the work necessary
to keep your project "current".

If are wanting to reduce the amount work for projects to "stay current"
then IMO it's certainly a bigger issue than neutron.


[1] http://lists.openstack.org/pipermail/openstack-dev/2018-June/131801.html

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

[openstack-dev] [neutron] Finalizing neutron-lib release for Rocky

[Boden Russell]

Howdy,
We need to have a final release of neutron-lib for Rocky by July 19th,
so we should probably propose a neutron-lib 1.18.0 release early next week.

To help focus our review efforts between now and then I'd like to ask
folks to tag any neutron-lib patches they deem necessary for Rocky with
the string "rocky-candidate" (just add a comment with "rocky-candidate"
to the patch). This will allow us to use a query [1] to focus our
efforts in this regard.

Please keep in mind that API reference patches don't fall into this
category as they are not based on pypi releases (IIUC).

If you have any questions please feel free to reach out on the
#openstack-neutron channel.


Cheers

[1]
https://review.openstack.org/#/q/project:openstack/neutron-lib+comment:rocky-candidate

__
OpenStack Development Mailing List (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] Networking projects not setup properly for Zuul v3 and local testing

[Boden Russell]

It appears a number of networking related projects aren't setup properly
for Zuul v3 gate jobs, as well as for local testing when it comes to
pulling in dependencies from source.

Since this may not be a common concept, ask yourself: "should my
project's master branch source be running with and tested against
neutron's (or other projects) master branch source"? If the answer is
yes, this may impact you.

I started a brain-dump on etherpad [1] for this topic and best I can
tell a number of networking projects are impacted.

I would like to please ask networking related projects that are "staying
current" to have a look.

Thanks!

[1] https://etherpad.openstack.org/p/neutron-sibling-setup


__
OpenStack Development Mailing 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] [tricircle] Zuul v3 integration status

[Boden Russell]

Thanks for that.

I'm a bit concerned about how to proceed with dependencies in the
meantime, it's not realistic to hold all such patches until S.

Perhaps we can continue this discussion in [1]?

[1] https://bugs.launchpad.net/tricircle/+bug/1776922



On 6/19/18 7:38 PM, linghucongsong wrote:
> we will plan this as a bp, but maybe can not finished it
>
> in the R release, we promise must be finish it in the next openstack
> version.
>


__
OpenStack Development Mailing List (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] [tricircle] Zuul v3 integration status

[Boden Russell]

Is there anyone who can speak to the status of tricircle's adoption of
Zuul v3?

As per [1] it doesn't seem like the project is setup properly for Zuul
v3. Thus, it's difficult/impossible to land patches like [2] that
require neutron/master + a depends on patch.

Assuming tricircle is still being maintained, IMO we need to find a way
to get it up to speed with zuul v3; otherwise some of our neutron
efforts will be held up, or tricircle will fall behind with respect to
neutron-lib adoption.

Thanks


[1] https://bugs.launchpad.net/tricircle/+bug/1776922
[2] https://review.openstack.org/#/c/565879/

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

[openstack-dev] [neutron] neutron-lib 1.15.0 syntax error in LOG.debug

[Boden Russell]

The 1.15.0 release of neutron-lib contains a syntax error in a LOG debug
call that was fixed with [1].

We are working to release the fix with 1.16.0 [2].

If you are running into this error [3], it maybe necessary to exclude
neutron-lib 1.15.0 and pickup 1.16.0 once we get it released.

Feel free to reach out on #openstack-neutron if you have questions.

Thanks


[1] https://review.openstack.org/#/c/574068/
[2] https://review.openstack.org/#/c/573826/
[3]
http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22from%20file%20runtime.py%2C%20line%2062%5C%22

__
OpenStack Development Mailing List (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] Bug deputy report May 28 - June 3

[Boden Russell]

Last week we had a total of 14 bugs come in [1]; 2 of which are RFEs.
Only 1 defect is high priority [2] and is already in progress.

There are still a few bugs under discussion/investigation:

- 1774257 "neutron-openvswitch-agent RuntimeError: Switch connection
timeout" could use some input from folks skilled with OVS and affects
multiple people.
- 1773551 "Error loading interface driver
'neutron.agent.linux.interface.BridgeInterfaceDriver'" is still waiting
for input from the submitter.
- 1773282 "errors occured when create vpnservice with flavor_id:Flavors
plugin not Found" still under investigation and could use an eye from
the VPNaaS team.



[1] https://bugs.launchpad.net/neutron/+bugs?orderby=-datecreated=0
[2] https://bugs.launchpad.net/neutron/+bug/1774006


__
OpenStack Development Mailing List (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] [tc][stackalytics][neutron] neutron-lib not showing as TC-approved project on stackalytics

[Boden Russell]

Back in 2016 we tagged neutron-lib as a "tc-approved-release" and as a
result neutron-lib commits/reviews showed up on stackalytics under
TC-approved Project Types.

However as of recent that's seemed to have changed and neutron-lib
commits/reviews are no longer showing up [1] even though it appears to
still be tagged [2] IIUC.

Is neutron-lib not showing up as a TC-approved project in
stackalytics intentional? If so can some please refer me as to why. If
not how do we get stackalytics to pick it up again?

Thanks


[1]
http://stackalytics.com/?release=rocky_type=tc:approved-release=commits
[2]
https://github.com/openstack/governance/blob/master/reference/projects.yaml#L2065

__
OpenStack Development Mailing 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] [requirements][horizon][neutron] plugins depending on services

[Boden Russell]

On 4/25/18 10:13 PM, Shu M. wrote:
> Hi folks,
> 
>> unwinding things
>> 
>>
>> There are a few different options, but it's important to keep in mind
>> that we ultimately want all of the following:
>>
>> * The code works
>> * Tests can run properly in CI
>> * "Depends-On" works in CI so that you can test changes cross-repo
>> * Tests can run properly locally for developers
>> * Deployment requirements are accurately communicated to deployers
> 
> One more thing:
> * Test environments between CI and local should be as same as possible.
> 
> To run tests in CI and local successfully, I have tried to add new
> testenv for local into tox.ini
> (https://review.openstack.org/#/c/564099/4/tox.ini
> ) as alternative
> solution last night, this would be same as adding new requirements.txt
> for local check. This seems to run fine, but this might make difference
> in environments between CI and local. So I can not conclude this is the
> best way for now.

I'd like to echo this point from a neutron plugin (project) perspective.

While we can move all our inter-project dependencies to requirements now
[1], this does not address how we can run tox targets or devstack
locally with master branches (to test changes locally before submitting
to gate).

To mitigate running tox locally we've introduced new targets that
manually install the inter-project dependencies [2] in editable mode.
While this works, IMHO it's not optimal and furthermore requires
"special" steps if you want to add some changes to those editable
projects and run with them.

And we've done something similar for devstack [3].

Finally, we also have some periodic jobs used to pre-validate our shared
neutron-lib project using master branches as defined by the
periodic-jobs-with-neutron-lib-master template. Certainly we want to
keep these working.


Frankly it's been a bit of a cat-and-mouse game to keep up with the
infra/zuul changes in the past 2 releases so it's possible what we've
done could be improved upon. If that's the case please do let me know so
we can works towards and optimized approach.

Thanks


[1] https://review.openstack.org/#/c/554292/
[2] https://review.openstack.org/#/c/555005/5/tox.ini
[3] https://review.openstack.org/#/c/555005/5/devstack/lib/nsx_common

__
OpenStack Development Mailing 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] [horizon][neutron] tools/tox_install changes - breakage with constraints

[Boden Russell]

On 3/14/18 6:59 PM, Tony Breeds wrote:
> On Thu, Mar 15, 2018 at 07:16:11AM +0900, Akihiro Motoki wrote:
>> (1) it makes difficult to run tests in local environment
>> We have only released version of neutron/horizon on PyPI. It means
>> PyPI version (i.e. queens) is installed when we run tox in our local
>> development. Most neutron stadium projects and horizon plugins depends
>> on the latest master. Test run in local environment will be broken. We
>> need to install the latest neutron/horizon manually. This confuses
>> most developers. We need to ensure that tox can run successfully in a
>> same manner in our CI and local environments.
> 
> This is an issue I agree and one we need to think about but it will be
> somewhat mitigated for local development by pbr siblings[1]
> 
> In the short term, developers can do something like:
> 
> for env in pep8,py35,py27 ; do
>tox -e $env --notest
>.tox/$env/bin/pip install -e /path/to/{horizon,neutron}
>tox -e $env
> done
> 
> Which is far from ideal but gives as a little breathing room to decide
> if we need to revert and try again in a while or persist with the plan
> as it stands.
> 
> pbr siblings wont fix all the issues we have and still makes consumption of
> neutron and horizon (and plugins / stadium projects) difficult outside
> of test.

Unless I'm missing something, devstack is also impacted in these
scenarios and doesn't account for installing master branches of select
dependencies. As a result we are seeing failures in our external CI jobs
(that use devstack) due to invalid package versions.

Is the proper way to address this to specify the _REPO and _BRANCH in
our project's devstack lib sciprt(s) as needed so that devstack will
grab master for them?

Thanks

__
OpenStack Development Mailing 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] [requirements][neutron] Depending on pypi versions

[Boden Russell]

> On 3/19/18 7:15 AM, Andreas Jaeger wrote:
> 
> pip install -U breaks it, please double check that this does the right
> thing:
> 
> https://review.openstack.org/554222

I'm not yet convinced the pip -U is the only factor here.
When I run with 554222 in my local env I still get a back-leveled
neutron, but maybe I'm doing something wrong.

I'm testing with: https://review.openstack.org/#/c/554245/

__
OpenStack Development Mailing List (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][networking-vsphere] neutron-lib patches for review

[Boden Russell]

Could I please ask the folks from networking-vsphere to keep an eye on
their review queue for incoming neutron-lib related patches?

Today we have at least 3 in the networking-vsphere queue that haven't
gotten a core review for over a month.

In order to keep the neutron-lib effort moving and stable, it's
important for networking projects using stable branches to assist with
these reviews. In general the code changes are minimal so I hoping this
isn't asking for a lot of time.

Thanks much

__
OpenStack Development Mailing List (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] Proper usage of neutron extensions/modules

[Boden Russell]

If your networking project is using neutron/neutron-lib, please read on.

SUMMARY:
If you're using neutron or neutron-lib code (for example extensions),
please ensure you import/use the respective attributes of those modules
rather than duplicate such values (str constants and such).


DETAILS:
To fully consume neutron-lib changes; the respective code that was
rehomed into lib is removed from neutron once all consumers using stable
branches are updated to use lib (instead of neutron). In order to find
such consumers we generally search [1] for who imports the respective
modules of interest. This allows us to update the consumers and ensure
they don't break once we remove the code from neutron.

The implication is that if consumers are using (depending on) the
neutron code, but never import it, they are missed in this process and
can end up with breakage when we remove the code from neutron.

A recent example of such includes [2] mentioned on [3].
An example of what's being asked for can be found in [4].


ACTION:
If neutron consumers could please inspect their code to ensure they are
declaring their intent to use neutron with 'imports' and also use
neutron module attributes were applicable, we can minimize the number of
breakages that occur in this process.


Feel free to reach out to me (boden) on openstack-neutron with any
questions/comments.

Thank you!


[1] http://codesearch.openstack.org/
[2] https://review.openstack.org/#/c/544179/
[3]
http://lists.openstack.org/pipermail/openstack-dev/2018-February/127385.html
[4] https://bugs.launchpad.net/kuryr-libnetwork/+bug/1749594


__
OpenStack Development Mailing List (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] reusable code moving to neutron-lib

[Boden Russell]

Just a quick update on the neutron-lib workstream.

Although there hasn't been many "neutron-lib impact" emails lately, the
effort is still active. The reason for decreased email volume is that
rather than just updating stadium consumers during consumption [1], all
(stadium/non-stadium) consumers who use neutron/neutron-lib stable
branches are updated (for ~free).

To summarize what this means:
- If your project uses neutron/neutron-lib stable branches, you should
see consumption patches as we consume [1] in neutron. Just help the
review along please.
- If your project "pins" older versions of neutron/neutron-lib, your
project will need to address the consumption as you move the "pin" up.
- To stay up to date on the latest neutron-lib consumption patches,
please consider attending the weekly neutron meeting and/or checking the
open patches tagged with NeutronLibImpact [2].

Finally; a heads up that the neutron.plugins.ml2.driver_api module is in
lib and will be removed in neutron as part of consumption [3]. For those
using stable branches, a consumption patch should already be queued up
in your gate [4].

Thanks

[1]
https://docs.openstack.org/neutron-lib/latest/contributor/contributing.html#phase-4-consume
[2]
https://wiki.openstack.org/wiki/Network/Meetings#Neutron-lib.2C_planned_refactoring_and_other_impacts
[3] https://review.openstack.org/#/c/488173/
[4] https://review.openstack.org/#/q/topic:use-lib-ml2-driverapi

__
OpenStack Development Mailing 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] [infra][all][stable] Zuul v3 changes and stable branches

[Boden Russell]

On 10/27/17 6:35 PM, James E. Blair wrote:
> 
> We're rolling out a new version of Zuul that corrects the issues, and
> the migration doc has been updated.  The main things to know are:
> 
> * If your project has stable branches, we recommend backporting the Zuul
>   config along with all the playbooks and roles that are in your repo to
>   the stable branches.

Does this apply to projects that don't have an in-repo config in master
and only use shared artifacts?

For example, our project's (master) pipeline is in project-config's
projects.yaml and only uses shared templates/jobs/playbooks. Is the
expectation that we copy this pipeline to an in-repo zuul.yaml for each
stable branch as well as the "shared" playbooks?

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

Re: [openstack-dev] [all][infra] Zuul v3 rollout, the sequel

[Boden Russell]

On 10/10/17 3:40 AM, Andreas Jaeger wrote:
> The common jobs have been fixed whenever bugs got reported. So, if you
> have current failures, tell us. 

How can projects validate zuul v3 jobs in our current state to prepare
for the transition?
Some projects don't even have a verified zuul v3 patch [1] and thus
really have no way to test and work through v3 issues (IIUC).

Is there a way we can leave v3 non-gating and let projects request
moving to gating v3 jobs on a per-project basis (e.g. project X is ready
for v3, make v3 gating for X now)? This would allow them the time they
need to transition with minimal impact to their pipeline.


[1]
https://review.openstack.org/#/q/project:openstack/vmware-nsx+label:Verified%252Czuul

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

Re: [openstack-dev] [all] Zuul Error for commits

[Boden Russell]

On 10/5/17 5:43 AM, Goutham Pratapa wrote:
> failed with the error *TIMED_OUT in 2h 32m 23s *which resulted in -1 how
> can I retrigger it is
>

[1] Based on [1] I though Zuul v3 jobs were non-voting at this point in time and
so a v3 job failure wouldn't -1V stalling a patch.

However, I'm also noticing that v3 jobs are failing patches in neutron-lib
([2] for ex).

What am I missing here??

[1] http://lists.openstack.org/pipermail/openstack-dev/2017-October/123052.html
[2] https://review.openstack.org/#/c/502698/

__
OpenStack Development Mailing List (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] [python-openstackclient][python-openstacksdk][neutron] Bridging neutronclient gaps

[Boden Russell]

While I realize my timing may be a little bad here with all the other
things we have going on, I wanted to follow up on our plans for the SDK
and OSC as time is already flying by for Queens.

As we discussed before [1], there are some gaps in the OSC/SDK model
that keep us from getting parity with the neutronclient, and thus
dropping support for it in neutron. While I'm happy to help bridge these
gaps, it's unclear what the plans are for OSC/SDK (see replies to [1]).

Who are the right folks for me to work with on this topic?

Thanks

[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/120613.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] [all] Important information for people with in-repo Zuul v3 config

[Boden Russell]

On 10/3/17 1:37 PM, Monty Taylor wrote:
> The partial rollback of Zuulv3 is in place now. Zuulv2 is acting as your
> gate keeper once again. 

Since the rollback, one of the neutron-lib (v2) jobs has been
consistently failing [1] with:

c/_cffi_backend.c:15:17: fatal error: ffi.h: No such file or directory

Is this a known issue?


[1]
http://logs.openstack.org/01/508901/1/check/gate-tempest-dsvm-neutron-src-neutron-lib-ubuntu-xenial/c1d98e2/console.html#_2017-10-04_11_06_07_410466

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

Re: [openstack-dev] [all] Update on Zuul v3 Migration - and what to do about issues

[Boden Russell]

On 10/3/17 5:17 AM, Sean Dague wrote:
> 
> Do we have a defined point on the calendar for getting the false
> negatives back below the noise threshold otherwise a rollback is
> implemented so that some of these issues can be addressed in parallel
> without holding up community development?

Along the same lines; where is the best place to get help with zuul v3
issues? The neutron-lib gate is on the floor with multiple problems; 2
broken gating jobs preventing patches from landing and all periodic jobs
broken preventing (safe) releases of neutron-lib. I've been adding the
issues to the etherpad [1] and trying to work through them solo, but
progress is very slow.


[1] https://etherpad.openstack.org/p/zuulv3-migration-faq

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

[openstack-dev] [neutron] neutron-lib impact: transitioning to callback payload objects

[Boden Russell]

If your project uses neutron callbacks, please read on.


As we discussed during the PTG [1] in the "Cross project related topics"
section, we'll treat the adoption of the new payload style objects as we
have been with other lib impact changes.

That said, the first (and easiest) set of patches are queued up [2]. All
sub-project patches in [2] should depend on the neutron change [3] and
ideally they can be ready to land when we pull the trigger on [3].

If folks could help with this reviewing effort, it'd go a long way in
making this transition smooth.

Thanks

[1] https://etherpad.openstack.org/p/neutron-queens-ptg
[2] https://review.openstack.org/#/q/message:%22use+new+payload+objects%22
[3] https://review.openstack.org/#/c/474213/

__
OpenStack Development Mailing 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][neutron] checking link integrity in the gate

[Boden Russell]

On 9/5/17 11:03 AM, Doug Hellmann wrote:
> Is eventlet being initialized (or partially initialized) when a module
> from the application is imported for the auto-generated API
> documentation?
More than likely :)
But even if they are, what's the fix/workaround?

__
OpenStack Development Mailing List (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] [docs][neutron] checking link integrity in the gate

[Boden Russell]

We've (neutron) run into a few cases where our doc links become
outdated/invalid and are dead. These dead links are not detected in the
doc build today, but is something we might be interested in enabling.

I'm no sphinx expert, but best I can tell that's done with the
"linkcheck" builder [1]. I've tried munking with this, but sporadically
get an eventlet error [2] followed by an indefinite hang; I've yet to
find a way around this even if setting linkcheck_workers to 1.

Also note that most project's doc/Makefile have a linkcheck target, but
that's also failing.

Does anyone know the best way to have our links checked during the doc
build?

Thanks

[1]
http://www.sphinx-doc.org/en/stable/config.html#options-for-the-linkcheck-builder
[2] http://paste.openstack.org/show/620423/

__
OpenStack Development Mailing 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] [python-openstackclient][python-openstacksdk][neutron] supporting resource extensions with our CLI

[Boden Russell]

On 8/8/17 10:29 AM, Akihiro Motoki wrote:
> My reply applies to 'resource' extension but does not apply to
> 'attribute extension'

My apologies for using confusing terminology; as you pointed out we
don't currently have a good solution for attribute extensions with OSC
and I've tried to outline the technicals in the RFE style bug [1] where
I hope we can continue this discussion.

python-neutronclient does support these attribute extensions, but as of
today neutronclient gives deprecation warnings when used; so users are
"concerned" when they see this and we don't have a complete story for
OSC. Perhaps we can suppress those deprecations until we figure out a
path forward?

Thanks


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

__
OpenStack Development Mailing 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] [python-openstackclient][python-openstacksdk][neutron][nova] supporting resource extensions with our CLI

[Boden Russell]

On 8/7/17 10:39 PM, Clint Byrum wrote:
> If the thing you're doing doesn't fit in the mainline API, then what
> you're doing is making a new API. Extensions just bypass the important
> part where that API gets designed and thought through.

Irrespective of opinions as to if API extensions are good or not, the
fact of the matter is we support them in neutron today and as a result
we have users that rely on them as well as the ability to interface
(CLI) with such extensions via python-neutronclient. That said, I think
this concern has been heard [1] and we will work to address it
short-to-mid term.

As to neutron's longer-term goals W/R/T API extensions; I can't speak to
that.

[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/120759.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] [python-openstacksdk] Status of python-openstacksdk project

[Boden Russell]

On 8/4/17 1:26 PM, Boris Pavlovic wrote:
> 
> That's not going to work for dozens of OpenStack projects. It's just
> won't scale. Every project should maintain plugin for their project. And
> it should be enough to say "pip install python-client" that
> extend the Core OpenStack python client and adds support of new commands. 
> 
> The whole core part should be only about how to make plugins interface
> in such way that it's easy to extend and provide to end user nice user
> experience from both side (shell & python) and nice and stable interface
> for client developers . 


I echo Boris's point; if the client side isn't pluggable and extendable
(in a reusable fashion), then how can we build a consistent CLI for
users of our APIs that do support pluggable (potentially out-of-tree)
extensions (ex: neutron)?

It's a concern with the current trajectory of OSC/SDK and one I
mentioned on the ML last week [1].

If we're going to reevaluate this client side "plumbing", I truly hope
we take into consideration how our users are interfacing with the CLI,
which today, includes the ability to handle API resource extensions in
the classic python client, but not in OSC.

As per the bug/RFE linked in [1], I'm willing to throw some code down to
help make this happen; it's just not clear who the right team is to
queue this discussion/code up with.


[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-August/120613.html

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

[openstack-dev] [python-openstackclient][python-openstacksdk][neutron][nova] supporting resource extensions with our CLI

[Boden Russell]

I think we have a gap in our OSC CLI for non-stadium plugin/driver
projects (neutron plugin projects, nova driver projects) that implement
RESTful resource API attribute extensions.

For details, go directly to [1].
For a summary read on...


For OpenStack APIs that support extensions (ex [2]), the classic
python-client CLIs worked "out of the box" for extensions
adding attributes to existing RESTful resources.

For example, your project has a neutron plugin that adds a 'my_bool'
boolean attribute to 'network' resources that can be set via POST/PUT
and is returned with GET. This just works with the python-neutronclient
CLI without any client-side code changes.


However, with OSC resource attributes must be added directly/statically
to the sdk's resource and then consumed in the client; the support does
not come "for free" in the CLI. While this is fine for stadium projects
(they can contribute directly to the sdk/client), non-stadium projects
have no viable option to plugin/extend the CLI today for this type of
API extension mechanism.

With the phasing out of the python clients, a number of our users will
be left without a CLI to interface with these extensions.

I'd like to try and close this gap in Queens and welcome discussion in [1].

Thanks


[1] https://bugs.launchpad.net/python-openstacksdk/+bug/1705755
[2] https://wiki.openstack.org/wiki/NeutronDevelopment#API_Extensions

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

[openstack-dev] [neutron] neutron-lib impact: use plugin common constants from neutron-lib

[Boden Russell]

If your project uses the constants from neutron.plugins.common.constants
please read on.

Many of the common plugin constants from neutron are now in neutron-lib
[1] and we're ready to consume them neutron [2].

Suggested actions:
- If your project uses any rehomed constants [1], please update your
imports to use them from neutron-lib. Best I can tell no other stadium
projects are using these constants today, but a number of non-stadium
projects are [3].


We can discuss when to land [2] during our weekly neutron meeting.

Thanks


[1] https://review.openstack.org/#/c/429036/
[2] https://review.openstack.org/#/c/469495/
[3]
http://codesearch.openstack.org/?q=from%20neutron%5C.plugins%5C.common%20import%20constants

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

[openstack-dev] [neutron] neutron-lib impact: attribute functions and constants now in neutron-lib

[Boden Russell]

If your project uses neutron.api.v2.attributes please read on.

A bulk of neutron.api.v2.attributes has been rehomed into neutron-lib
[1][2] and we've begun consuming these changes in neutron and stadium
projects.

Today we are working to consume:
- The core resource/collection name constants [3] such as NETWORK,
NETWORKS, etc..
- Many of the "helper functions" from attributes [4].

Subsequent patches will work to consume to remainder of attributes
including the global resource attribute map.


Suggested actions:
- If your project uses any of the core resource/collection constants
from attributes and is not included in [3], please move your imports
over and use neutron-lib.
- If your project uses any of the helper functions from attributes,
please move your code over to neutron-lib's implementation. Best I can
tell [4] covers all uses, but perhaps I missed something.

Feel free to catch me on #openstack-neutron as 'boden' if you have any
questions.

Thanks

[1] https://review.openstack.org/#/c/394244/
[2] https://review.openstack.org/#/c/449277/
[3]
https://review.openstack.org/#/q/message:%22use+core+resource+attribute+constants%22
[4] https://review.openstack.org/#/q/message:%22use+attribute+functions%22

__
OpenStack Development Mailing 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] diagnostics

[Boden Russell]

On 5/12/17 12:31 PM, Armando M. wrote:
>
> Please, do provide feedback in case I omitted some other key takeaway.
>
> [1] https://etherpad.openstack.org/p/pike-neutron-diagnostics
> [2] 
> http://specs.openstack.org/openstack/neutron-specs/specs/pike/diagnostics.html
>
Glad you all got a chance to discuss this topic!

I've added some additional notes and comments to the etherpad ([1] from
your list). Please feel free to reach out to me on IRC ('boden') for further
discussion.

Thanks



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

[openstack-dev] [neutron] neutron-lib impact: extra_dhcp_opt extension now in neutron-lib

[Boden Russell]

If your project uses neutron.extensions.extra_dhcp_opt please read on.

The extra_dhcp_opt is now available as a neutron-lib API definition [1]
and consumption has begun [2].

Recommended action:
- If you're a stadium project; you should be covered in [2].
- If not, please update your project's imports to use the neutron-lib
API def rather than the neutron extension. The work in [2] can be used
as reference.

We can discuss when to land the changes in neutron [3] during our weekly
meetings.

Thanks


[1] https://review.openstack.org/#/c/428387/
[2]
https://review.openstack.org/#/q/message:%22use+extra_dhcp_opt+api-def%22
[3] https://review.openstack.org/#/c/464044/

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

[openstack-dev] [neutron] neutron-lib impact: ml2 MechanismDriver and constants are now in neutron-lib

[Boden Russell]

If your project uses the MechanismDriver class or associated constants
in neutron.plugins.ml2.driver_api, please read on. If not, it's probably
safe to delete this message.

For details on what's been rehomed, please see [1].

Suggested actions:
- If you're a stadium project, you should be already covered with [2].
- If not and your project uses any of the rehomed code [1], please
update your imports to use the neutron-lib version.

We can discuss when to land the neutron patch that removes the rehomed
code [3] in our weekly neutron meeting.

Thanks


[1] https://review.openstack.org/#/c/428997/
[2]
https://review.openstack.org/#/q/message:%22+use+MechanismDriver+from+neutron-lib%22
[3] https://review.openstack.org/#/c/462731

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

Re: [openstack-dev] [neutron] neutron-lib impact: neutron.plugins.common.constants are now in neutron-lib

[Boden Russell]

On 5/3/17 8:55 AM, Eric Fried wrote:
> Can you please point to the change(s) that move the constants?  Or
> provide some other way to figure out which are affected?
>
This Hound search [1] provides an overall picture and can be honed to
specific projects as needed. The search will identify all modules that
import the constants, but the respective source will need to be inspected
to determine which constants are applicable to neutron-lib.

Also, feel free to reach out to me ('boden') on #openstack-neutron if
there's questions/comments/etc..

[1] 
http://codesearch.openstack.org/?q=from%20neutron%5C.plugins%5C.common%20import%20constants

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

[openstack-dev] [neutron] neutron-lib impact: neutron.plugins.common.constants are now in neutron-lib

[Boden Russell]

If your project uses neutron.plugins.common.constants please read on. If
not, it's probably safe to discard this message.

A number of the constants from neutron.plugins.common.constants have
moved into neutron-lib:
- The service type constants are in neutron_lib.plugins.constants
- Many of the others are in neutron_lib.constants
- A few have not yet been rehomed into neutron-lib

Suggested actions:
- If you work on a stadium project, you should already be covered [1].
- Otherwise, please move your project's imports to use the constants in
neutron-lib rather than neutron. See the work in [1] for reference.

Once we see sub-projects moved off these constants, we'll begin removing
them from neutron.plugins.common.constants (likely as a set of patches).
We can discuss this topic in our weekly neutron meeting.

Thanks


[1]
https://review.openstack.org/#/q/message:%22use+neutron-lib+constants+rather%22

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

[openstack-dev] [neutron] neutron-lib impact: Port security extension moved

[Boden Russell]

The neutron portsecurity extension has been rehomed into neutron-lib and
we are now in the process of consuming it.

Suggested actions:
- If your project consumes neutron.extensions.portsecurity [2] and
there's not an existing patch for your project in [1], please move your
imports over to neutron-lib's portsecurity API definition. You can use
[3] for reference.

We'll hold off on merging [3] until consumers have a chance to switch
over and can discuss this topic in our weekly neutron meeting.

Thanks


[1]
https://review.openstack.org/#/q/message:%22use+neutron-lib+port+security%22
[2]
http://codesearch.openstack.org/?q=from%20neutron%5C.extensions%20import%20portsecurity
[3] https://review.openstack.org/#/c/461464/

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

[openstack-dev] [neutron] neutron-lib impact: neutron.callbacks moved to neutron-lib

[Boden Russell]

If you work on a neutron sub-project that uses neutron.callbacks, please
read on. If not, it's probably safe to discard this message.

We've been talking about it for awhile, but it's finally coming to
fruition; we're transitioning over to neutron-lib's callbacks.

To ease sync issues across projects, we've taken a happy-path approach
that stages the transition as described in the commit message of [1].

Suggested per-project actions:
- If you're a stadium project, you're likely already covered [2]. Just
help shepherd the patch through review and ensure there's no issues.
- If not and your project uses neutron.callbacks, consider moving over
to neutron-lib's callbacks in the near future. You can use the work in
[2] as reference.

Once we get projects moved over to neutron-lib's callbacks we'll be
deleting the neutron.callbacks package all together. We can discuss when
the "right time" is for this during our weekly neutron meeting.

Thanks

[1] https://review.openstack.org/#/c/439146/
[2]
https://review.openstack.org/#/q/message:%22+consume+neutron-lib+callbacks%22

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

[openstack-dev] [neutron] neutron-lib impact: ServicePluginBase and PluginInterface moved

[Boden Russell]

Head's up: the ServicePluginBase and PluginInterface classes are being
removed from neutron.

- ServicePluginBase is available in neutron-lib.
- PluginInterface is likely going to remain private in neutron-lib;
pretty much everyone is using ServicePluginBase anyway.

A patch is proposed to neutron [1] consuming the above changes and
patches have been proposed to stadium projects for the same [2]. For all
other projects using these classes, please sync-up and consume from
neutron-lib.

We'll hold off on landing [1] until consumers get a chance to sync-up.

For a deeper dive (and comments on) into why we're likely making
PluginInterface private, please see [3].

Thanks


[1] https://review.openstack.org/#/c/441129/
[2] https://review.openstack.org/#/q/message:+consume+ServicePluginBase
[3] https://review.openstack.org/#/c/424151/

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

[openstack-dev] [neutron] neutron-lib pep8 hacking checks

[Boden Russell]

If your project is or plans to use neutron-lib moving forward, please
read on.

At the PTG we discussed how to roll-out new hacking checks in
neutron-lib. In summary we decided to move forward using a single set of
hacking checks, as proposed by [1] (see 'doc/source/usage.rst' in that
patch for gory details).

The major implication is that sub-projects using neutron-lib's hacking
checks [2] will pick-up new checks as we release them to the lib.

This email serves as a heads-up and friendly reminder on that topic.

Please direct any technical discussion to the patch [1] so we can
capture it along with the implementation.

Thanks

[1] https://review.openstack.org/421484/
[2]
http://codesearch.openstack.org/?q=local-check-factory%20%3D%20neutron_lib%5C.hacking%5C.checks.factory

__
OpenStack Development Mailing List (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] Does your plugin support updating network provider extended attributes?

[Boden Russell]

Today, most, if not all plugins forbid updating network provider
extended attributes. Our docs [1] even say so:

"Most Networking plug-ins and drivers do not support updating any
provider related attributes."

To formalize this we were discussing the possibility of forbidding
updates (PUT) at the API layer [2]. However, such a change begs the
question of backwards compatibility; the motivation for this email.

Question:
Are there any neutron plugins that DO support updating network provider
extended attributes [1]?


Thanks

PS: Just to make sure we cover our bases, I'll send a quick note to the
operator list as well; referring to this one.


[1]
https://developer.openstack.org/api-ref/networking/v2/#provider-extended-attributes
[2] https://review.openstack.org/421961/

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

Re: [openstack-dev] [neutron] - Neutron team social in Atlanta on Thursday

[Boden Russell]

+1

On 2/17/17 2:18 PM, Kevin Benton wrote:
> Hi all,
> 
> I'm organizing a Neutron social event for Thursday evening in Atlanta
> somewhere near the venue for dinner/drinks. If you're interested, please
> reply to this email with a "+1" so I can get a general count for a
> reservation.
> 
> 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-dev] [neutron] neutron-lib impact: portbindings extension moved to neutron-lib

[Boden Russell]

A new version (1.1.0) of neutron-lib was recently released.
Among other things, this release rehomes the neutron portbindings API
extension [1].

A consumption patch to use the rehomed code has been submitted to
neutron [2] and once merged will impact consumers who use portbindings
constants from neutron.

While a patch for each affected project has been submitted [3], I only
plan to shepherd those patches in [3] that target stadium projects. For
all others (non-stadium) please encourage your team to help drive the
patch through review.

For more details on consuming neutron-lib, please see [4].


[1] https://review.openstack.org/411960/
[2] https://review.openstack.org/422210/
[3] https://review.openstack.org/#/q/topic:rehome-portbindings-apidef
[4]
https://github.com/openstack/neutron-lib/blob/master/doc/source/contributing.rst#phase-4-consume

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

[openstack-dev] [neutron] neutron-lib impact: providernet extension moved to neutron-lib

[Boden Russell]

A new version (1.1.0) of neutron-lib was recently released.
Among other things, this release rehomes the neutron providernet API
extension [1].

A consumption patch to use the rehomed code has been submitted to
neutron [2] and once merged will impact consumers who use providernet
constants from neutron.

While a patch for each affected project has been submitted [3], I only
plan to shepherd those patches in [3] that target stadium projects. For
all others (non-stadium) please encourage your team to help drive the
patch through review.

For more details on consuming neutron-lib, please see [4].


[1] https://review.openstack.org/418560/
[2] https://review.openstack.org/421562/
[3] https://review.openstack.org/#/q/topic:lib-providernet-apidef
[4]
https://github.com/openstack/neutron-lib/blob/master/doc/source/contributing.rst#phase-4-consume

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

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

[Boden Russell]

I would encourage anyone working on neutron-lib related changes to have
a peek at the recently renovated contributing doc [1] if you haven't
already.

In particular the 'Phase 4: Consume' section [2] provides some tips on
how we see this workflow playing out.

Thanks

[1]
https://github.com/openstack/neutron-lib/blob/master/doc/source/contributing.rst
[2]
https://github.com/openstack/neutron-lib/blob/master/doc/source/contributing.rst#phase-4-consume


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

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

Re: [openstack-dev] [all] Useful tool for easier viewing of IRC logs online

[Boden Russell]

> Source code is here: https://github.com/abashmak/chrome-irc-filter
> 
> Comments, suggestions are welcome.

Nice thanks!

I've always wanted a tool that could alert me of "missed mentions" when
I'm offline IRC rather than having to manually parse the IRC logs for
those times I'm offline. However I'm guessing that falls outside the
scope of this tool or could be done with some other tool (I haven't
investigated yet)?

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

[openstack-dev] [neutron][neutron-lib] No meeting today

[Boden Russell]

Our small neutron-lib crowd is busy today, so we won't hold the meeting.

For neutron-lib planning/tasks/etc., please see [1].
If time permits, please take a pass through the neutron-lib reviews [2].

Thanks

[1] https://etherpad.openstack.org/p/nl-planning
[2] https://review.openstack.org/#/q/project:openstack/neutron-lib

__
OpenStack Development Mailing 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] Let's clean up APi reference

[Boden Russell]

I probably missed this, but is there a way for out-of-tree plugins that
have extensions to add them to the api-ref?

For example, suppose we wanted to api-ref the extensions in [1].

Thanks

[1] http://goo.gl/cGVXMN


On 8/18/16 6:16 AM, Akihiro Motoki wrote:
> Hi Neutron team,
> 
> As you may know, the OpenStack API references have been moved into
> individual project repositories, but it contains a lot of wrong
> information now :-(
> 
> Let's clean up API reference.
> It's now time to start the clean up and finish the cleanup by Newton-1.
> 
> I prepared the etherpad page to share the guideline of the cleanup and
> useful information.
> This page shares my experience of 'router' resource cleanup.
> 
> https://etherpad.openstack.org/p/neutron-api-ref-sprint
> 
> I hope everyone work on at least one resource :)
> The etherpad page has the progress tracking section (bottom of the page)
> Make sure to add your name when you start to work.
> 
> Feel free to ask me if you have a question.
> 
> Thanks,
> Akihiro
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

[openstack-dev] [all] Generating python API signature + diff reports

[Boden Russell]

Do any projects have an interest in generating python API signature
reports capable of showing "what's new/changed/removed" in a release
(ex: [2])? If so, read on.


We recently developed a tool in neutron-lib [1] capable of inspecting +
generating python API signature and diff reports.

Its current high-level features include:
- Inspecting python source without installing any dependencies.
- Generating python API signature reports in a JSON format. For example [3].
- Diffing python two JSON API signature reports; showing what's
new/removed/changed/unchanged. For example [2].
- Showing python API signature reports in a user-friendly format.
- Filtering (blacklist) inspection and report output using regex patterns.

We're currently using the tool to generate a "what's new" report for
neutron-lib releases, but hope to incorporate it into the actual release
notes longer term.

In its current form, the implementation a prototype living as a
neutron-lib tool.
However, if other projects may have an interest in such tool I'd
consider spinning the tool off into it's own repo and spending some time
solidifying the implementation.

I'll gauge interest based on feedback here, and/or find me on
#openstack-neutron as 'boden'.


[1] https://github.com/openstack/neutron-lib/blob/master/tools/pyir.py
[2] http://paste.openstack.org/show/562199/
[3] http://paste.openstack.org/show/562200/

__
OpenStack Development Mailing 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][infra] Switch to xenial and Neutron unit tests

[Boden Russell]

>From a vmware-nsx perspective, we have added some temp gate jobs that
run pep8, py27 and py35 on Xenial (check-xenial-epep8,
check-xenial-epy27 and check-xenial-epy35 respectively). Everything (on
Xenial) is passing as indicated in recent job results [1].

That said, please feel free to create vmware-nsx defects [2] as needed
for any such failures and/or reach out to me on IRC ('boden').

Thanks

[1] https://review.openstack.org/#/c/342128
[2] https://bugs.launchpad.net/vmware-nsx


On 7/12/16 6:18 PM, Armando M. wrote:
> Hi Neutrinos,
> 
> OpenStack infra is in the process of testing OpenStack tests on ubuntu
> Xenial so that it can be adopted as default platform for testing in the
> Gate. It is likely that the switch is going to happen sometime next week.
> 
> It was noted in the channel at [1] that some unit tests are not
> currently passing for the following repos: vmware-nsx, networking-cisco
> and group-based-policy.
> 
> For those of you who may be affected, please make sure to read IRC logs
> and stay on top of this issue.
> 
> Cheers,
> Armando
> 
> [1]
> http://eavesdrop.openstack.org/irclogs/%23openstack-neutron/%23openstack-neutron.2016-07-12.log.html#t2016-07-12T21:39:32
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

__
OpenStack Development Mailing 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] [stable][all] Tagging kilo-eol for "the world"

[Boden Russell]

On 6/2/16 4:31 AM, Tony Breeds wrote:
> Any projects that will be EOL'd will need all open reviews abandoned before it
> can be processed. 

openstack/vmware-nsx kilo patches have been abandoned in preparation for
the EOL.

Thanks

__
OpenStack Development Mailing 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] Diagnostics & troubleshooting design summit summary and next steps

[Boden Russell]

Assaf, thanks for driving this session.

As a newbie to the design sessions, I think presenting a brief "context"
up-front is helpful. IMO the key word here is "brief" (5 min or less for
example) and furthermore should not open the floor for digression given
the short time-frame we have per session. Some of us will be experts on
the topic, others of us will not have had time to do the proper research
before heading into the session. This "intro" gets us all on the same page,
or closer to it.

Finally, it might be nice to collaborate on the intro content with the main
players of the session topic. Not saying the intro needs to be reviewed,
but typically it seems there are a few individuals with vested
interest / knowledge in the space and it would be nice if they could work
together on developing the content.


On 5/6/16 2:38 PM, Assaf Muller wrote:
> It is my personal experience that unless I do my homework, design
> summit discussions largely go over my head. I'd guess that most people
> don't have time to research the topic of every design session they
> intend to go to, so for the session I lead I decided to do the
> unthinkable and present the context of the discussion [1] with a few
> slides [2] (That part of the session took I think 3 minutes). I'd love
> to get feedback particularly on that, if people found it useful we may
> consider increasing adoption of that habit for the Barcelona design
> summit.
>
> The goal for the session was to achieve consensus on the very high
> level topics: Do we want to do Neutron diagnostics in-tree and via the
> API. I believe that goal was achieved, and the answer to both
> questions is 'yes'.
>
> Since there's been at least 4 RFEs submitted in this domain, the next
> step is to try and converge on one and iterate on an API. For these
> purposes we will be using Hynek's spec, under review here [3]. I was
> approached by multiple people that are interested in assisting with
> the implementation phase, please say so on the spec so that Hynek will
> be able to add you as a contributor.
>
> I foresee a few contention points, chief of which is the abstraction
> level of the API and how best to present diagnostics information in a
> way that is plugin agnostic. The trick will be to find an API that is
> not specific to the reference implementation while still providing a
> great user experience to the vast majority of OpenStack users.
>
> A couple of projects in the domain were mentioned, specifically
> Monasca and Steth. Contributors from these projects are highly
> encouraged to review the spec.
>
> [1] https://etherpad.openstack.org/p/newton-neutron-troubleshooting
> [2] 
> https://docs.google.com/presentation/d/1IBVZ6defUwhql4PEmnhy3fl9qWEQVy4iv_IR6pzkFKw/edit?usp=sharing
> [3] https://review.openstack.org/#/c/308973/
>
> __
> OpenStack Development Mailing List (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][nova][oslo] Common backoff & timeout utils

[Boden Russell]

On 4/21/16 1:38 PM, Joshua Harlow wrote:
> This might be harder in retrying, but I think I can help u make
> something that will work, since retrying has a way to provide a custom
> delay function.

Thanks for that. My question was if this might be useful as a new
backoff in retrying (vs a custom delay function in oslo or something).


> https://github.com/rholder/retrying/blob/master/retrying.py#L65
> 
> 'wait_exponential_max'?

When expressed in milliseconds; bingo!
Thanks for doing some of my work :)

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

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

[Boden Russell]

I haven't spent much time on this, so the answers below are a first
approximation based on a quick visual inspection (e.g. subject to change
when I get a chance to hack on some code).

On 4/21/16 12:10 PM, Salvatore Orlando wrote:
> Can you share more details on the "few things we need" that
> retrying is lacking?

(a) Some of our existing code uses a 'stepping' scheme (fist N attempts
with timeout T, next M attempts with timeout U, etc.). For example [1].
This could also be tackled using chaining.
(b) It doesn't appear retrying supports capping (ceiling) exponential
sleep times as we do in [2].

> Do you think oslo_messaging would be a good target? Or do you think it
> should go somewhere else?

My initial thought was to implement it as a subclass of oslo_messaging's
RPCClient [3] with a nice way for consumers to configure the
backoff/retry magic. If consumers want a backing off client, then they
use the new subclass.


[1] https://github.com/openstack/nova/blob/master/nova/conductor/api.py#L147
[2] https://review.openstack.org/#/c/280595/
[3]
https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/rpc/client.py#L208

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

Re: [openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

[Boden Russell]

On 4/20/16 3:29 PM, Doug Hellmann wrote:
> Yes, please, let's try to make that work and contribute upstream if we
> need minor modifications, before we create something new.

We can leverage the 'retrying' module (already in global requirements).
It lacks a few things we need, but those can be implemented using its
existing "hooks" today, or, working with the module owner(s) to push a
few changes that we need (the later probably provides the "greatest good").

Assuming we'll leverage 'retrying', I was thinking the initial goals
here are:
(a) Ensure 'retrying' supports the behaviors we need for our usages in
neutron + nova (see [1] - [5] on my initial note) today. Implementation
details TBD.
(b) Implement a "Backing off RPC client" in oslo, inspired by [1].
(c) Update nova + neutron to use the "common implementation(s)" rather
than 1-offs.

This sounds fun and I'm happy to take it on. However, I probably won't
make much progress until after the summit for obvious reasons. I'll plan
to lead with code, if a RFE/spec/other is needed please let me know.

Additional comments welcomed.


Thanks

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

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

[openstack-dev] [neutron][nova][oslo] Common backoff & timeout utils

[Boden Russell]

Today there are a number of places in nova, neutron and perhaps
elsewhere that employ backoff + timeout strategies (see [1] - [4]).
While we are working towards a unified approach in neutron for RPC [5],
it appears such logic could benefit the greater community as a reusable
oslo implementation.

IMHO such an oslo implementation could:
- Enable backoff/timeout irrespective of client/transport. This would
allow the utils to be used with various clients (HTTP, AMQP RPC, etc.).
- Support namespacing as inspired by the existing neutron patch [5].
- In the future, perhaps, allow multiple (pluggable) backoff strategies
to be used (e.g. configurable backoff).

Anyone adverse to me crafting an initial oslo patch to kick-off the
details on this one?


Thanks


[1] https://github.com/openstack/nova/blob/master/nova/conductor/api.py#L162
[2]
https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/scheduler/utils.py#L356
[3]
https://github.com/openstack/neutron/blob/dd4f1253c951d78a5b497680dfb31317ba469a58/neutron/agent/l3/agent.py#L224
[4]
https://github.com/openstack/neutron/blob/42c6f05f2904cd4c01bcd3f79b1966489f5ad3c1/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_dvr_neutron_agent.py#L189
[5] https://review.openstack.org/#/c/280595/

__
OpenStack Development Mailing List (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] PBAM Extension RFE

[Boden Russell]

I recently added a Neutron RFE [1] that proposes a new extension called
Pluggable Backend Association Mappings (PBAM). This admin-based
extension allows consumers to view Neutron / backend resource mappings,
quickly identify mappings that are out of sync and remediate them.

If this sounds interesting to you, please join us on the RFE [1] for a
discussion and see [2] for a video demo and [3] for the PoC repo that
contains detailed documentation about the extension.

Thanks

[1] https://bugs.launchpad.net/neutron/+bug/1563538
[2] https://www.youtube.com/watch?v=qAY8U8vgbzc
[3] https://github.com/bodenr/neutron/tree/feature/pbam

__
OpenStack Development Mailing 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.messaging] extending notification MessagingDriver

[Boden Russell]

Regarding bug 1426046 (see below) -- Is this just a matter of making the
classes public or are you thinking the driver interface needs more
thought + solidifying before making something extendable?

Perhaps I can donate a cycle to 2 to help get this in.

 On 2/26/15 10:33 AM, Doug Hellmann wrote:
 
 Yes, I don't recommend relying on anything in private modules. It looks
 like even the base class for the notification drivers is private, right
 now. We should probably change that, so I filed
 https://bugs.launchpad.net/oslo.messaging/+bug/1426046.

__
OpenStack Development Mailing 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.messaging] extending notification MessagingDriver

[Boden Russell]

I don't have a public repo -- have been PoCing using a private gitlab to
date... I figured any interest in the driver impl would come out of this
email discussion.

More than happy to provide my PoC code publicly (after a little
clean-up) if there's an interest.


 On 2/26/15 12:01 PM, Sandy Walsh wrote:
 Cool, I'm interested in creating some notification drivers outside of 
 olso-messaging as well (for Kafka support and schema-based notifications). 
 
 Do you have a repo started on this? I'd be keen to have a look.

__
OpenStack Development Mailing 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.messaging] extending notification MessagingDriver

[Boden Russell]

Thanks for filing the bug report...

My driver implementation effectively allows you to filter on
notification events and multicast matches to a given list of topics.

I've been calling it an messaging multicast notification driver and thus
the plugin stevedore entry point I've called 'messaging-multicast'.

The impl basically wraps the oslo messaging driver and does it's
matching and multicasting after the parent... e.g.

def notify(self, ctxt, msg, priority, retry):
_notify = super(AMQPMulticastDriver, self).notify(
ctxt, msg, priority, retry)

# check filters on msg and priority and notify on configured topics
# for any matches below
... code ...

return _notify


The driver is a drop-in replacement anywhere oslo.messaging is used for
notifications and accepts some conf props to set it up.

example config for usage (glance in this example):

rpc_backend = rabbit
...
notification_driver = messaging-multicast
multicast_events = image.upload,image.delete
multicast_topic_prefix = glance.multicast.
publisher_id = GLANCE:MASTER
image.delete = host1,host2
image.upload = host1,host2


The above will send a copy of image.delete and image.upload events to
the glance.multicast.host1 and glance.multicast.host2 topics. It will
use 'GLANCE:MASTER' as the publisher ID in the multicasted events.

Your feedback is appreciated.


 On Thu, Feb 26, 2015, at 07:24 AM, Boden Russell wrote:
 What's the suggested approach for implementing a custom oslo messaging
 driver given the existing impl [1] is private?
 [1] http://goo.gl/cRGNwJ

 On 2/26/15 10:33 AM, Doug Hellmann wrote:
 Yes, I don't recommend relying on anything in private modules. It looks
 like even the base class for the notification drivers is private, right
 now. We should probably change that, so I filed
 https://bugs.launchpad.net/oslo.messaging/+bug/1426046.
 
 Maybe if you can give more details about what your driver wants to do, I
 can provide better feedback about a short-term approach for you.


__
OpenStack Development Mailing List (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] [oslo.messaging] extending notification MessagingDriver

[Boden Russell]

What's the suggested approach for implementing a custom oslo messaging
driver given the existing impl [1] is private?

e.g. I want to provide my own notification messaging driver which adds
functionality atop the existing driver [1]. This can obviously be done
by extending the oslo.messaging.notify._impl_messaging.MessagingDriver
and registering the custom impl as a stevedore plugin. e.g.

---
from oslo.messaging.notify import _impl_messaging as messaging


class MyMessagingDriver(messaging.MessagingDriver):
# impl below
---


This works, but given the private nature of oslo's _impl_messaging I'm
likely not following best practices.

Any feedback is appreciated.

Thanks


[1] http://goo.gl/cRGNwJ


__
OpenStack Development Mailing List (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] [oslo.messaging] notification listener; same target with multiple executors

[Boden Russell]

Is it possible to have multiple oslo messaging notification listeners
using different executors on the same target?

For example, I was to create multiple notification listeners [1] each
using a different executor for the same set of targets (e.g.
glance/notifications).


When I try this [2], only the endpoints associated with the 1st listener
(server) are executed. Note that I'm using rabbitmq this very ad-hoc
test and listening for glance notifications. Also I've tried returning
different results in my endpoint methods.

Finally - when I try [2] and set each listener pool name to different
values; none of my endpoints are executed. This ?might? be a bug, but
needs additional investigation.


I'm still digging into the oslo.messaging impl, but hoping someone here
has existing knowledge on this topic.


Thanks for any assistance.


[1] http://goo.gl/9JHUkz
[2] http://paste.openstack.org/show/172265/

__
OpenStack Development Mailing 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] [glance] Replication on image create

[Boden Russell]

 On 1/15/15 12:59 AM, Flavio Percoco wrote:
 All that being said, it'd be very nice if you could open a spec on
 this topic so we can discuss over the spec review and one of us (or
 you) can implement it if we reach consensus.


I'll create a BP + spec; doing a little homework now...

W / R / T the async task plugins -- are there plans to make the task
definitions more pluggable? Based on what I see right now it appears the
definitions are static[1].

I was expecting to see the list of applicable tasks to be defined via
stevedore entry points or via conf file properties.

e.g.
[entry_points]
glance.async.tasks =
import = glance.common.scripts.image_import
replicate = glance.common.scripts.image_repl
# etc...


Perhaps there's already a BP on this topic, but I didn't find one.

Thanks

[1]
https://github.com/openstack/glance/blob/master/glance/domain/__init__.py#L316

__
OpenStack Development Mailing 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] [glance] Replication on image create

[Boden Russell]

On 1/14/15 1:38 AM, Flavio Percoco wrote:
 On 13/01/15 21:24 -0500, Jay Pipes wrote:
 On 01/13/2015 04:55 PM, Boden Russell wrote:
 Looking for some feedback from the glance dev team on a potential BP…

 This is the solution that I would recommend. Frankly, this kind of
 replication should be an async out-of-band process similar to
 bittorrent. Just have bittorrent or rsync or whatever replicate the
 image bits to a set of target locations and then call the
 glanceclient.v2.client.images.add_location() method:

 https://github.com/openstack/python-glanceclient/blob/master/glanceclient/v2/images.py#L211


 to add the URI of the replicated image bits.
 
 It recently landed in Glance an async workers engine (?) that allows
 for this kind of things to exists. For instance, it'll be used for
 image introspection to extract information from images after they have
 been *imported* into glance.
 
 The right hooks that trigger this async workers maybe need to be
 defined better but the infrastructure is there. Once that's more
 solid, you'll be able to write your own plugin that will do that job
 on every glance image import.
 

While I understand the motivation for suggesting the out of band
approach (async workers or separate process), my major concern here is
the additional processing required. In my particular scenario this would
require the out of band process to pull the image bits back down from
the remote location and then push them back up to the replication
locations. If the image size is decent, this could be a fairly expensive
operation. Moreover an out of band process (IMO) would make for a less
than optimal user experience as users would have to query the image
locations metadata to understand if the image has replicated yet.
Perhaps async workers improves this user experience a bit (can query
worker status), but it still seems cleaner (IMO) to have the replication
happen in-line with the image create flow.


 In a prototype I implemented #1 which can be done with no impact outside
 of the store driver code itself.

 I'm not entirely sure how you did that considering the http storage
 backend is readonly. Are you saying you implemented the add() method
 for the glance_store._drivers.http.Store class?

I was trying to generalize my use case to other glance store drivers,
but my generalization using the http store driver was obviously a poor
choice... My interest and PoC is based on the VMware datastore driver.


Let me ask more directly -- if we wanted to enhance the VMware datastore
driver to support replication (as I described in approach #1 of my
initial email) is this something the community would consider (assume
changes are contained to the VMware datastore driver), or would such an
enhancement be an uphill battle to get reviewed / merged?


__
OpenStack Development Mailing List (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] [glance] Replication on image create

[Boden Russell]

Looking for some feedback from the glance dev team on a potential BP…

The use case I’m trying to solve is —

As an admin, I want my glance image bits replicated to multiple store
locations (of the same store type) during a glance create operation.

For example, I have 3 HTTP based backend locations I want to store my
glance image bits on. When I create / upload a new glance image, I want
those bits put onto all 3 HTTP based locations and have the image's
'locations' metadata properly reflect all stored locations.


There are obviously multiple approaches to getting this done.

[1] Allow per glance store drivers the ability to manage config and
connectivity to multiple backends. For example in the glance-api.conf:

[DEFAULT]
store_backends = http1,http2,http3
...
[http1]
# http 1 backend props
...
[http2]
# http 2 backend props
...
[http2]
# http 2 backend props
...

And then in the HTTP store driver use a configuration approach like
cinder multi-backend does (e.g.:
https://github.com/openstack/cinder/blob/2f09c3031ef2d2db598ec4c56f6127e33d29b2cc/cinder/volume/configuration.py#L52).
Here, the store driver handles all the logic w/r/t pushing the image
bits to all backends, etc..


[2] A separate (3rd party) process which handles the image replication
and location metadata updates... For example listens for the glance
notification on create and then takes the steps necessary to replicate
the bits elsewhere and update the image metadata (locations).

[3] etc...


In a prototype I implemented #1 which can be done with no impact outside
of the store driver code itself. I prefer #1 over #2 given approach #2
may need pull the image bits back down from the initial location in
order to push for replication; additional processing.

Is the dev team adverse to option #1 for the store driver's who wish to
implement it and / or what are the other (preferred) options here?


Thank you,
- boden


__
OpenStack Development Mailing 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 Havana End of Upstream Support Lifetime

[Boden Russell]

On 10/9/14 1:31 PM, Chris Friesen wrote:
 On 10/09/2014 08:12 AM, Jeremy Stanley wrote:
  On 2014-09-30 01:38:29 + (+), Jeremy Stanley wrote:
  [...]
  the tips of these branches have been tagged havana-eol in
  preparation for branch deletion. The list of affected Git
  repositories is as follows:
 
   openstack-dev/devstack
   openstack-dev/grenade
   openstack/ceilometer
   openstack/cinder
   openstack/designate
   openstack/glance
   openstack/heat
   openstack/horizon
   openstack/keystone
   openstack/neutron
   openstack/nova
   openstack/openstack-manuals
   openstack/oslo-incubator
   openstack/oslo.config
   openstack/requirements
   openstack/swift
   openstack/tempest
   openstack/trove
 
  Just following up to note that I finally removed the stable/havana
  branches of the above mentioned projects, in accordance with the EOL
  announcement from a couple weeks ago.

 Just curious...why do we remove the stable branches for old releases? Is the 
 idea to force people onto new branches?

If I'm not mistaken; it appears the tag rename from havana - havana-eol 
may be effecting the upgrade CI tests in recent commits (ex: [1]).

For example in real-db-upgrade_nova_mysql_user001:th-mysql:
[snip]

2014-10-09 17:12:11,771 [output] Database is from Grizzly! Upgrade via Havana
2014-10-09 17:12:11,774 [output] error: branch 'stable/havana' not found.
2014-10-09 17:12:11,784 [output] Fetching origin
2014-10-09 17:12:16,634 [output] Switched to a new branch 'stable/havana'
2014-10-09 17:12:16,639 [output] fatal: ambiguous argument 
'remotes/origin/stable/havana': unknown revision or path not in the working 
tree.

[/snip]

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


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