Re: [openstack-dev] [Sender Auth Failure] [infra][release][all] Automatic .ics generation for OpenStack's and project's deadlines

[Johnston, Nate]

I think this is a great idea.  +1

—N.

> On Dec 10, 2015, at 1:20 PM, Flavio Percoco  wrote:
> 
> Greetings,
> 
> I'd like to explore the possibility of having .ics generated - pretty
> much the same way we generate it for irc-meetings - for the OpenStack
> release schedule and project's deadlines. I believe just 1 calendar
> would be enough but I'd be ok w/  a per-project .ics too. 
> With the new home for the release schedule, and it being a good place
> for projects to add their own deadlines as well, I believe it would be
> good for people that use calendars to have these .ics being generated
> and linked there as well.
> 
> Has this been attempted? Any objections? Is there something I'm not
> considering?
> 
> Cheers,
> Flavio
> 
> -- 
> @flaper87
> Flavio Percoco
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

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

Re: [openstack-dev] [Sender Auth Failure] Re: [neutron] How could an L2 agent extension access agent methods ?

[Johnston, Nate]

Ihar,

This is brilliant.  The complexity of doing graceful CRUD on the OVS flow table 
especially when other features are active is so complex, that abstracting the 
management of it into functionality optimized for that task is an incredibly 
good idea, especially for those of us like me who are not experts in OVS, and 
thus have a hard time seeing the edge cases.

Thanks very much for this.

—N.

> On Dec 3, 2015, at 10:46 AM, Ihar Hrachyshka  wrote:
> 
> Hi,
> 
> Small update on the RFE. It was approved for Mitaka, assuming we come up with 
> proper details upfront thru neutron-specs process.
> 
> In the meantime, we have found more use cases for flow management among 
> features in development: QoS DSCP, also the new OF based firewall driver. 
> Both authors for those new features independently realized that agent does 
> not currently play nice with flows set by external code due to its graceful 
> restart behaviour when rules with unknown cookies are cleaned up. [The agent 
> uses a random session uuid() to mark rules that belong to its current run.]
> 
> Before I proceed, full disclosure: I know almost nothing about OpenFlow 
> capabilities, so some pieces below may make no sense. I tried to come up with 
> high level model first and then try to map it to available OF features. 
> Please don’t hesitate to comment, I like to learn new stuff! ;)
> 
> I am thinking lately on the use cases we collected so far. One common need 
> for all features that were seen to be interested in proper integration with 
> Open vSwitch agent is to be able to manage feature specific flows on br-int 
> and br-tun. There are other things that projects may need, like patch ports, 
> though I am still struggling with the question of whether it may be postponed 
> or avoided for phase 1.
> 
> There are several specific operation 'kinds' that we should cover for the RFE:
> - managing flows that modify frames in-place;
> - managing flows that redirect frames.
> 
> There are some things that should be considered to make features cooperate 
> with the agent and other extensions:
> - feature flows should have proper priorities based on their ‘kind’ (f.e. 
> in-place modification probably go before redirections);
> - feature flows should survive flow reset that may be triggered by the agent;
> - feature flows should survive flow reset without data plane disruption 
> (=they should support graceful restart: 
> https://review.openstack.org/#/c/182920).
> 
> With that in mind, I see the following high level design for the flow tables:
> 
> - table 0 serves as a dispatcher for specific features;
> - each feature gets one or more tables, one per flow ‘kind’ needed;
> - for each feature table, a new flow entry is added to table 0 that would 
> redirect to feature specific table; the rule will be triggered only if OF 
> metadata is not updated inside the feature table (see the next bullet); the 
> rule will have priority that is defined for the ‘kind’ of the operation that 
> is implemented by the table it redirects to;
> -  each feature table will have default actions that will 1) mark OF metadata 
> for the frame as processed by the feature; 2) redirect back to table 0;
> - all feature specific flow rules (except dispatcher rules) belong to feature 
> tables;
> 
> Now, the workflow for extensions that are interested in setting flows would 
> be:
> - on initialize() call, extension defines feature tables it will need; it 
> passes the name of the feature table and the ‘kind’ of the actions it will 
> execute; with that, the following is initialized by the agent: 1) table 0 
> dispatcher entry to redirect frames into feature table; the entry has the 
> priority according to the ‘kind’ of the table; 2) the actual feature table 
> with two default rules (update metadata and push back to table 0);
> - whenever extension needs to add a new flow rule, it passes the following 
> into the agent: 1) table name; 2) flow specific parameters (actions, 
> priority, ...)
> 
> Since the agent will manage setting flows for extensions, it will be able to 
> use the active agent cookie for all feature flows; next time the agent is 
> restarted, it should be able to respin extension flows with no data plane 
> disruption. [Note: we should make sure that on agent restart, we call to 
> extensions *before* we clean up stale flow rules.]
> 
> That design will hopefully allow us to abstract interaction with flows from 
> extensions into management code inside the agent. It should guarantee 
> extensions cooperate properly assuming they properly define their priorities 
> thru ‘kinds’ of tables they have.
> 
> It is also assumed that existing flow based features integrated into the 
> agent (dvr? anti-spoofing?) will eventually move to the new flow table 
> management model.
> 
> I understand that the model does not reflect how do feature processing for 
> existing OF based features in the agent. It may require some smart 
> workarounds 

Re: [openstack-dev] [Neutron] Bug deputy process

[Johnston, Nate]

I second that - I don’t have the ability to triage a bug.  But I would be happy 
to take a watch if I could.

—N.

> On Dec 3, 2015, at 1:42 PM, Smigiel, Dariusz  
> wrote:
> 
>> From: Kyle Mestery [mailto:mest...@mestery.com] 
> [...]
>> One concern I have is ensuring we rotate people, because it does take some 
>> time, and if the same handful of rotate, they will burn out. So I actively 
>> encourage more people to volunteer, you don't even have to be a Neutron core 
>> reviewer to do this!
> 
> Kyle, didn't know that not only core reviewers can do deputy. I thought that 
> only selected group of users have an access to bug triaging.
> Another thing, probably the best users who know how bug is complicated or 
> important, are cores.
> 
> If you have any tips or tricks to do proper deputy, I'm in.
> 
>> Thanks!
>> Kyle
> 
> Thanks, Darek Smigiel (dasm)
> ITP
> __
> OpenStack Development Mailing List (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] Question about Microsoft Hyper-V CI tests

[Johnston, Nate]

I noticed the same failure in the neutron-dsvm-tempest test for the Neutron DVR 
HA change, https://review.openstack.org/#/c/143169

I have not yet been able to determine the cause.

Thanks,

—N.

On Nov 3, 2015, at 3:57 PM, sla...@kaplonski.pl 
wrote:

Hello,

I'm now working on patch to neutron to add QoS in linuxbridge: https://
review.openstack.org/#/c/236210/
Patch is not finished yet but I have some "problem" with some tests. For
example Microsoft Hyper-V CI check are failing. When I checked logs of this
tests in http://64.119.130.115/neutron/236210/7/results.html.gz file I found
error like:

ft1.1: setUpClass
(tempest.api.network.test_networks.NetworksIpV6TestAttrs)_StringException:
Traceback (most recent call last):
 File "tempest/test.py", line 274, in setUpClass
   six.reraise(etype, value, trace)
 File "tempest/test.py", line 267, in setUpClass
   cls.resource_setup()
 File "tempest/api/network/test_networks.py", line 65, in resource_setup
   cls.network = cls.create_network()
 File "tempest/api/network/base.py", line 152, in create_network
   body = cls.networks_client.create_network(name=network_name)
 File "tempest/services/network/json/networks_client.py", line 21, in
create_network
   return self.create_resource(uri, post_data)
 File "tempest/services/network/json/base.py", line 59, in create_resource
   resp, body = self.post(req_uri, req_post_data)
 File "/usr/local/lib/python2.7/dist-packages/tempest_lib/common/
rest_client.py", line 259, in post
   return self.request('POST', url, extra_headers, headers, body)
 File "/usr/local/lib/python2.7/dist-packages/tempest_lib/common/
rest_client.py", line 639, in request
   resp, resp_body)
 File "/usr/local/lib/python2.7/dist-packages/tempest_lib/common/
rest_client.py", line 757, in _error_checker
   resp=resp)
tempest_lib.exceptions.UnexpectedResponseCode: Unexpected response code
received
Details: 503


It is strange for me because it looks that error is somewhere in
create_network. I didn't change anything in code which is creating networks.
Other tests are fine IMHO.
So my question is: should I check reason of this errors and try to fix it also
in my patch? Or how should I proceed with such kind of errors?

--
Pozdrawiam / Best regards
Sławek Kapłoński
slawek@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 Development Mailing 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] [Sender Auth Failure] Re: [neutron] Neutron rolling upgrade - are we there yet?

[Johnston, Nate]

On Oct 15, 2015, at 11:23 AM, Ihar Hrachyshka 
> wrote:

I also feel that upgrades are in lots of ways not only a technical issue, but a 
cultural one too. You should have reviewers being aware of all the moving 
parts, and how a seemingly innocent change can break the flow. That’s why I 
plan to start on a devref page specifically about upgrades, where we could lay 
ground about which scenarios we should support, and those we should not (f.e. 
we have plenty of compatibility code in agents that to handle old controller 
scenario, which should not be supported); how all pieces interact and behave in 
transition, and what to look for during reviews. Hopefully, once such a page is 
up and read by folks, we will be able to have more meaningful conversation 
about our upgrade strategy.

That is a fantastic idea, and would really help me understand this part of the 
Neutron code as a reviewer.  Thanks!

—N.
__
OpenStack Development Mailing 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-docs][Neutron] Networking Guide - Call for contributors

[Johnston, Nate]

No, I am in Reston, VA.

—N.

On Oct 8, 2015, at 11:06 AM, Edgar Magana 
<edgar.mag...@workday.com<mailto:edgar.mag...@workday.com>> wrote:

Awesome Nate!  Are you located in Philadelphia?

Edgar

From: "Johnston, Nate"
Reply-To: "OpenStack Development Mailing List (not for usage questions)"
Date: Wednesday, October 7, 2015 at 8:50 PM
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [OpenStack-docs][Neutron] Networking Guide - Call 
for contributors

I can definitely help.

—N.

On Oct 7, 2015, at 8:11 PM, Edgar Magana 
<edgar.mag...@workday.com<mailto:edgar.mag...@workday.com>> wrote:

Hello,

I would like to invite everybody to become an active contributor for the 
OpenStack Networking Guide: http://docs.openstack.org/networking-guide/

During the Liberty cycle we made a lot of progress and we feel that the guide 
is ready to have even more contributions and formalize a bit more the team 
around it.
The first thing that I want to propose is to have a regular meeting over IRC to 
discuss the progress and to welcome new contributors. This is the same process 
that other guides like the operators one are following currently.

The networking guide is based on this ToC: 
https://wiki.openstack.org/wiki/NetworkingGuide/TOC
Contribution process is the same that the rest of the OpenStack docs under the 
openstack-manuals git repo: 
https://github.com/openstack/openstack-manuals/tree/master/doc/networking-guide/source

Please, response to this thread and let me know if you could allocate some time 
to help us to make this guide a rock star as the other ones. Based on the 
responses, I will propose a couple of times for the IRC meeting that could 
allocate to everybody if possible, this is why is very important to let me know 
your time zone.

I am really looking forward to increase the contributors in this guide.

Thanks in advance!

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

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

Re: [openstack-dev] [OpenStack-docs][Neutron] Networking Guide - Call for contributors

[Johnston, Nate]

I can definitely help.

—N.

On Oct 7, 2015, at 8:11 PM, Edgar Magana 
> wrote:

Hello,

I would like to invite everybody to become an active contributor for the 
OpenStack Networking Guide: http://docs.openstack.org/networking-guide/

During the Liberty cycle we made a lot of progress and we feel that the guide 
is ready to have even more contributions and formalize a bit more the team 
around it.
The first thing that I want to propose is to have a regular meeting over IRC to 
discuss the progress and to welcome new contributors. This is the same process 
that other guides like the operators one are following currently.

The networking guide is based on this ToC: 
https://wiki.openstack.org/wiki/NetworkingGuide/TOC
Contribution process is the same that the rest of the OpenStack docs under the 
openstack-manuals git repo: 
https://github.com/openstack/openstack-manuals/tree/master/doc/networking-guide/source

Please, response to this thread and let me know if you could allocate some time 
to help us to make this guide a rock star as the other ones. Based on the 
responses, I will propose a couple of times for the IRC meeting that could 
allocate to everybody if possible, this is why is very important to let me know 
your time zone.

I am really looking forward to increase the contributors in this guide.

Thanks in advance!

Edgar Magana
__
OpenStack Development Mailing List (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] [Sender Auth Failure] Re: [neutron] New cycle started. What are you up to, folks?

[Johnston, Nate]

I was wondering if you provide a little bit more background on the QoS item, 
"-- remove RPC upgrade tech debt that we left in L (that should open path for 
new QoS rules that are currently blocked by it);”.  Is this related to the 
issue you point out in the commit message for the 
https://review.openstack.org/#/c/211520 change?  Does this block work on 
implementing QoS DSCP in Mitaka, and if so are there bugs that we can pitch in 
to in order to get past it?

Thanks,

—N.

> On Oct 1, 2015, at 10:02 AM, Ihar Hrachyshka  wrote:
> 
>> On 01 Oct 2015, at 15:45, Ihar Hrachyshka  wrote:
>> 
>> Hi all,
>> 
>> I talked recently with several contributors about what each of us plans for 
>> the next cycle, and found it’s quite useful to share thoughts with others, 
>> because you have immediate yay/nay feedback, and maybe find companions for 
>> next adventures, and what not. So I’ve decided to ask everyone what you see 
>> the team and you personally doing the next cycle, for fun or profit.
>> 
>> That’s like a PTL nomination letter, but open to everyone! :) No 
>> commitments, no deadlines, just list random ideas you have in mind or in 
>> your todo lists, and we’ll all appreciate the huge pile of awesomeness no 
>> one will ever have time to implement even if scheduled for Xixao release.
>> 
>> To start the fun, I will share my silly ideas in the next email.
> 
> Here is my silly list of stuff to do.
> 
> - start adopting NeutronDbObject for core resources (ports, networks) [till 
> now, it’s used in QoS only];
> 
> - introduce a so called ‘core resource extender manager’ that would be able 
> to replace ml2 extension mechanism and become a plugin agnostic way of 
> extending core resources by additional plugins (think of port security or qos 
> available for ml2 only - that sucks!);
> 
> - more changes with less infra tinkering! neutron devs should not need to go 
> to infra projects so often to make an impact;
> -- make our little neat devstack plugin used for qos and sr-iov only a huge 
> pile of bash code that is currently stored in devstack and is proudly called 
> neutron-legacy now; and make the latter obsolete and eventually removed from 
> devstack;
> -- make tempest jobs use a gate hook as we already do for api jobs;
> 
> - qos:
> -- once we have gate hook triggered, finally introduce qos into tempest runs 
> to allow first qos scenarios merged;
> -- remove RPC upgrade tech debt that we left in L (that should open path for 
> new QoS rules that are currently blocked by it);
> -- look into races in rpc.callbacks notification pattern (Kevin mentioned he 
> had ideas in mind around that);
> 
> - oslo:
> -- kill the incubator: we have a single module consumed from there (cache); 
> Mitaka is the time for the witch to die in pain;
> -- adopt oslo.reports: that is something I failed to do in Liberty so that I 
> would have a great chance to do the same in Mitaka; basically, allow neutron 
> services to dump ‘useful info’ on SIGUSR2 sent; hopefully will make debugging 
> a bit easier;
> 
> - upgrades:
> -- we should return to partial job for neutron; it’s not ok our upgrade 
> strategy works by pure luck;
> -- overall, I feel that it’s needed to provide more details about how 
> upgrades are expected to work in OpenStack (the order of service upgrades; 
> constraints; managing RPC versions and deprecations; etc.) Probably devref 
> should be a good start. I talked to some nova folks involved in upgrades 
> there, and we may join the armies on that since general upgrade strategy 
> should be similar throughout the meta-project.
> 
> - stable:
> -- with a stadium of the size we have, it becomes a burden for 
> neutron-stable-maint to track backports for all projects; we should think of 
> opening doors for more per-sub-project stable cores for those subprojects 
> that seem sane in terms of development practices and stable awareness side; 
> that way we offload neutron-stable-maint folks for stuff with greater impact 
> (aka stuff they actually know).
> 
> And what are you folks thinking of?
> 
> Ihar
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

Re: [openstack-dev] New PyCharm License

[Johnston, Nate]

Yes please - my launchpad ID is ‘nate-johnston’.

Thanks!

—N.

On Sep 21, 2015, at 10:54 AM, Andrew Melton 
> wrote:


Hi devs,


I've got the new license for the next year. As always, please reply to this 
email with your launchpad-id if you would like a license.


Also, if there are other JetBrains products you use to contribute to OpenStack, 
please let me know and I will request licenses.

​

--Andrew

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