14:00:57 <kevinbenton> #startmeeting networking
14:01:01 <openstack> Meeting started Tue Feb 28 14:00:57 2017 UTC and is due to finish in 60 minutes.  The chair is kevinbenton. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:05 <openstack> The meeting name has been set to 'networking'
14:01:07 <ihrachys> o/
14:01:09 <john-davidge> o/
14:01:10 <mlavalle> o/
14:01:11 <hoangcx> o/
14:01:21 <andreas_s> hi
14:01:53 <kevinbenton> #topic announcments
14:01:56 <bcafarel> hi
14:02:18 <kevinbenton> I sent out an email last night with a big summary of things that were covered at the PTG
14:02:26 <kevinbenton> #link http://lists.openstack.org/pipermail/openstack-dev/2017-February/113032.html
14:02:48 <ihrachys> that's huge, wow.
14:02:48 <kevinbenton> Take some time to look over it
14:03:05 <dasm> kevinbenton: thanks for doing that
14:03:15 <kevinbenton> If there were any topics I completely forgot, please reply to that email with a brief summary
14:03:39 <kevinbenton> but if there is anything you want to expand on or have a discussion about, please start a new email thread with a different subject
14:03:40 <ajo> late o/
14:03:49 <kevinbenton> so it doesn't become the Neutron development megathread
14:03:54 <john-davidge> kevinbenton: Thanks, this is great
14:04:06 <dalvarez> o/
14:04:23 <ajo> ++
14:04:47 <kevinbenton> This announcement is from the last meeting, but a quick reminder that the Pike spec repository is open
14:05:01 <kevinbenton> so if you had any specs for Ocata, retarget them to Pike
14:05:15 <kevinbenton> and propose new specs under that folder
14:05:47 <dasanind> o/
14:06:00 <kevinbenton> If you had any features that were targeting Ocata, please review the postmortem patch from armax
14:06:06 <kevinbenton> #link https://review.openstack.org/#/c/425990/
14:06:37 <kevinbenton> This applies to all stadium projects IIRC
14:07:23 <kevinbenton> Does anyone have any questions about the above or have any other announcements to make?
14:07:46 <john-davidge> kevinbenton: Do you intend to keep the postmortems going for future releases? Personally I think they're great.
14:07:59 <mlavalle> ++
14:08:12 <kevinbenton> john-davidge: yeah, i'll try to keep that tradition up
14:08:20 <kevinbenton> john-davidge: i may conscript armax to help
14:08:26 <john-davidge> kevinbenton: :)
14:09:11 <kevinbenton> #topic Bugs
14:09:34 <kevinbenton> i see from the wiki electrocucaracha was bug deputy last
14:09:48 <kevinbenton> but he's not online
14:10:12 <kevinbenton> does anyone have any bugs that need discussion with the wider team?
14:10:48 <ihrachys> I would like to remind folks that if you cannot join, you should send a report as per https://docs.openstack.org/developer/neutron/policies/bugs.html#neutron-bug-deputy
14:10:53 <ihrachys> I mean, if you are a bug deputy :)
14:11:32 <ihrachys> do we have deputies for next weeks?
14:11:33 <kevinbenton> speaking of which, does anyone want to volunteer to be bug deputy this week?
14:12:50 <kevinbenton> i can do it
14:13:05 <kevinbenton> #info kevinbenton for bug deputy week of feb 28th
14:14:02 <ihrachys> thanks kevinbenton
14:14:19 <kevinbenton> any volunteers now for next week?
14:14:41 <dasanind> kevinbenton: I can do next week
14:14:42 <reedip> hi
14:14:49 <kevinbenton> dasanind: thanks
14:15:25 <kevinbenton> #info dasanind for bug deputy week of mar 6th
14:16:24 <kevinbenton> #topic gate issues
14:16:38 <kevinbenton> ihrachys: quick update since we have a separate meeting, any big blockers we need to be aware of?
14:17:08 <ihrachys> we had breakages due to devstack-gate local.conf logic on Fri but those are contained for the most part in neutron repo
14:17:30 <ihrachys> it also broke some stadium repos like fwaas (fix should be in for master, maybe backport needed)
14:17:55 <kevinbenton> ack
14:17:56 <ihrachys> I advise stadium project owners to check their gates and fix/reach out to me about details
14:18:15 <ihrachys> it also seems we have fragile gate hook
14:18:30 <ihrachys> there is ongoing work on that matter in scope of https://review.openstack.org/438682
14:18:36 <ihrachys> that may also need to be backported later
14:19:10 <ihrachys> apart from that, business as usual (oom-killers, libvirtd crashing, dragons burning villages)
14:19:23 <ihrachys> that's all I have, we'll elaborate in CI meeting in 2h
14:19:26 <kevinbenton> ihrachys: fragile in the sense that it randomly fails, or we are just a patch away from broken?
14:19:43 <ihrachys> kevinbenton: as in 'gonna be broken in next weeks if we don't adopt to the right path'
14:19:48 <kevinbenton> ihrachys: ack
14:20:30 <kevinbenton> #topic neutron-lib
14:20:39 <kevinbenton> boden: any news?
14:21:18 <kevinbenton> #info neutron-lib is complete :)
14:21:56 <boden> kevinbenton: sorry I stepped away for a min
14:21:58 <ihrachys> huh, WAT. is it 2025 already?
14:22:06 <kevinbenton> boden: no prob
14:22:13 <kevinbenton> boden: wanna give us a quick neutron-lib update?
14:22:55 <boden> as listed on the neutron meeting wiki; we have 2 lib impact changes in progress… they’ve been out for awhile so IMO they are about ready to merge
14:23:43 <boden> as we discussed at the PTG and I summerized in ML yesterday, we are proposing a single set of hacking checks for neutron-lib consumers.. just a heads up (again) as this impacts a number of projects
14:24:16 <boden> there are also a number of patches ready for review in neutron-lib… if you get time please take a peek :)
14:24:35 <kevinbenton> boden: are these the impact changes? https://review.openstack.org/#/q/status:open+message:%22NeutronLibImpact%22
14:25:30 <ihrachys> I think we should speed up landing for neutron context patch. it's the best timing for such a huge change.
14:25:56 <ihrachys> armax mentioned that this should happen after subprojects release ocata, I think sfc was the last one sched for this Wed
14:26:10 <boden> kevinbenton: yes but that list is a bit messy a cleaner picture might be: https://review.openstack.org/#/q/status:open+message:%22NeutronLibImpact%22+project:openstack/neutron
14:26:27 <boden> ihrachys: agree… the same goes for moving to the neutron-lib callbacks
14:26:48 <ihrachys> I also see a lot of helpers to be killed with https://review.openstack.org/#/c/433034/ was it ever announced?
14:27:16 <ihrachys> oh sorry, those helpers were already marked with deprecations
14:27:28 <boden> ihrachys: I didn’t see an announce, but perhaps I missed it… I’ll follow up with garyk on that one
14:27:39 <kevinbenton> #link https://review.openstack.org/#/c/388157/
14:27:46 <kevinbenton> context spinoff patch
14:28:07 <mlavalle> so we want this merged soon, right?
14:28:27 <kevinbenton> #info any importers of neutron.context will break after merge of https://review.openstack.org/#/c/388157/ . please import from neutron-lib
14:28:57 <kevinbenton> mlavalle: yep
14:29:02 <kevinbenton> mlavalle: deal with the pain now
14:29:09 <ihrachys> mlavalle: I would hope so. it's start of the cycle, better soon than late
14:29:23 <mlavalle> Agree with both
14:31:01 <boden> also FYI: I sent a note to ML yesterday, but there was some discussion on forbidding provider net extended attrs update (PUT) at the API layer in https://review.openstack.org/#/c/421961/   however it doesn’t appear folks think this is the right approach so I’m guessing it won’t end up merging
14:31:01 <dasm> fyi. neutron-lib 1.2.0 got released recently and soon should land in requirements. so from now on, all the latest features provided by boden can be used
14:31:20 <boden> well; not just my features :)
14:31:27 <kevinbenton> boden-lib
14:31:28 <kevinbenton> :)
14:31:31 <boden> ha
14:31:37 <dasm> ok, so fancy features from boden and couple others, not so fancy ;)
14:31:39 <ihrachys> kevinbenton was going to look at allowing updates for the field
14:31:44 <ihrachys> that's why we put -2 for now
14:32:28 <kevinbenton> ihrachys: yeah, with our internal segments API now, it may be much simpler to allow this
14:32:43 <kevinbenton> ihrachys: but I haven't had a chance to look into it yet
14:33:36 <ihrachys> speaking of stadium projects, I just spotted dynamic-routing has broken periodic job in grafana
14:33:49 <ihrachys> that's due to models moved in Ocata, and the fix will be https://review.openstack.org/#/c/438739/
14:34:08 <ihrachys> please approve so that we can land next breaking changes "safely"
14:34:27 <ihrachys> otherwise they will need to squash and that's not cool
14:34:51 <kevinbenton> ack
14:35:00 <ihrachys> oh also midonet and ovn broken
14:35:40 <ihrachys> as per the dashboard at least. though I don't see any ovn failure in gerrit
14:35:59 <russellb> when did the breaking change land?
14:36:10 <russellb> networking-ovn has merged several changes in the last 12 hours or so
14:36:33 <ihrachys> russellb: then you are good and it was one off
14:36:33 <dasm> btw. are we still in neutron-lib section? shouldn't we change that?
14:36:42 <ihrachys> I think the impactful is https://review.openstack.org/#/c/436312/
14:36:47 <russellb> ihrachys: ok thanks for looking out
14:36:54 <ihrachys> midonet is definitely borked by it, and there is no fix yet
14:37:06 <kevinbenton> dasm: we divered a bit
14:37:29 <kevinbenton> boden: any other neutron-lib related things?
14:37:48 <boden> kevinbenton: I think that’s enough for now
14:38:16 <kevinbenton> #topic OSC
14:38:29 <kevinbenton> any updates on the OSC transition?
14:39:01 <amotoki> no update to report.
14:39:39 <kevinbenton> #topic docs
14:39:44 <kevinbenton> john-davidge: anything?
14:40:18 <john-davidge> So kevinbenton mentioned in in the PTG summary email, but I'd like to highlight the point about DocImpact
14:41:07 <john-davidge> When reviewing patches with a DocImpact tag, please make sure the commit message includes a summary of the doc change needed, whether its in the neutron tree or openstack-manuals
14:41:20 <john-davidge> That helps a lot with triaging the resulting bugs
14:41:40 <john-davidge> Also, we have some chnages planned for the Networking Guide over the Pike cycle: https://etherpad.openstack.org/p/networking-guide-improvements
14:42:00 <john-davidge> Anybody who's interested in working in the guide is most welcome :)
14:42:05 <john-davidge> That's it
14:42:13 <kevinbenton> john-davidge: thanks
14:42:53 <kevinbenton> some on demand topics on here from the last meeting
14:43:08 <kevinbenton> #topic Disable security group filter refresh on DHCP port changes
14:43:22 <kevinbenton> i don't think mdorman is around
14:43:37 <kevinbenton> he wanted to discuss https://review.openstack.org/#/c/416380/
14:44:11 <kevinbenton> I think that will be superceded by https://review.openstack.org/#/c/432506/ if we go that route
14:45:12 <kevinbenton> #topic Logging API for security groups
14:45:21 <kevinbenton> I think this was discussed at the PTG
14:45:36 <kevinbenton> so we probably don't need to discuss it again here
14:45:56 <hoangcx> +1. Thanks kevin
14:46:07 <kevinbenton> #topic Open Discussion
14:46:15 <kevinbenton> anyone have anything else to discuss?
14:46:33 <mlavalle> kevinbenton: quick update to your PTG summary of last night. For moving floating ips to central node in DVR, swami already filed a RFE: https://bugs.launchpad.net/neutron/+bug/1667877
14:46:33 <openstack> Launchpad bug 1667877 in neutron "[RFE] DVR support for Configuring Floatingips in Network Node or in the Compute Node based on Config option." [Undecided,New] - Assigned to Miguel Lavalle (minsel)
14:47:25 <dasm> one thing from me: all stadium projects are now following cycle with milestones. everything will be synced now: https://review.openstack.org/#/c/437699/
14:47:49 <mlavalle> and I assigned it to me :-)
14:48:11 <ihrachys> dasm: oh that's nice, less headache for release team.
14:48:12 <kevinbenton> mlavalle: thanks, do you want to reply to that email with just a pointer to the RFE?
14:48:21 <mlavalle> kevinbenton: will do
14:48:33 <dasm> ihrachys: i agree
14:48:34 <electrocucaracha> sorry for being late, regarding the bugs of last week most of the criticals were reported by you kevinbenton , there is a couple of invalid and other features
14:49:02 <kevinbenton> electrocucaracha: ok, thanks
14:49:23 <electrocucaracha> there is only one that I would like to bring to discussion https://bugs.launchpad.net/neutron/+bug/1667500
14:49:23 <openstack> Launchpad bug 1667500 in neutron "Openstack add 'deafult' security group to a VM when attaching new interface to new network even the VM have customized secgroup" [Undecided,New]
14:49:25 <kevinbenton> dasm: cool. hopefully this works smoothly :)
14:49:46 <electrocucaracha> but that discussion can happen offline
14:50:39 <kevinbenton> electrocucaracha: ack. i'll take a look
14:51:07 <ihrachys> electrocucaracha: sounds like behaviour as designed
14:51:25 <ihrachys> sec groups are per port
14:51:34 <kevinbenton> ihrachys, electrocucaracha: yeah, i think it would need to be a feature change on the nova side if they wanted this
14:51:45 <ihrachys> +
14:51:47 <kevinbenton> to alter the port create request nova is making
14:51:51 <amotoki> tend to agree with ihar, but there may be a room to improve nova interaction
14:51:52 <electrocucaracha> ihrachys: agree
14:52:14 <dasm> amotoki: "improve nova integration" as always ;)
14:52:17 <kevinbenton> electrocucaracha: i would mark nova as an affected project because I don't think there is anything we can do on the neutron side
14:52:23 <ihrachys> it's always nova's fault
14:52:30 <amotoki> perhaps nova side instead of nova interaction
14:52:38 <ihrachys> +, close neutron side as Won't Fix and allow nova folks to triage
14:52:55 <kevinbenton> from neutron's perspective it's just a normal port create and we can't change that behavior
14:53:09 <electrocucaracha> but there is a place in neutron where we ensure the existence of the default security group rule
14:53:36 <kevinbenton> electrocucaracha: right, but that's different from which security group is assigned to the port
14:53:57 <kevinbenton> electrocucaracha: if they want a different group assigned to the port, that needs to be in the port create body
14:54:00 <ihrachys> I just closed it from neutron side and opened for nova
14:54:16 <electrocucaracha> thanks ihrachys
14:54:25 <amotoki> nova maintains security groups associated with a VM itself, so nova can take care of the default secgroup when creating a new port from nova.
14:54:32 <kevinbenton> amotoki: right
14:54:44 <kevinbenton> amotoki: seems like a reasonable feature request for them
14:54:54 <kevinbenton> anything else?
14:54:56 <amotoki> kevinbenton: agree
14:55:37 <kevinbenton> ok, thanks everyone!
14:55:43 <kevinbenton> #endmeeting