21:01:02 <slaweq> #startmeeting networking
21:01:03 <openstack> Meeting started Mon Nov 26 21:01:02 2018 UTC and is due to finish in 60 minutes.  The chair is slaweq. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:04 <slaweq> hi
21:01:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:07 <openstack> The meeting name has been set to 'networking'
21:01:15 <haleyb> hi
21:01:31 <slaweq> mlavalle is traveling today and he asked me to run our meeting
21:01:33 <amotoki> hi morning
21:01:43 <bcafarel> hi mlavalle's clone (and others)
21:01:49 <slaweq> LOL
21:01:52 <hongbin> o/
21:02:01 <munimeha1> hi
21:02:21 <boden> howdy
21:02:32 <manjeets> hi
21:02:46 <slaweq> agenda for meeting is on https://wiki.openstack.org/wiki/Network/Meetings
21:02:52 <slaweq> #Topic Announcements
21:03:20 <slaweq> Next milestone is Stein-2, January 7 - 11
21:04:15 <slaweq> Other thing which is worth to highlight is fact that mailing lists are being combined:
21:04:22 <slaweq> http://lists.openstack.org/pipermail/openstack-dev/2018-November/136424.html
21:04:36 <slaweq> so we should use openstack-discuss ML now
21:05:17 <bcafarel> and add "[dev]" if needed in topic
21:05:36 <slaweq> and [neutron] tag also can be added, right?
21:06:03 <amotoki> from what I gathered so far,if a topic is completely specific to dev, [dev] would be fine.
21:06:10 <amotoki> [neutron] is fine too
21:06:26 <bcafarel> [dev] [neutron] probably then
21:06:32 <amotoki> so if a topic is also related to ops/users, just [neutron] would be fine
21:06:52 <slaweq> ok
21:06:54 <slaweq> thx
21:07:21 <bcafarel> http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000094.html
21:08:32 <slaweq> thx bcafarel for the link
21:08:51 <slaweq> so, please be aware and use new ML instead of old ones now :)
21:08:59 <amotoki> followup thread would be helpful like http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000100.html
21:09:06 <slaweq> old MLs will be closed in few weeks IIRC
21:10:06 <slaweq> ok, any other announcements for today?
21:11:01 <slaweq> ok, I guess that means "no" :)
21:11:06 <slaweq> so next topic
21:11:08 <slaweq> #topic Blueprints
21:11:21 <slaweq> current BP for Stein-2: https://launchpad.net/neutron/+milestone/stein-2
21:11:47 <slaweq> any updates on blueprints?
21:14:42 <slaweq> ok, I guess there is no any updates on blueprints
21:14:54 <slaweq> so let's move on to the next topic then
21:15:07 <slaweq> #topic Community goals
21:15:27 <slaweq> amotoki: any updates on policy-in-code?
21:15:33 <amotoki> yes
21:15:42 <amotoki> There are several updates on policy-in-code. The code is becoming a good shape, but I see several things.
21:15:59 <amotoki> I would liek to share three issues I see now.
21:16:19 <amotoki> First one is failures in unit tests and functional tests. When I dropped tests/etc/policy.json, they fail.
21:16:32 <amotoki> there is a test patch : https://review.openstack.org/#/c/619898/
21:16:44 <amotoki> Second is when I drop policy.json completely from devstack (https://review.openstack.org/#/c/619639/) somehow neutron-fullstack fails (patch set 6 of https://review.openstack.org/#/c/619639/)
21:16:58 <amotoki> Third is a problem caused by two policy enforcers (neutron and neutron-lib). neutron enforcer works fine but neutron-lib enforcer warns no corresponding rules if we have customized partial policy.json. I am exploring an approach.
21:17:04 <amotoki> My current priorities are first and second ones. Any helps on investigating failures would be appreciated.
21:17:18 <amotoki> this is updates from me
21:17:49 <slaweq> ok
21:18:00 <slaweq> I think You pasted wrong link to PS6 and fullstack failure
21:18:29 <amotoki> slaweq: you are correct. it should be "patch set 6 of https://review.openstack.org/#/c/585037/"
21:19:34 <amotoki> I am wondering why devstack policy.json change triggers fullstack failure. it needs more investigation
21:19:44 <slaweq> amotoki: I can help with that one
21:19:59 <slaweq> tomorrow I will take a look at this issue with fullstack tests
21:20:12 <amotoki> thanks
21:20:58 <slaweq> and what about those UT and functional tests? Do You have examples of failures too?
21:21:37 <amotoki> UT failure example is http://logs.openstack.org/98/619898/1/check/openstack-tox-py35/6b4fcc5/
21:22:09 <amotoki> handling of shared attribute of address scope is failing
21:22:22 <amotoki> this is the only failure pattern I see so far.
21:22:46 <slaweq> ok, so this doesn't looks like "big" issue :)
21:23:58 <amotoki> I hope so. perhaps it is caused by some difference between the real API processing and a plugin for UT.
21:24:16 <slaweq> yep, it is possible
21:25:29 <slaweq> amotoki: and this http://logs.openstack.org/98/619898/1/check/neutron-functional/d21121c/logs/testr_results.html.gz is functional failure, right?
21:26:00 <amotoki> yes, that's the one
21:26:10 <amotoki> both are linked from https://review.openstack.org/#/c/619898/
21:26:14 <slaweq> ok, so it is only one test which is failing
21:26:42 <slaweq> and I think both issues can be easily reproduced locally so debugging shouldn't be very hard probably
21:27:31 <amotoki> I think so too
21:27:42 <slaweq> ok, thx for update amotoki
21:27:54 <slaweq> I will ping You if I will find something with this fullstack issue
21:28:01 <slaweq> lets move on
21:28:03 <amotoki> note that we need to ensure /etc/neutron/policy.json does not exist to reproduce UT failure
21:28:10 <amotoki> let's move on
21:28:42 <slaweq> I think njohnston is not here, so we can skip python 3 goal today
21:29:25 <slaweq> and last one is upgrade checker cli tool
21:29:47 <slaweq> I have patch to allow loading checks from stadium/3rd party projects to neutron tool:
21:29:49 <slaweq> https://review.openstack.org/#/c/615196/
21:30:24 <slaweq> I did it in the way that stadium projects can register their own checks in entry_points
21:30:35 <slaweq> and each check function is one entry point
21:30:49 <slaweq> amotoki proposed different approach
21:31:32 <amotoki> my approach is one entry point per stadium/3rd party project.
21:31:44 <slaweq> I would like others to review this patch and tell what is better solution in Your opinion - for me both are fine
21:32:40 <slaweq> amotoki: am I understand correct that then such stadium project should have some method like "get_checks()" or something like that, which we can call in neutron-status script to load all checks from stadium project?
21:32:51 <slaweq> is my understanding correct?
21:33:15 <amotoki> slaweq: correct
21:33:27 <slaweq> ok
21:33:35 <amotoki> I see a little difference. Only difference I see is per-project entry points looks easier to avoid naming conflict in check functions, but we can suggest the naming convention.
21:34:04 <slaweq> I'm starting thinking that Your idea is better :)
21:34:31 <amotoki> the similar approach is used in policy-in-code loader
21:34:49 <slaweq> yes, I saw it today when I was reviewing Your big patch
21:35:29 <amotoki> hehe
21:35:49 <slaweq> thx for suggestion amotoki, I will change it :)
21:36:16 <slaweq> ok, next topic then
21:36:18 <slaweq> #topic Bugs
21:36:37 <slaweq> yamamoto was bug deputy last week
21:36:55 <slaweq> I don't see report from him on ML but maybe I missed it today
21:36:59 <amotoki> http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000225.html
21:37:08 <slaweq> thx a lot amotoki
21:37:29 <slaweq> I was looking on openstack-dev ML :)
21:37:44 <slaweq> I have to remember this new one now
21:37:58 <bcafarel> :)
21:38:13 <slaweq> ok, so we have one critical bug from last week:
21:38:15 <slaweq> https://bugs.launchpad.net/neutron/+bug/1803745
21:38:16 <openstack> Launchpad bug 1803745 in neutron "neutron-dynamic-routing: unit test failures with master branch of neutron" [Critical,In progress] - Assigned to Hongbin Lu (hongbin.lu)
21:38:21 <slaweq> hongbin is assigned to it
21:38:27 <slaweq> any update hongbin?
21:38:50 <hongbin> there is a patch proposed to neutron-dynamic-routing
21:38:54 * hongbin is finding the link
21:39:03 <tidwellr> https://review.openstack.org/#/c/619652 ?
21:39:08 <hongbin> #link https://review.openstack.org/#/c/619652/
21:39:15 <hongbin> tidwellr: right, thx
21:39:41 <hongbin> slaweq: any specific question about this bug?
21:39:51 <slaweq> not from me
21:40:04 <slaweq> I see that yamamoto has some questions in review
21:40:22 <hongbin> yes, i think i replied to his comment
21:40:53 <slaweq> yes, and he replied to Yours too :P
21:41:19 <hongbin> ok, i will check it out
21:41:33 <slaweq> hongbin: thx
21:41:56 <slaweq> from other bugs I would like to highlight one high: https://bugs.launchpad.net/neutron/+bug/1799737
21:41:57 <openstack> Launchpad bug 1799737 in neutron "l3 agent external_network_bridge broken with ovs" [High,Confirmed]
21:42:14 <slaweq> which don't have assignment yet
21:43:30 <amotoki> the config option is deprecated but it seems we need to fix and backport it.
21:43:45 <hongbin> slaweq: doesn't you have a patch to remove that config?
21:43:49 <slaweq> yes, I think I know this patch
21:44:03 <amotoki> and then we would like to drop it in Stein (after cleaning up in other projects)
21:44:15 <slaweq> hongbin: yes, I have patch to remove this option finally but it seems that ironic is using it still and they need some time to get rid of it
21:44:34 <slaweq> so I don't know if we will be able to remove it in Stein finally
21:44:51 <hongbin> slaweq: i will look at the ironic side to see what we can do
21:44:58 <slaweq> it's already removed from some repos but still not from neutron :/
21:45:04 <slaweq> hongbin: thx a lot :)
21:45:20 <slaweq> and I will take a look at this bug this week
21:46:11 <slaweq> ok
21:46:20 <slaweq> this week's bug deputy is mlavalle
21:46:28 <slaweq> and he told me that he is aware of it already :)
21:46:37 <slaweq> so we are in good hands for sure
21:46:48 <slaweq> lets move on
21:46:51 <slaweq> next topic
21:46:52 <slaweq> #topic neutron-lib
21:47:00 <slaweq> boden: any updates?
21:47:03 <boden> hi
21:47:12 <boden> quickly since we are short on time
21:47:38 <boden> we were talking about doing a neutron-lib release this week... I'm still waiting for https://review.openstack.org/#/c/615941/
21:47:50 <boden> if there are other patches we need to wait for pls let me know
21:48:48 <boden> and finally a FYI... it seems bgpvpn's gate maybe broken... I filed https://bugs.launchpad.net/bgpvpn/+bug/1805240
21:48:49 <openstack> Launchpad bug 1805240 in networking-bgpvpn "Unit tests fail with: 'AnonymousUser' object has no attribute 'token'" [Undecided,New]
21:49:18 <boden> that's all I have really
21:49:53 <slaweq> is this UT failure related to neutron-lib?
21:50:16 <boden> slaweq not that I know of, other than its holding up some lib patches in bgpvpn
21:50:33 <slaweq> ahh, ok
21:50:43 <slaweq> thx for update then
21:51:36 <slaweq> and looking at list of neutron-lib patches at https://review.openstack.org/#/q/project:openstack/neutron-lib+status:open I don't think there is anything really needed to be released this week (except Your patch)
21:51:48 <boden> slaweq okay thanks
21:51:57 <slaweq> amotoki, please check it also as release liaision :)
21:52:34 <amotoki> slaweq: yes, I often check the release reviews :)
21:52:40 <slaweq> amotoki: thx :)
21:52:52 <slaweq> ok, lets move on
21:52:58 <slaweq> #topic os-ken
21:53:05 <slaweq> hongbin: any updates?
21:53:06 <hongbin> hi
21:53:26 <hongbin> first, we have a patch that rename everything from "ryu" to "osken"
21:53:28 <hongbin> #link https://review.openstack.org/#/c/619652/
21:53:43 <hongbin> this patch needs code reviews :)
21:53:56 <slaweq> I think You gave wrong link
21:53:58 <slaweq> :)
21:54:14 <hongbin> #link https://review.openstack.org/#/c/615655/
21:54:26 <hongbin> slaweq: right :)
21:54:44 <hongbin> after that patch is merged, i will propose another release
21:54:59 <slaweq> ok, I will review it tomorrow morning
21:55:11 <hongbin> on the neutron side, there is a POC patch for switching to the new library
21:55:13 <hongbin> #link https://review.openstack.org/#/c/607008/
21:55:33 <slaweq> I just wanted to ask about switch in neutron :) thx hongbin
21:55:57 <hongbin> there are some discussion in the reviews
21:56:20 <hongbin> the argument is about whether we should rename "ryu" to "osken" in neutron side
21:57:08 <amotoki> if "os_ken" is "ken", we don't need space changes :p
21:57:53 <slaweq> I will look at this patch but now I think that we could change it
21:58:08 <amotoki> I am not sure how often we have backports from ryu upstream.
21:58:24 <amotoki> it depends on maintenance cost. diff seems not a lot.
21:58:47 <slaweq> I don't think we will have a lot of such backports
21:59:01 <amotoki> yeah agree
21:59:03 <slaweq> as ryu isn't in very active development now, right?
21:59:38 <slaweq> ok, I think we need to finish now
21:59:52 <slaweq> sorry that I didn't get to on demand agenda today
22:00:02 <hongbin> the reason we need to create "ken" is that ryu will no longer be maintained, so no, i don't think ryu is very active
22:00:03 <slaweq> thx for attending
22:00:08 <amotoki> let's add demand agenda to the agenda
22:00:31 <slaweq> #endmeeting