14:00:46 <jlibosva> #startmeeting networking
14:00:47 <openstack> Meeting started Tue Nov 21 14:00:46 2017 UTC and is due to finish in 60 minutes.  The chair is jlibosva. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:50 <openstack> The meeting name has been set to 'networking'
14:00:51 <jlibosva> hi everyone
14:00:53 <mlavalle> o/
14:00:55 <annp> hi
14:00:59 <hichihara> hi
14:01:00 <jlibosva> #topic Announcements
14:01:20 <bcafarel> o/
14:01:20 <jlibosva> We're migrating the tempest tests to separate neutron-tempest-plugin repo
14:01:44 <jlibosva> so please if you want to send patches to either scenarios or api tests, it will need to go to neutron-tempest-plugin repo
14:02:04 <jlibosva> there are still patches in flight regarding zuul but they should be solved soon
14:02:58 <jlibosva> next one: we're slowly approaching Q2, Dec 7 should be the deadline
14:03:12 <mlavalle> jlibosva: how about a patch like this: https://review.openstack.org/#/c/519198/
14:03:15 <jlibosva> that's all from me, does anybody have anything to announce?
14:03:17 <mlavalle> ?
14:03:30 <jlibosva> mlavalle: looking
14:03:33 <mlavalle> that patch still goes in Neuron, right?
14:03:40 <mlavalle> Neutron^^^^
14:04:26 <jlibosva> mlavalle: right, it has corresponding patch in tempest-plugin repo: https://review.openstack.org/#/c/520233
14:04:32 <mlavalle> ++
14:04:59 <amotoki> in my understanding, job defintions should go to the neutron repo
14:05:16 <jlibosva> amotoki: the job definition uses tempest-plugin tho
14:05:21 <amotoki> sorry, job consumption should go to the neutron
14:05:34 <amotoki> jlibosva: yes, you are right
14:05:44 <jlibosva> ack :)
14:05:49 <mlavalle> amotoki: still useful to clarify, thanks
14:05:55 <jlibosva> anything else to announce?
14:06:10 <jlibosva> let's move on then
14:06:12 <jlibosva> #topic Blueprints
14:06:17 <jlibosva> #link https://launchpad.net/neutron/+milestone/queens-2
14:07:13 <jlibosva> that reminds me I should spend more time reviewing firewall logging patches ...
14:07:30 <jlibosva> anybody has anything related to blueprints? any blockers?
14:07:51 <annp> yeah, thanks in advance jakub
14:08:07 <mlavalle> https://blueprints.launchpad.net/neutron/+spec/floating-ip-rate-limit is making excellent progress
14:08:36 <mlavalle> the TC lib patch was merged last week
14:08:52 <mlavalle> Server side needs one more +2: https://review.openstack.org/#/c/424466/
14:09:13 <mlavalle> hhopefully haleyb can take a look
14:09:25 <annp> jlibosva: I'd like to speed up on firewall logging patch's because 7 DEC is deadline for Q2.
14:09:33 <hichihara> mlavalle: I checked the patch today and then I'll test it works fine in my env.
14:09:39 <jlibosva> annp: yes, I'm aware :)
14:09:49 <mlavalle> hichihara: thanks:-)
14:09:51 <annp> jakub, thanks :)
14:10:20 <haleyb> mlavalle: sorry, was late, workstation with my irc proxy lost power and i'm not near it
14:10:44 <mlavalle> haleyb: np, thanks
14:11:25 <mlavalle> hichihara: keep in mind the agent side is not ready yet
14:11:55 <hichihara> mlavalle: yeah. I'll try to check API side only.
14:12:21 <jlibosva> ok, any other BP worth discussion?
14:12:23 <amotoki> mlavalle: hichihara: about qos-fip patch?
14:12:38 <hichihara> amotoki: Right
14:12:51 <mlavalle> yeap
14:12:54 <amotoki> hichihara: thanks. two blueprints were being discussed :)
14:13:18 * mlavalle created the confusion :-(
14:14:26 <jlibosva> I thought the qos-fip patch is realated to the fip rate limit :)
14:15:19 <jlibosva> seems like we can move on now?
14:15:26 <mlavalle> I think so
14:15:28 <jlibosva> #topic Starter Approved RFEs
14:15:49 <jlibosva> I see three RFEs at the wikipage
14:15:54 <mlavalle> yeap
14:16:18 <mlavalle> available for new contributors to take them over
14:16:21 <jlibosva> #link https://bugs.launchpad.net/neutron/+bug/1653932
14:16:21 <openstack> Launchpad bug 1653932 in neutron "[rfe] network router:external field not exported" [Wishlist,Triaged]
14:16:27 <jlibosva> #link https://bugs.launchpad.net/neutron/+bug/1689830
14:16:28 <openstack> Launchpad bug 1689830 in neutron "[RFE] Add attribute to the a port that lists the UUIDs of other ports that the port is allowed to impersonate" [Wishlist,Triaged] - Assigned to Dongcan Ye (hellochosen)
14:16:33 <jlibosva> #link https://bugs.launchpad.net/neutron/+bug/1690438
14:16:33 <openstack> Launchpad bug 1690438 in neutron "[RFE] make get-me-a-network work with any network topology" [Wishlist,Triaged] - Assigned to Benjamin Kennel (bkennel)
14:16:57 <mlavalle> apparently the third one was claimed over the past few days
14:17:04 <jlibosva> mlavalle: two are assigned, does it mean we do have contributors for those?
14:17:25 <mlavalle> yeah, it looks like it
14:17:28 <mlavalle> Nice!
14:17:28 <jlibosva> nice :)
14:18:02 <mlavalle> This is what this is for :-)
14:18:57 <jlibosva> anything else related to those RFEs? any volunteers for the first one? ;)
14:19:15 <jlibosva> I guess we can jump to bugs then
14:19:17 <jlibosva> #topic Bugs
14:19:19 <mlavalle> yeap
14:19:40 <jlibosva> the bug deputy for the last week was bzhao
14:20:10 <mlavalle> no, I think it was haleyb
14:20:19 * haleyb thought it was me as well
14:20:26 <jlibosva> ah, sorry :)
14:20:47 * jlibosva puts on his glasses
14:20:49 <mlavalle> yeah, bzhao is this week
14:20:53 <jlibosva> right
14:21:03 <haleyb> There was one critical that came in, possible DoS
14:21:06 <haleyb> https://bugs.launchpad.net/neutron/+bug/1732294
14:21:06 <openstack> Launchpad bug 1732294 in neutron "Probable DOS in linuxbridge" [Critical,In progress] - Assigned to Brian Haley (brian-haley)
14:21:22 <haleyb> i proposed a patch but submitter wasn't able to verify it
14:21:34 <haleyb> https://review.openstack.org/520249
14:22:29 <haleyb> needs some update testing since both old and new rules would be installed on a restart
14:23:12 <haleyb> this one slipped through the cracks, https://bugs.launchpad.net/neutron/+bug/1732067
14:23:12 <openstack> Launchpad bug 1732067 in neutron "openvswitch firewall flows cause flooding on integration bridge" [Undecided,New]
14:23:29 <haleyb> came in between deputies
14:23:44 <jlibosva> I actually consulted that with James
14:24:01 <jlibosva> on irc
14:24:24 <haleyb> perfect
14:24:26 <jlibosva> I didn't add a proper tag though, thanks for bringing this up :)
14:25:21 <mlavalle> jlibosva: how important should it be?
14:26:27 <jlibosva> mlavalle: I'm not really sure I understand clearly the issue. It's that replies don't know where to go because on incoming traffic we bypass normal switching, so the replies are sent to all interfaces on given local network
14:26:41 <jlibosva> mlavalle: I don't think it's severe
14:26:54 <jlibosva> but maybe rackspace folks think it is :)
14:27:21 <jlibosva> also I don't know how to fix it as the output action is much faster then normal action in openflow
14:27:25 <mlavalle> :-)
14:28:10 <haleyb> there were some other dhcp-related bugs, all medium, and a lot of api-ref bugs by boden :)
14:28:20 <haleyb> this was the only other high, https://bugs.launchpad.net/neutron/+bug/1732543
14:28:20 <openstack> Launchpad bug 1732543 in neutron "HA network tenant network fails upon router delete" [High,Confirmed]
14:28:52 <haleyb> a fix was proposed, but breaks something else, on my L3 radar now
14:29:57 <jlibosva> should we assign it to Steven then?
14:31:04 <haleyb> i asked him to send it out for review, but he didn't know the workflow we have, havne't seen a response after that yet
14:31:44 <jlibosva> I see but he seems to be one working on it, so it makes sense to me to have an assignee
14:31:49 <jlibosva> we can remove it if he goes silent
14:31:58 <haleyb> sure, i'll assign it to him
14:32:08 <mlavalle> ++
14:32:12 <jlibosva> I did :)
14:32:23 <jlibosva> haleyb: thanks for the report
14:32:27 <jlibosva> I think we can move to docs now
14:32:31 <haleyb> yup
14:32:34 <jlibosva> #topic Docs
14:32:51 <jlibosva> boden: hi :)
14:32:56 <boden> hi
14:33:10 <jlibosva> do you want to give any updates?
14:33:36 <boden> the only think I wanted to mention (already hinted by haleyb) is that I went through all neutron extensions and determined those that needed updates in the api-ref
14:33:49 <boden> I created a bug for each that needs work in case someone else wants to help out
14:34:08 <boden> they all have the ‘api-ref’ tag.. https://bugs.launchpad.net/neutron/+bugs?field.tag=api-ref
14:34:14 <mlavalle> ok, so you need volunteers
14:34:25 <boden> no its fine.. I can process them over the next few weeks
14:34:44 <boden> just saying if someone gets bored feel free to join the party if you want
14:34:51 <mlavalle> cool
14:34:58 <boden> that’s all I really have
14:35:30 <jlibosva> boden: thanks
14:35:49 <jlibosva> boden: don't go far
14:35:51 <jlibosva> #topic neutron-lib
14:35:58 <boden> hi again
14:36:00 <jlibosva> hi! :)
14:36:08 <boden> so a high-level thing
14:36:32 <boden> based on recent ML discussion it appears we will start publishing server projects to pypi.. including neutron
14:36:37 <boden> http://lists.openstack.org/pipermail/openstack-dev/2017-November/124676.html
14:37:21 <boden> one of the main motivations for neutron-lib was to provide something that could be released to pypi and versioned; since neutron couldn't
14:37:22 <jlibosva> #link http://lists.openstack.org/pipermail/openstack-dev/2017-November/124676.html
14:37:54 <boden> so my question becomes; do we need to rethink what we want to do with neutron-lib, or just keep moving forward
14:38:25 <boden> there are still some benefits to neutron-lib… consolodate concrete interfaces, reduce dependencies (neutron pulls along a number), etc..
14:38:40 <boden> anybody have thoughts on this topic?
14:38:48 <jlibosva> wasn't the motivation also that other projects don't need to fetch the whole neutron code base with specific implementation ?
14:38:56 <mlavalle> I don't know what to say right now. I will take a look at the thread and discuss in the channel
14:39:00 <jlibosva> ah, you just wrote it in the meantime
14:39:19 <boden> is armax around?
14:39:20 <mlavalle> for the time being, I say let's carry on
14:39:31 <boden> doesnt look like it
14:39:33 <boden> ok
14:40:07 <jlibosva> boden: anything else for the lib?
14:40:08 <boden> thats all I have
14:40:10 <jlibosva> ok, thanks
14:40:22 <jlibosva> #topic Migration to OSC
14:40:30 <jlibosva> amotoki: do you want to give updates?
14:40:43 <amotoki> hi
14:40:54 <amotoki> there are several things
14:41:25 <amotoki> there are several pending patches in neutronclient repo. reviews would be appreciated
14:41:38 <amotoki> it looks better to cut a release at some point.
14:42:46 <amotoki> the second thing is https://review.openstack.org/#/c/518954/ . haleyb proposed a patch to change the default protocol of a new sg rule.
14:43:00 <amotoki> I would like to ask opinions for others.
14:43:11 <haleyb> yes, i had forgotten about thatone
14:43:21 <amotoki> there is a discussion on backward-compat on OSC vs on neutron CLI.
14:44:13 <haleyb> there was a change merged to OSC that defaulted the protocol to 'tcp' and it was noticed as not the same as the neutron client
14:44:42 <haleyb> i was annoyed because noone from neutron was even asked to review it
14:44:46 <amotoki> yes, the default value comes from nova sg rule implementation and OSC supports both
14:45:18 <amotoki> I will leave a comment after the meeting
14:45:37 <mlavalle> so, provide feedback in the review
14:45:39 <mlavalle> ?
14:45:40 <haleyb> it is *almost* backwards-compatible in that if you specify a port range you must specify a protocol
14:46:18 <haleyb> dean has said he would allow it in OSC4 only
14:46:32 <amotoki> that is good point
14:47:38 <amotoki> anyway feel free to leave comments/bugs if you feel odd around the migration to OSC
14:48:07 <amotoki> the last thing is https://bugs.launchpad.net/neutron/+bug/1705755 raised by boden
14:48:07 <openstack> Launchpad bug 1705755 in neutron "[RFE] Plugin support for API resource attribute extensions" [Wishlist,Triaged]
14:48:33 <amotoki> i wouldn't like to discuss the detail here. feedback would be appreciated.
14:48:51 <amotoki> it is one of big gaps around the migration
14:49:01 <amotoki> that's all from me
14:49:01 <mlavalle> amotoki: it was discussed in the drivers meeting last Thursday
14:49:08 <mlavalle> please chack the logs
14:49:15 <mlavalle> check
14:49:17 <amotoki> mlavalle: thanks. i haven't checked the log
14:49:22 <amotoki> will check it soon
14:49:28 <mlavalle> I will update the RFE itself today
14:50:43 <amotoki> i think we can move on to the next topic if nothing else
14:50:49 <jlibosva> amotoki: thanks
14:50:56 <jlibosva> #topic open discussion
14:51:04 <jlibosva> does anybody have a topic he'd like to discuss here?
14:51:15 <haleyb> one question
14:51:39 <jlibosva> haleyb: go ahead
14:51:51 <jlibosva> I see two topics at the wiki
14:51:59 <haleyb> ok, mine isn't on the wiki
14:52:13 <jlibosva> haleyb: so go ahead, we can discuss those after :)
14:52:38 <haleyb> amotoki: i know you cover the osc client, but how do we make sure neutronions are always added to network reviews?
14:53:26 <haleyb> relying on people seeing the review emails isn't enough
14:53:55 <amotoki> haleyb: honestly i am not sure what is a better way.
14:54:23 <haleyb> ok, i was even looking through the repo looking for a doc but didn't see anything
14:54:32 <amotoki> i think there is a way to query which file(s) are included in a review.
14:54:40 <amotoki> it might help us
14:55:07 <haleyb> yes, i'd be ok with receiving emails if they are networking ones
14:55:19 <amotoki> previously i checked networking guide reviews in openstakc-manuals by using "path:^doc/networking-guide/.*' in my gerrit dashboard
14:55:42 <haleyb> ok, thanks, i'll try the same with osc
14:55:59 <haleyb> jlibosva: back to you
14:56:04 <jlibosva> let's jump to those topics from wiki then
14:56:17 <hoangcx_> Hi jlibosva, VPNaaS team is working on stadium inclusion, almost required criteria have been addressed/addressing. It needs to get attention from core reviewers in order to help it jump into the stadium in Queens.
14:56:20 <jlibosva> hoangcx_: hi, you have one VPNaaS stadium inclusion request: https://review.openstack.org/#/c/506012/
14:56:49 <jlibosva> mlavalle: ^^ I think it will need PTL's blessing :)
14:57:02 <mlavalle> yeap, I will look at it this week
14:57:12 <hoangcx_> jlibosva: I discussed with yamamoto and got suggestion to raise it here. Hopefully can get comments/decision from cores :)
14:57:32 <jlibosva> hoangcx_: yes, thanks for bringing this up :)
14:57:37 <mlavalle> hoangcx_: I will look at it this week
14:57:45 <hoangcx_> thanks a lot mlavalle jlibosva :)
14:57:50 <jlibosva> bcafarel: next one is yours: "Should we use a single repo for all stadium split tempest plugins? http://lists.openstack.org/pipermail/openstack-dev/2017-October/123814.html"
14:58:15 <bcafarel> indeed
14:58:31 <jlibosva> I don't know answer to that question
14:58:39 <bcafarel> the topic should be short :) I'd just welcome some feedback (and decision) on the topic
14:58:55 <mlavalle> bcafarel: do you see any downsides to having one repo for tempest tests?
14:59:02 <jlibosva> it would make sense to me to have test repo per project but that would create loots of new projects :)
14:59:34 <bcafarel> mlavalle: no downside apart from the creation job
15:00:09 <bcafarel> but as some other parts are in common repos, armax brought the question
15:00:14 <mlavalle> I think we are short of people now in general so creating a lot of new projects will be difficult
15:00:15 <amotoki> we have tempest API test and we have a single place neutron-lib to have API defintions. it makes sense to have a single repo in this context
15:00:22 <amotoki> but this is only one aspect
15:00:33 <jlibosva> maybe we could discuss this on ML
15:00:35 <jlibosva> we're out of time
15:00:37 <amotoki> +1
15:00:45 <bcafarel> oops indeed
15:00:45 <jlibosva> thanks bcafarel
15:00:51 <jlibosva> and thanks everyone for showing up
15:00:52 <amotoki> I completely missed that mail
15:00:54 <jlibosva> #endmeeting