Re: [openstack-dev] [ALL][PTLs] [Community goal] Toggle the debug option at runtime

[Sławomir Kapłoński]

Hi,


> Wiadomość napisana przez ChangBo Guo <glongw...@gmail.com> w dniu 26.03.2018, 
> o godz. 14:15:
> 
> 
> 2018-03-22 16:12 GMT+08:00 Sławomir Kapłoński <sla...@kaplonski.pl>:
> Hi,
> 
> I took care of implementation of [1] in Neutron and I have couple questions 
> to about this goal.
> 
> 1. Should we only change "restart_method" to mutate as is described in [2] ? 
> I did already something like that in [3] - is it what is expected?
> 
>  Yes , let's the only  thing.  we need test if that if it works .

Ok, so please take a look at my patch for neutron if that is what we should do 
:)

> 
> 2. How I can check if this change is fine and config option are mutable 
> exactly? For now when I change any config option for any of neutron agents 
> and send SIGHUP to it it is in fact "restarted" and config is reloaded even 
> with this old restart method.
>  
> good question, we indeed thought this question when we proposal  the 
> goal.  But It seems difficult to test  that consuming projects like Neutron 
> automatically. 

I was asking rather about some manual test instead of automatic one.

> 
> 3. Should we add any automatic tests for such change also? Any examples of 
> such tests in other projects maybe?
>  There is no example for tests now, we only have some unit tests  in 
> oslo.service .
> 
> [1] 
> https://governance.openstack.org/tc/goals/rocky/enable-mutable-configuration.html
> [2] https://docs.openstack.org/oslo.config/latest/reference/mutable.html
> [3] https://review.openstack.org/#/c/554259/
> 
> —
> Best regards
> Slawek Kaplonski
> sla...@kaplonski.pl
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
> -- 
> ChangBo Guo(gcb)
> Community Director @EasyStack
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl


__
OpenStack Development Mailing 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][PTLs] [Community goal] Toggle the debug option at runtime

[Sławomir Kapłoński]

Hi,

I took care of implementation of [1] in Neutron and I have couple questions to 
about this goal.

1. Should we only change "restart_method" to mutate as is described in [2] ? I 
did already something like that in [3] - is it what is expected?

2. How I can check if this change is fine and config option are mutable 
exactly? For now when I change any config option for any of neutron agents and 
send SIGHUP to it it is in fact "restarted" and config is reloaded even with 
this old restart method.

3. Should we add any automatic tests for such change also? Any examples of such 
tests in other projects maybe?

[1] 
https://governance.openstack.org/tc/goals/rocky/enable-mutable-configuration.html
[2] https://docs.openstack.org/oslo.config/latest/reference/mutable.html
[3] https://review.openstack.org/#/c/554259/

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl


__
OpenStack Development Mailing 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]Does neutron-server support the main backup redundancy？

[Sławomir Kapłoński]

Hi,

Neutron agents communicate with server through RPC messages. So agent don't 
need to know how many servers are on the other end of queue to consume 
messages. If You will start new neutron-server it will connect to same rabbitmq 
as other servers and to same db and will start processing messages.
If Your new server should also process API requests, You should put You neutron 
server behind some load balancer and add new server as a backend to Your farm.

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl

> Wiadomość napisana przez Frank Wang  w dniu 
> 22.03.2018, o godz. 03:25:
> 
> Thanks for your response, another question is Does the compute nodes or 
> agents know how many neutron-servers running? I mean If there was a server 
> corrupt, they will automatically connect to other servers?
> 
> Thanks,
> 
> At 2018-03-21 18:14:47, "Miguel Angel Ajo Pelayo"  wrote:
> You can run as many as you want, generally an haproxy is used in front of 
> them to balance load across neutron servers.
> 
> Also, keep in mind, that the db backend is a single mysql, you can also 
> distribute that with galera.
> 
> That is the configuration you will get by default when you deploy in HA with 
> RDO/TripleO or OSP/Director.
> 
> On Wed, Mar 21, 2018 at 3:34 AM Kevin Benton  wrote:
> You can run as many neutron server processes as you want in an active/active 
> setup. 
> 
> On Tue, Mar 20, 2018, 18:35 Frank Wang  wrote:
> Hi All,
>  As far as I know, neutron-server only can be a single node, In order to 
> improve the reliability of the system, Does it support the main backup or 
> active/active redundancy? Any comment would be appreciated.
> 
> 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 Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
>  
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] Poll: S Release Naming

[Sławomir Kapłoński]

Indeed. I now tried from different IP address and I was able to vote. Thx a lot 
for help.

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl

> Wiadomość napisana przez Thierry Carrez <thie...@openstack.org> w dniu 
> 14.03.2018, o godz. 10:05:
> 
> Jens Harbott wrote:
>> 2018-03-14 9:21 GMT+01:00 Sławomir Kapłoński <sla...@kaplonski.pl>:
>>> Hi,
>>> 
>>> Are You sure this link is good? I just tried it and I got info that 
>>> "Already voted" which isn't true in fact :)
>> 
>> Comparing with previous polls, these should be personalized links that
>> need to be sent out to each voter individually, so I agree that this
>> looks like a mistake.
> 
> We crashed CIVS for the last naming with a private poll sent to all the
> Foundation membership, so the TC decided to use public (open) polling
> this time around. Anyone with the link can vote, nothing was sent to
> each of the voters individually.
> 
> The "Already voted" error might be due to CIVS limiting public polling
> to one entry per IP, and a colleague of yours already voted... Maybe try
> from another IP address ?
> 
> -- 
> Thierry Carrez (ttx)
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] Poll: S Release Naming

[Sławomir Kapłoński]

Hi,

Are You sure this link is good? I just tried it and I got info that "Already 
voted" which isn't true in fact :)

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl

> Wiadomość napisana przez Paul Belanger  w dniu 
> 14.03.2018, o godz. 00:58:
> 
> Greetings all,
> 
> It is time again to cast your vote for the naming of the S Release. This time
> is little different as we've decided to use a public polling option over per
> user private URLs for voting. This means, everybody should proceed to use the
> following URL to cast their vote:
> 
>  
> https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_40b95cb2be3fcdf1=8cfdc1f5df5fe4d3
> 
> Because this is a public poll, results will currently be only viewable by 
> myself
> until the poll closes. Once closed, I'll post the URL making the results
> viewable to everybody. This was done to avoid everybody seeing the results 
> while
> the public poll is running.
> 
> The poll will officially end on 2018-03-21 23:59:59[1], and results will be
> posted shortly after.
> 
> [1] 
> http://git.openstack.org/cgit/openstack/governance/tree/reference/release-naming.rst
> ---
> 
> According to the Release Naming Process, this poll is to determine the
> community preferences for the name of the R release of OpenStack. It is
> possible that the top choice is not viable for legal reasons, so the second or
> later community preference could wind up being the name.
> 
> Release Name Criteria
> 
> Each release name must start with the letter of the ISO basic Latin alphabet
> following the initial letter of the previous release, starting with the
> initial release of "Austin". After "Z", the next name should start with
> "A" again.
> 
> The name must be composed only of the 26 characters of the ISO basic Latin
> alphabet. Names which can be transliterated into this character set are also
> acceptable.
> 
> The name must refer to the physical or human geography of the region
> encompassing the location of the OpenStack design summit for the
> corresponding release. The exact boundaries of the geographic region under
> consideration must be declared before the opening of nominations, as part of
> the initiation of the selection process.
> 
> The name must be a single word with a maximum of 10 characters. Words that
> describe the feature should not be included, so "Foo City" or "Foo Peak"
> would both be eligible as "Foo".
> 
> Names which do not meet these criteria but otherwise sound really cool
> should be added to a separate section of the wiki page and the TC may make
> an exception for one or more of them to be considered in the Condorcet poll.
> The naming official is responsible for presenting the list of exceptional
> names for consideration to the TC before the poll opens.
> 
> Exact Geographic Region
> 
> The Geographic Region from where names for the S release will come is Berlin
> 
> Proposed Names
> 
> Spree (a river that flows through the Saxony, Brandenburg and Berlin states of
>   Germany)
> 
> SBahn (The Berlin S-Bahn is a rapid transit system in and around Berlin)
> 
> Spandau (One of the twelve boroughs of Berlin)
> 
> Stein (Steinstraße or "Stein Street" in Berlin, can also be conveniently
>   abbreviated as )
> 
> Steglitz (a locality in the South Western part of the city)
> 
> Springer (Berlin is headquarters of Axel Springer publishing house)
> 
> Staaken (a locality within the Spandau borough)
> 
> Schoenholz (A zone in the Niederschönhausen district of Berlin)
> 
> Shellhaus (A famous office building)
> 
> Suedkreuz ("southern cross" - a railway station in Tempelhof-Schöneberg)
> 
> Schiller (A park in the Mitte borough)
> 
> Saatwinkel (The name of a super tiny beach, and its surrounding neighborhood)
>   (The adjective form, Saatwinkler is also a really cool bridge but
>   that form is too long)
> 
> Sonne (Sonnenallee is the name of a large street in Berlin crossing the former
>   wall, also translates as "sun")
> 
> Savigny (Common place in City-West)
> 
> Soorstreet (Street in Berlin restrict Charlottenburg)
> 
> Solar (Skybar in Berlin)
> 
> See (Seestraße or "See Street" in Berlin)
> 
> Thanks,
> Paul
> 
> __
> OpenStack Development Mailing 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] Bug deputy report - 26.02-5.03.2018

[Sławomir Kapłoński]

Hi,

I was on bug deputy during last week. Below short summary about reported bugs.

* For drivers team there are two RFE bugs:
[RFE] Support stateless security groups  - 
https://bugs.launchpad.net/neutron/+bug/1753466
[RFE] (Operator-only) Add support 'snat' for loggable resource type - 
https://bugs.launchpad.net/neutron/+bug/1752290

* One critical bug reported:
https://bugs.launchpad.net/neutron/+bug/1753507 - it is error in neutron-fwaas 
after upgrade from Pike to Queens

* Two bugs marked as High:
https://bugs.launchpad.net/neutron/+bug/1743425 - it is about crash 
neutron-server during service restart if vlan_range was changed,
* https://bugs.launchpad.net/neutron/+bug/1752006 - crash of neutron 
linuxbridge agent if fwaas_v2 is also enabled - I think that patch is ready for 
review for that one,

Other bugs are marked as medium or low:
* https://bugs.launchpad.net/neutron/+bug/1752274 - merge API references from 
wiki, and neutron-specs into neutron-lib,
* https://bugs.launchpad.net/neutron/+bug/1752903 - issue with allocation IPv6 
for FIP if there is IPv6 subnet in network - someone familiar with IPAM and L3 
should take a look on this one probably,
* https://bugs.launchpad.net/neutron/+bug/1753384 - issue with updating FIP 
QoS, patch is already proposed for this one,
* https://bugs.launchpad.net/neutron/+bug/1752275 - it's about write some 
document on API reference guideline,

There is also one bug reported for LBaaS v2: 
https://bugs.launchpad.net/neutron/+bug/1753380 and here is my question: should 
we redirect it to Octavia/LBaaS team's storyboard?

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl


__
OpenStack Development Mailing 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] [sdk] Nominating Adrian Turjak for core

[Sławomir Kapłoński]

+1

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl

> Wiadomość napisana przez Monty Taylor  w dniu 
> 26.02.2018, o godz. 11:31:
> 
> Hey everybody,
> 
> I'd like to nominate Adrian Turjak (adriant) for openstacksdk-core. He's an 
> Operator/End User and brings *excellent* deep/strange/edge-condition bugs. He 
> also has a great understanding of the mechanics between Resource/Proxy 
> objects and is super helpful in verifying fixes work in the real world.
> 
> It's worth noting that Adrian's overall review 'stats' aren't what it 
> traditionally associated with a 'core', but I think this is a good example 
> that life shouldn't be driven by stackalytics and the being a core reviewer 
> is about understanding the code base and being able to evaluate proposed 
> changes. From my POV, Adrian more than qualifies.
> 
> Thoughts?
> Monty
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [neutron][sdk] Proposal to migrate neutronclient python bindings to OpenStack SDK

[Sławomir Kapłoński]

I also agree that it is good idea and I would be very happy to help with such 
migration :)

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl

> Wiadomość napisana przez Monty Taylor  w dniu 
> 26.02.2018, o godz. 11:14:
> 
> On 02/26/2018 09:57 AM, Akihiro Motoki wrote:
>> Hi neutron and openstacksdk team,
>> This mail proposes to change the first priority of neutron-related
>> python binding to OpenStack SDK rather than neutronclient python
>> bindings.
>> I think it is time to start this as OpenStack SDK became a official
>> project in Queens.
> 
> ++
> 
>> [Current situations and problems]
>> Network OSC commands are categorized into two parts: OSC and
>> neutronclient OSC plugin.
>> Commands implemented in OSC consumes OpenStack SDK
>> and commands implemented as neutronclient OSC plugin consumes
>> neutronclient python bindings.
>> This brings tricky situation that some features are supported only in
>> OpenStack SDK and some features are supported only in neutronclient
>> python bindings.
>> [Proposal]
>> The proposal is to implement all neutron features in OpenStack SDK as
>> the first citizen,
>> and the neutronclient OSC plugin consumes corresponding OpenStack SDK APIs.
>> Once this is achieved, users of OpenStack SDK users can see all
>> network related features.
>> [Migration plan]
>> The migration starts from Rocky (if we agree).
>> New features should be supported in OpenStack SDK and
>> OSC/neutronclient OSC plugin as the first priority. If new feature
>> depends on neutronclient python bindings, it can be implemented in
>> neutornclient python bindings first and they are ported as part of
>> existing feature transition.
>> Existing features only supported in neutronclient python bindings are
>> ported into OpenStack SDK,
>> and neutronclient OSC plugin will consume them once they are
>> implemented in OpenStack SDK.
> 
> I think this is a great idea. We've got a bunch of good 
> functional/integrations tests in the sdk gate as well that we can start 
> running on neutron patches so that we don't lose cross-gating.
> 
>> [FAQ]
>> 1. Will neutornclient python bindings be removed in future?
>> Different from "neutron" CLI, as of now, there is no plan to drop the
>> neutronclient python bindings.
>> Not a small number of projects consumes it, so it will be maintained as-is.
>> The only change is that new features are implemented in OpenStack SDK first 
>> and
>> enhancements of neutronclient python bindings will be minimum.
>> 2. Should projects that consume neutronclient python bindings switch
>> to OpenStack SDK?
>> Necessarily not. It depends on individual projects.
>> Projects like nova that consumes small set of neutron features can
>> continue to use neutronclient python bindings.
>> Projects like horizon or heat that would like to support a wide range
>> of features might be better to switch to OpenStack SDK.
> 
> We've got a PTG session with Heat to discuss potential wider-use of SDK (and 
> have been meaning to reach our to horizon as well) Perhaps a good first step 
> would be to migrate the heat.engine.clients.os.neutron:NeutronClientPlugin 
> code in Heat from neutronclient to SDK. There's already an 
> heat.engine.clients.os.openstacksdk:OpenStackSDKPlugin plugin in Heat. I 
> started a patch to migrate senlin from senlinclient (which is just a thin 
> wrapper around sdk): https://review.openstack.org/#/c/532680/
> 
> For those of you who are at the PTG, I'll be giving an update on SDK after 
> lunch on Wednesday. I'd also be more than happy to come chat about this more 
> in the neutron room if that's useful to anybody.
> 
> Monty
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] [neutron] QoS IRC meeting

[Sławomir Kapłoński]

Hi,

I have to cancel todays Neutron QoS IRC meeting.
If You have something related to QoS that You want to talk about, please catch 
me on openstack-neutron irc channel.

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl


__
OpenStack Development Mailing 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] [sdk][ptl] PTL Candidacy for Rocky

[Sławomir Kapłoński]

Big +1 from me :)

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl



> Wiadomość napisana przez Monty Taylor  w dniu 
> 31.01.2018, o godz. 16:54:
> 
> Hi everybody!
> 
> I'd like to run for PTL of OpenStackSDK again
> 
> This last cycle was pretty exciting. We merged the shade and openstacksdk 
> projects into a single team. We shifted os-client-config to that team as 
> well. We merged the code from shade and os-client-config into openstacksdk, 
> and then renamed the team.
> 
> It wasn't just about merging projects though. We got some rework done to base 
> the Proxy classes on keystoneauth Adapters providing direct passthrough REST 
> availability for services. We finished the Resource2/Proxy2 transition. We 
> updated pagination to work for all of the OpenStack services - and in the 
> process uncovered a potential cross-project goal. And we tied services in 
> openstacksdk to services listed in the Service Types Authority.
> 
> Moving forward, there's tons to do.
> 
> First and foremost we need to finish integrating the shade code into the sdk 
> codebase. The sdk layer and the shade layer are currently friendly but 
> separate, and that doesn't make sense long term. To do this, we need to 
> figure out a plan for rationalizing the return types - shade returns 
> munch.Munch objects which are dicts that support object attribute access. The 
> sdk returns Resource objects.
> 
> There are also multiple places where the logic in the shade layer can and 
> should move into the sdk's Proxy layer. Good examples of this are swift 
> object uploads and downloads and glance image uploads.
> 
> I'd like to move masakari and tricircle's out-of-tree SDK classes in tree.
> 
> shade's caching and rate-limiting layer needs to be shifted to be able to 
> apply to both levels, and the special caching for servers, ports and
> floating-ips needs to be replaced with the general system. For us to do that 
> though, the general system needs to be improved to handle nodepool's batched 
> rate-limited use case as well.
> 
> We need to remove the guts of both shade and os-client-config in their repos 
> and turn them into backwards compatibility shims.
> 
> We need to work with the python-openstackclient team to finish getting the 
> current sdk usage updated to the non-Profile-based flow, and to make sure 
> we're providing what they need to start replacing uses of python-*client with 
> uses of sdk.
> 
> I know the folks with the shade team background are going to LOVE this one, 
> but we need to migrate existing sdk tests that mock sdk objects to 
> requests-mock. (We also missed a few shade tests that still mock out methods 
> on OpenStackCloud that need to get transitioned)
> 
> Finally - we need to get a 1.0 out this cycle. We're very close - the main 
> sticking point now is the shade/os-client-config layer, and specifically 
> cleaning up a few pieces of shade's API that weren't great but which we 
> couldn't change due to API contracts.
> 
> I'm sure there will be more things to do too. There always are.
> 
> In any case, I'd love to keep helping to pushing these rocks uphill.
> 
> Thanks!
> Monty
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

[openstack-dev] Issue with eventlet monkey patching

[Sławomir Kapłoński]

Hi,

Recently we found in Neutron errors with starting our agents which uses 
eventlet.monkey_patch() method. Bug is described in [1].

I heard on IRC that it's not related only to Neutron so here is what we found 
about that.
It looks that this issue happens on Ubuntu with python2.7 
2.7.12-1ubuntu0~16.04.3 with eventlet < 0.22.0 (in OpenStack requirements it is 
set to 0.20.0).
There is no this issue with python2.7.12-1ubuntu0~16.04.2 and eventlet 0.20.0

Something similar was already reported for monotonic in [2]. From one of 
comments there we found that problem can be caused because: 
"ctypes.util.find_library is now using subprocess.Popen, instead of os.popen 
(python/cpython@eb063011), and eventlet monkey-patches subprocess.Popen but not 
os.popen."

It looks that eventlet patch [3] fixes/workaround this issue.
I pushed similar patch to Neutron [4] and it looks that our issue is solved for 
now.

I hope that maybe this info will be helpful for You :)

[1] https://bugs.launchpad.net/neutron/+bug/1745013
[2] https://www.bountysource.com/issues/43892421-new-monotonic-broken-on-docker
[3] 
https://github.comhttps://review.openstack.org/#/c/537863/1/eventlet/eventlet/commit/b756447bab51046dfc6f1e0e299cc997ab343701
 
[4] https://review.openstack.org/#/c/537863

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl




__
OpenStack Development Mailing 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]The components timing problem

[Sławomir Kapłoński]

s' % msg_id)
> 2018-01-23 17:37:53.807 8636 ERROR 
> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
> MessagingTimeout: Timed out waiting for a reply to message ID 
> 5907b7ced96140c693a6fb6dd0698dbc
> 2018-01-23 17:37:53.807 8636 ERROR 
> neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent 
> 2018-01-23 17:37:53.808 8636 WARNING oslo.service.loopingcall [-] Function 
> 'neutron.plugins.ml2.drivers.openvswitch.agent.ovs_neutron_agent.OVSNeutronAgent._report_state'
>  run outlasted interval by 30.00 sec
> 2018-01-23 17:37:59.227 8636 INFO oslo.messaging._drivers.impl_rabbit [-] 
> [3e7c487b-9222-4eee-b879-a7981649d49c] Reconnected to AMQP server on 
> 127.0.0.1:5672 via [amqp] client with port 51476.
> 2018-01-23 17:37:59.270 8636 INFO oslo.messaging._drivers.impl_rabbit [-] 
> [a6262917-f316-43df-83fd-05af30a2b302] Reconnected to AMQP server on 
> 127.0.0.1:5672 via [amqp] client with port 51478.
> 2018-01-23 17:37:59.308 8636 INFO oslo.messaging._drivers.impl_rabbit [-] 
> [99ff11c3-1662-461
> 
> Thanks,
> Frank
> At 2018-01-23 17:27:52, "Sławomir Kapłoński" <sla...@kaplonski.pl> wrote:
> >Hi,
> >
> >If both ovs agent and neutron-server reconnect to rabbitmq then it should 
> >report state properly again IMO.
> >Can You maybe send more details about Your issue? What OpenStack version You 
> >are running, exact stack trace of exception which You get and so on.
> >
> >— 
> >Best regards
> >Slawek Kaplonski
> >sla...@kaplonski.pl
> >
> >
> >
> >> Wiadomość napisana przez Frank Wang <wangpeihui...@126.com> w dniu 
> >> 23.01.2018, o godz. 10:08:
> >> 
> >> Hi All,
> >> 
> >> I'm really newbie about OpenStack Neutron, Please correct me if I say 
> >> something wrong. There was a question I'd like to consult.  AMQP is the 
> >> messaging bus between neutron-server and *agents. we usually use rabbitmq 
> >> as the back-end of messaging bus.  The problem I encountered is the ovs 
> >> agent raise an exception while reporting its own state to the server.  
> >> Here is my guess, If I restart the controller node, what if the rabbitmq 
> >> start early than neutron-server. I mean the ovs agent always trying to 
> >> connect to the rabbitmq. It will report state to the server through RPC 
> >> once the connection established. if the server is not ready at this time. 
> >> Does it cause the agent exception?  Any suggestion would be greatly 
> >> appreciated!
> >> 
> >> 
> >> Thanks,
> >> Frank
> >> 
> >> 
> >>  
> >> __
> >> OpenStack Development Mailing List (not for usage questions)
> >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >__
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> 
>  
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Neutron]The components timing problem

[Sławomir Kapłoński]

Hi,

If both ovs agent and neutron-server reconnect to rabbitmq then it should 
report state properly again IMO.
Can You maybe send more details about Your issue? What OpenStack version You 
are running, exact stack trace of exception which You get and so on.

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl



> Wiadomość napisana przez Frank Wang  w dniu 
> 23.01.2018, o godz. 10:08:
> 
> Hi All,
> 
> I'm really newbie about OpenStack Neutron, Please correct me if I say 
> something wrong. There was a question I'd like to consult.  AMQP is the 
> messaging bus between neutron-server and *agents. we usually use rabbitmq as 
> the back-end of messaging bus.  The problem I encountered is the ovs agent 
> raise an exception while reporting its own state to the server.  Here is my 
> guess, If I restart the controller node, what if the rabbitmq start early 
> than neutron-server. I mean the ovs agent always trying to connect to the 
> rabbitmq. It will report state to the server through RPC once the connection 
> established. if the server is not ready at this time. Does it cause the agent 
> exception?  Any suggestion would be greatly appreciated!
> 
> 
> Thanks,
> Frank
> 
> 
>  
> __
> OpenStack Development Mailing 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] Bug deputy report

[Sławomir Kapłoński]

Hello,

I was on bug deputy between 11.12.2017 and 18.12.2017. Below short summary 
about bugs reported in this time.

https://bugs.launchpad.net/neutron/+bug/1737917 - not prioritized, for me it 
looks like some issue with l2pop so if someone is familiar with l2pop, please 
check it. I asked Miguel to look at it also.

https://bugs.launchpad.net/neutron/+bug/1738337 - looks like issue with DB 
(maybe some race condition), I saw that Lujin Luo is on it together with 
reported of this bug.

https://bugs.launchpad.net/neutron/+bug/1738371 - issue with port range 
validation in neutron-lib, patch is already proposed: 
https://review.openstack.org/#/c/528205/ so please review it (especially 
drivers team :))

https://bugs.launchpad.net/neutron/+bug/1738420 - some issue with DHCP and IPs 
assigned, I marked it as incomplete for now, and Brian was also checking that

https://bugs.launchpad.net/neutron/+bug/1738466 - this issue is for 
neutron-lbaas and affects Ocata only and patch is in review already: 
https://review.openstack.org/#/c/528364/

https://bugs.launchpad.net/neutron/+bug/1738475 - I marked it as low for now 
because I didn't saw that it happen more than two times reported in bug 
description. If it will happen more often, we will have to increase priority 
for it probably,

https://bugs.launchpad.net/neutron/+bug/1738612 - fix already released - thx 
Gary :)

https://bugs.launchpad.net/neutron/+bug/1738659 - I don't know how to 
prioritize this one, help from someone who knows Linuxbridge better would be 
very helpful :)

https://bugs.launchpad.net/neutron/+bug/1738738 - it should be RFE probably so 
I marked it with such tag

https://bugs.launchpad.net/neutron/+bug/1738768 - it's related to containers 
and AFAIK Brian is on it together with Daniel Alvarez


— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl




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

Re: [openstack-dev] [neutron] Stepping down from core

[Sławomir Kapłoński]

Hi Armando,

It's very sad to hear that.
Thanks for all Your work for Neutron community as well as for all Your help for 
other contributors.
Good luck!

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl



> Wiadomość napisana przez Armando M.  w dniu 15.12.2017, o 
> godz. 20:01:
> 
> Hi neutrinos,
> 
> To some of you this email may not come as a surprise.
> 
> During the past few months my upstream community engagements have been more 
> and more sporadic. While I tried hard to stay committed and fulfill my core 
> responsibilities I feel like I failed to retain the level of quality and 
> consistency that I would have liked ever since I stepped down from being the 
> Neutron PTL back at the end of Ocata.
> 
> I stated many times when talking to other core developers that being core is 
> a duty rather than a privilege, and I personally feel like it's way overdue 
> for me to recognize on the mailing list that it's the time that I state 
> officially my intention to step down due to other commitments.
> 
> This does not mean that I will disappear tomorrow. I'll continue to be on 
> neutron IRC channels, support the neutron team, being the release liasion for 
> Queens, participate at meetings, and be open to providing feedback to anyone 
> who thinks my opinion is still valuable, especially when dealing with the 
> neutron quirks for which I might be (git) blamed :)
> 
> Cheers,
> Armando
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Neutron] Propose Slawek Kaplonski for Neutron core

[Sławomir Kapłoński]

Hi,

Thanks all of You for support. I'm very happy to be part of the team.

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl


> Wiadomość napisana przez Miguel Lavalle  w dniu 
> 06.12.2017, o godz. 16:58:
> 
> Hi Neutron Team,
> 
> It has been a week since Slawek's nomination to Neutron core went out. We 
> have received great positive feedback from the team and community members at 
> large. As a consequence, I want to welcome Slawek to the core team and 
> congratulate him on his hard work and many contributions to OpenStack 
> Networking. Keep it up!
> 
> Cheers
> 
> Miguel
> 
> On Mon, Dec 4, 2017 at 7:06 AM, Anna Taraday  
> wrote:
> +1 !
> Well deserved! 
> 
> On Sun, Dec 3, 2017 at 1:03 PM Gary Kotton  wrote:
> +1
> 
>  
> 
> Welcome to the team!
> 
>  
> 
> From: Miguel Lavalle 
> Reply-To: OpenStack List 
> Date: Wednesday, November 29, 2017 at 9:21 PM
> To: OpenStack List 
> Subject: [openstack-dev] [Neutron] Propose Slawek Kaplonski for Neutron core
> 
>  
> 
> Hi Neutron Team,
> 
>  
> 
> I want to nominate Slawek Kaplonski (irc: slaweq) to Neutron core. Slawek has 
> been an active contributor to the project since the Mitaka cycle. He has been 
> instrumental in the development of the QoS capabilities in Neutron, becoming 
> the lead of the sub-team focused on that set of features. More recently, he 
> has collaborated in the implementation of OVO and is an active participant in 
> the CI sub-team. His number of code reviews during the Queens cycle is on par 
> with the leading core members of the team: 
> http://stackalytics.com/?module=neutron
> 
>  
> 
> In my opinion, his efforts are highly valuable to the team and we will be 
> very lucky to have him as a fully voting core.
> 
>  
> 
> I will keep this nomination open for a week as customary,
> 
>  
> 
> Thank you,
> 
>  
> 
> Miguel
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> -- 
> Regards,
> Ann Taraday
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] stable/newton branch for Neutron and Glance

[Sławomir Kapłoński]

Hi,

For Neutron there is tag "newton-eol" in repository: 
https://github.com/openstack/neutron/tree/newton-eol
You can clone latest Newton from this tag.
For Glace it's probably the same.

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl



> Wiadomość napisana przez Anda Nicolae  w dniu 
> 22.11.2017, o godz. 09:36:
> 
> Hi all,
>  
> I intend to install OpenStack Newton using stable/newton branch from devstack 
> (https://github.com/openstack-dev/devstack.git)
>  
> Unfortunately, I’ve noticed that some OpenStack repos such as Neutron 
> (https://github.com/openstack/neutron) or Glance 
> (https://github.com/openstack/glance) do not have stable/newton branch. 
> Because of this, stack.sh script from devstack fails when trying to clone 
> Neutron or Glance repos using stable/newton branch, because this branch does 
> not exist in GitHub for the respective projects.
>  
> Can you please let me know from where can I clone stable/newton branch for 
> Neutron and Glance projects? Or are there other repos for Neutron and Glance 
> which contain stable/newton branch?
>  
> Thanks,
> Anda
>  
> __
> OpenStack Development Mailing 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] No QoS meeting tomorrow

[Sławomir Kapłoński]

Hi,

Tomorrow I will be on OpenStack Day in France so I will not be able to chair 
QoS meeting. Sorry.
Next meeting should be normally at 5.12.2017.

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl




__
OpenStack Development Mailing 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] No QoS meeting today

[Sławomir Kapłoński]

Hello,

There will be no QoS meeting today. Next one will be on 7.11.2017.
Sorry.

— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl




__
OpenStack Development Mailing 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] MTU native ovs firewall driver

[Sławomir Kapłoński]

Isn't OVS setting MTU automatically MTU for bridge as lowest value from ports 
connected to this bridge?


> Wiadomość napisana przez Miguel Angel Ajo Pelayo  w dniu 
> 22.09.2017, o godz. 10:32:
> 
> I believe that one of the problems is that if you set a certain MTU in an OVS 
> switch, new connected ports will be automatically assigned to such MTU the 
> ovs-vswitchd daemon.
> 
> 
> 
> On Wed, Sep 20, 2017 at 10:45 PM, Ian Wells  wrote:
> Since OVS is doing L2 forwarding, you should be fine setting the MTU to as 
> high as you choose, which would probably be the segment_mtu in the config, 
> since that's what it defines - the largest MTU that (from the Neutron API 
> perspective) is usable and (from the OVS perspective) will be used in the 
> system.  A 1500MTU Neutron network will work fine over a 9000MTU OVS switch.
> 
> What won't work is sending a 1500MTU network to a 9000MTU router port.  So if 
> you're doing any L3 (where the packet arrives at an interface, rather than 
> travels a segment) you need to consider those MTUs in light of the Neutron 
> network they're attached to.
> -- 
> Ian.
> 
> On 20 September 2017 at 09:58, Ihar Hrachyshka  wrote:
> On Wed, Sep 20, 2017 at 9:33 AM, Ajay Kalambur (akalambu)
>  wrote:
> > So I was forced to explicitly set the MTU on br-int
> > ovs-vsctl set int br-int mtu_request=9000
> >
> >
> > Without this the tap device added to br-int would get MTU 1500
> >
> > Would this be something the ovs l2 agent can handle since it creates the 
> > bridge?
> 
> Yes, I guess we could do that if it fixes your problem. The issue
> stems from the fact that we use a single bridge for different networks
> with different MTUs, and it does break some assumptions kernel folks
> make about a switch (that all attached ports steer traffic in the same
> l2 domain, which is not the case because of flows we set). You may
> want to report a bug against Neutron and we can then see how to handle
> that. I will probably not be as simple as setting the value to 9000
> because different networks have different MTUs, and plugging those
> mixed ports in the same bridge may trigger MTU updates on unrelated
> tap devices. We will need to test how kernel behaves then.
> 
> Also, you may be interested in reviewing an old openvswitch-dev@
> thread that I once started here:
> https://mail.openvswitch.org/pipermail/ovs-dev/2016-June/316733.html
> Sadly, I never followed up with a test scenario that wouldn't involve
> OpenStack, for OVS folks to follow up on, so it never moved anywhere.
> 
> Cheers,
> Ihar
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



— 
Best regards
Slawek Kaplonski
sla...@kaplonski.pl




__
OpenStack Development Mailing 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] possible race condition with nova instance and neutron ports

[Sławomir Kapłoński]

With such settings nova is not waiting for info from neutron and that is why 
Your instances starting without network ready.
If You will change this timeout to some value higher than 0 then instance will 
be paused and nova will wait for info from neutron that port is active (You 
should also check credentials config in neutron server)
If You will set also vif_plugging_is_fatal=True then nova will put instance in 
ERROR state if port will not be active after timeout time.

-- 
Slawek

> Wiadomość napisana przez Saverio Proto <saverio.pr...@switch.ch> w dniu 
> 09.08.2017, o godz. 14:24:
> 
> Hello,
> 
> thanks for the tip.
> I checked on a compute node, in the nova.conf file I have the following:
> 
> vif_plugging_is_fatal=False
> vif_plugging_timeout=0
> 
> both options are in the [DEFAULT] section.
> I guess these settings were never changed since we were running Icehouse.
> 
> Should I change to the Ocata default values ? (True and 300)
> 
> I will try that today.
> Thank you
> 
> Saverio
> 
> 
> On 09/08/17 09:23, Sławomir Kapłoński wrote:
>> Hello,
>> 
>> Do You have configured in nova-compute: vif_plugging_timeout and 
>> vif_plugging_is_fatal options?
>> With those options nova should pause VM until port will be set to ACTIVE in 
>> Neutron.
>> 
> 
> 
> -- 
> SWITCH
> Saverio Proto, Peta Solutions
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 15, direct +41 44 268 1573
> saverio.pr...@switch.ch, http://www.switch.ch
> 
> http://www.switch.ch/stories
> 
> __
> OpenStack Development Mailing 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] possible race condition with nova instance and neutron ports

[Sławomir Kapłoński]

Hello,

Do You have configured in nova-compute: vif_plugging_timeout and 
vif_plugging_is_fatal options?
With those options nova should pause VM until port will be set to ACTIVE in 
Neutron.

-- 
Slawek

> Wiadomość napisana przez Saverio Proto  w dniu 
> 09.08.2017, o godz. 09:06:
> 
> Hello,
> 
> I see this in Openstack Newton
> 
> I start 200 instances with a oneliner.
> 
> openstack server create \
> --image "Ubuntu Xenial 16.04 (SWITCHengines)" \
> --flavor c1.small \
> --network demonetwork \
> --user-data cloud-init.txt \
> --key-name macsp \
> --min 200 \
> --max 200 test
> 
> When I do this I see a problem where all the instances boot and are in
> Running state, before all neutron ports are ACTIVE.
> 
> I see with `openstack port list` neutron ports still in BUILD state. It
> takes a longer time to make them all ACTIVE, the instances that use
> those ports boot up much faster.
> 
> In rabbitmq queues I see growing the dhcp_agent. queues.
> 
> At the very end all neutron ports will be ACTIVE and rabbitmq queues
> back to normal. But many VMs failed getting an address via DHCP because
> at the time they were trying the dnsmasq process did not have a
> corresponding entry for the instance in the `host` file. Unfortunately
> the instance gives up trying obtaining an address via DHCP after 5 minutes.
> 
> When I start 200 instances I always end up with 15 to 30 instances
> without IP address. I check carefully using cloud-init: I make them
> phone-home to check if they are alive.
> 
> Should I open a bug for this ?? It looks like a race condition where
> nova boots the instance before the neutron port is really ready.
> 
> thank you for your feedback.
> 
> Saverio
> 
> 
> 
> 
> 
> -- 
> SWITCH
> Saverio Proto, Peta Solutions
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone +41 44 268 15 15, direct +41 44 268 1573
> saverio.pr...@switch.ch, http://www.switch.ch
> 
> http://www.switch.ch/stories
> 
> __
> OpenStack Development Mailing 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][QoS] No QoS meeting this week

[Sławomir Kapłoński]

Hello,

As many of people are probably on summit we will cancel this week QoS meeting.
Next meeting will be at 23.05.2017.

Pozdrawiam / Best regards
Sławek Kapłoński
sla...@kaplonski.pl


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