14:00:26 <ihrachys> #startmeeting networking
14:00:29 <openstack> Meeting started Tue Jul 19 14:00:26 2016 UTC and is due to finish in 60 minutes.  The chair is ihrachys. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:00:32 <openstack> The meeting name has been set to 'networking'
14:00:34 <ihrachys> hello neutrinos
14:00:36 <dasm> o/
14:00:36 <mlavalle> o/
14:00:39 <hichihara> hi
14:00:40 <ivc_> o/
14:00:40 <HenryG> o/
14:00:41 <amuller> hiya
14:00:44 <njohnston> joyous ${localtime}, all
14:00:45 <yamahata> hello
14:00:49 <hoangcx> hi
14:00:57 <bcafarel> howdy
14:01:10 <annp> Hi
14:01:13 <ralonsoh> hi
14:01:13 <john-davidge> o/
14:01:17 <korzen> hello
14:02:00 <ihrachys> the agenda for today is...
14:02:01 <ihrachys> #link https://wiki.openstack.org/wiki/Network/Meetings
14:02:16 <ihrachys> #topic Announcements
14:02:23 <ihrachys> as you know, we are past N2 now
14:02:42 <ihrachys> #link http://releases.openstack.org/newton/schedule.html
14:02:49 <ihrachys> N-3 is the end of Aug
14:03:28 <ihrachys> note that libraries are freezed at around that same time. so if your feature has a library piece (neutron-lib, client, ...) please make sure you land it in time
14:03:33 <ihrachys> otherwise you risk to slip into O
14:04:01 <HenryG> Well, for neutron-lib it's a bit different ...
14:04:15 <ihrachys> HenryG: I don't think so: requirements are frozen too
14:04:35 <HenryG> You can carry a local copy of code until the neutron-lib catches up, is what I mean.
14:05:17 <ihrachys> yeah, sure. since it's our own child, we can make a shortcut.
14:05:19 <HenryG> Just saying that neutron-lib should not hold anyone up.
14:05:43 <ihrachys> thanks for clarification, it's useful
14:06:05 <ihrachys> one more announcement: we seem to get into high time for bike shedding and yak shaving
14:06:27 <ihrachys> some of you may have received next release naming voting invitations, please check the mailbox and vote
14:06:48 <ihrachys> and also, neutron is picking a mascot for the team
14:06:49 <ihrachys> #link http://lists.openstack.org/pipermail/openstack-dev/2016-July/099281.html
14:07:04 <ihrachys> there, you will find instructions and a link to an etherpad with votes.
14:07:13 <HenryG> https://etherpad.openstack.org/p/neutron-project-mascot
14:07:42 <ihrachys> everyone has a chance to propose something original, like some already did
14:07:46 * ihrachys looks at line 60)
14:08:22 * john-davidge wonders if line 60 is safe to google
14:08:30 <ihrachys> finally, a reminder we have a midcycle in August in Cork
14:08:30 <dasm> john-davidge: yes, it is. checked :)
14:08:45 <mlavalle> the mid-cycle etherpad is here:
14:08:51 <mlavalle> #link https://etherpad.openstack.org/p/newton-neutron-midcycle
14:08:59 * ihrachys bows to mlavalle and HenryG for helping me with links
14:09:06 <mlavalle> LOL
14:09:08 <ihrachys> #link Blueprints
14:09:21 <ihrachys> the current targeted bps are at:
14:09:22 <ihrachys> #link  https://launchpad.net/neutron/+milestone/newton-3
14:09:28 <ihrachys> we won't go thru them today.
14:09:39 <amotoki> s/link/topic/?
14:09:52 <ihrachys> #topic Blueprints
14:10:05 <ihrachys> #link  https://launchpad.net/neutron/+milestone/newton-3
14:10:21 <ihrachys> assignees and approvers, make sure whiteboards are up to date
14:10:42 <ihrachys> so that both the state of specs and patches are reflected there.
14:10:47 <ihrachys> #topic Bugs and Gate failures
14:11:10 <ihrachys> blogan was the deputy the previous week.
14:11:34 <ihrachys> blogan: would you mind giving a brief status update?
14:11:56 <blogan> the only thing pertinent now is a bug amuller reported
14:11:58 <blogan> https://bugs.launchpad.net/neutron/+bug/1604115
14:11:58 <openstack> Launchpad bug 1604115 in neutron "test_cleanup_stale_devices functional test sporadic failures" [Medium,Confirmed]
14:12:12 <amuller> I added some info there
14:12:47 <blogan> other than that, i didn't get t some bugs yesterday, so i can help mlavalle out with those if needed bc he's next deputy
14:13:06 <mlavalle> I am ready to go. Thanks!
14:13:20 <ihrachys> amuller: thanks. do we have candidates to explore the failure further?
14:13:34 <ihrachys> blogan: yes, please talk to mlavalle to make sure nothing cracks in
14:14:14 <amuller> ihrachys: I don't think anyone volunteered yet :) I was thinking of adding a wait_until for the assertion of the number of devices, merging that and monitoring that test's failure rate, I suspect it will go to 0
14:15:08 <ihrachys> amuller: ok, let's see if someone picks it up in due time
14:15:29 <ihrachys> there is another high impact gate failure right now, in grenade multinode
14:15:31 <ihrachys> #link https://bugs.launchpad.net/neutron/+bug/1603268
14:15:31 <openstack> Launchpad bug 1603268 in neutron "Unstable grenade multinode job" [Critical,In progress] - Assigned to Ihar Hrachyshka (ihar-hrachyshka)
14:15:48 <ihrachys> the patch to unravel it is not in neutron though
14:15:49 <ihrachys> #link https://review.openstack.org/#/c/343024/
14:16:02 <ihrachys> so we need to pull in devstack-gate/devstack cores to get the fix in the gate.
14:16:13 <ihrachys> I was thinking of sc68cal and garyk
14:16:40 <sc68cal> devstack-gate 's cores are separate from devstack
14:16:59 <sc68cal> there is some overlap but I'm not core for d-g
14:17:08 <ihrachys> ack. that said, devstack-gate piece is already +W
14:17:21 <ihrachys> so it's now a matter of devstack (with stable branches)
14:17:36 <sc68cal> ok, I'll do my bit on the devstack side
14:18:01 <ihrachys> I personally don't have devstack stable +2 vote, so I can't help much
14:18:14 <ihrachys> sc68cal: thanks
14:18:29 <ihrachys> we need a bug deputy volunteer for the next week
14:19:06 <john-davidge> ihrachys: which date?
14:19:18 <ihrachys> the week starting on July 25.
14:19:38 <mlavalle> one week from now
14:19:46 <jlibosva> I can volunteer
14:20:32 <ihrachys> jlibosva: sold! :) please update the wiki page to include your name in the corresponding section
14:20:43 <jlibosva> will do
14:21:00 <ihrachys> if there are more volunteers for the week after that, please speak up, otherwise we'll pick on the next meeting.
14:21:31 <ihrachys> thanks to all bug deputies for serving the duty
14:21:33 <ihrachys> #topic Docs
14:21:50 <ihrachys> anyone to give an update on docs?
14:21:56 <HenryG> http://lists.openstack.org/pipermail/openstack-dev/2016-July/099558.html
14:22:22 <ihrachys> amotoki: which dates do you have in mind for the sprint?
14:22:22 <HenryG> Hot off the press. :)
14:22:32 <amotoki> thanks HenryG.
14:22:37 <amotoki> I haven't set a specific period for the virtual sprint, but I would like to complete the sprint by Newton-3 milestone.
14:23:13 <amotoki> we'd like to encourage folks to join the effort.
14:23:45 <ihrachys> amotoki: aren't picking specific dates when folks can justify their focus on the topic an essence of a sprint?
14:23:51 * njohnston would like to join if it doesn't overlap with his PTO
14:24:54 <amotoki> ihrachys: we can set some date on the virtual sprint, but i think we need to coordinate it with other events.
14:25:26 <ihrachys> amotoki: yeah. midcycles come to mind. so probably it's worth exploring the events calendar to see where we have a hole
14:25:51 <amotoki> let me check other events. N-2 has been over, the mid-cycles are coming.
14:26:26 <ihrachys> amotoki: ok. please update the openstack-dev@ thread with your findings.
14:26:30 <ihrachys> amotoki: speaking of api-ref, where does https://github.com/openstack/neutron-specs/tree/master/misc/api fit in the docs story?
14:27:11 <amotoki> i think it is not linked from anywhere.
14:27:24 <amotoki> is anybody maintaining it?
14:27:25 <ihrachys> right. but it still contains some valuable info that is not found in other places.
14:27:54 <amotoki> ihrachys: agree. i think it is better to merge them into neutron-lib api-ref.
14:27:58 <ihrachys> so maybe it's worth looking at that tree to see what can be moved to a more visible place, and nuke all remainings.
14:28:19 <ihrachys> for one, that is the only place documenting sorting/pagination behaviour
14:29:01 <HenryG> +1 for merging into api-ref, assuming api-ref is flexible enough to add examples and other notes.
14:29:20 <ihrachys> amotoki: and thanks for organizing the sprint
14:29:46 <ihrachys> #topic Transition to OSC
14:30:12 <ihrachys> amotoki: how does the progress look like?
14:30:27 <amotoki> the base OSC plugin has been merged
14:30:37 <amotoki> and BGP stuff patch is under review.
14:31:14 <amotoki> I am preparing VPN stuff now to refresh my memory.
14:31:28 <amotoki> is anybody working on LBaaS stuff?
14:32:20 <ihrachys> dougwig: blogan: ^ is it on lbaas radar?
14:32:32 <ihrachys> I wonder how it plays with the plan to deprecate v2 and switch to octavia :)
14:33:32 <amotoki> same thinking too. I wonder we can implement LBaaS stuff in OSC plugin even though we switch to octavia.
14:34:07 <blogan> ihrachys: i would say its on the fringe of the lbaas radar
14:34:31 <amotoki> we can move lbaas commands later, but it is worth well coordinated.
14:35:01 <ihrachys> blogan: meaning, you are aware but better spend time for other things? :)
14:35:22 <njohnston> For FWaaS, we talked about it at the last FWaaS meeting, and there was a lot of interest in helping.  I looked at the openstack client plugin docs, but a working example would be really helpful to look at as well.
14:36:13 <ihrachys> ok, let's move on
14:36:16 <amotoki> njohnston: good to hear that. I will share my experienece on vpn stuff.
14:36:17 <ihrachys> #topic Moving to Keystone v3 API in Neutron
14:36:24 <ihrachys> dasm: your stage
14:36:25 <njohnston> amotoki: Thanks!
14:36:28 <dasm> o/
14:36:46 <dasm> HenryG prepared etherpad with list of all stadium projects that need to be updated: https://etherpad.openstack.org/p/neutron-stadium-tenant2project
14:36:59 <dasm> "updated" in terms: prepare all migrations
14:37:18 <dasm> couple of subprojects have already patches in queue. other need to be revised and sent
14:37:29 <ihrachys> dasm: does it mean they will be forced to land transition scripts to unbreak their gates?
14:37:39 <dasm> if something is missing, feel free to update.
14:38:05 <amotoki> dasm: one question. some patches in subprojects depend on the neutron patch and some do not.
14:38:07 <dasm> ihrachys: i need to confirm with HenryG and armax, how depends-on should look. But in general, everything will land in the same time, or very close timeframe
14:38:14 <amotoki> dasm: what is your suggestion?
14:38:47 <HenryG> I think we can make the neutron patch depend on the stadium patches
14:39:51 <HenryG> That will need to be followed by a cleanup of the local temporary HasTenant() functions, but it means there will be minimal breakage.
14:40:21 <amotoki> so, do we first merge all subproject patches and then merge the neutron patches?
14:40:32 <HenryG> yes, that is my suggestion
14:40:42 <ihrachys> HenryG: doesn't common_db_mixin use tenant_id field to determine permissions for a resource? in which case, landing a stadium patch before neutron would break the check for them.
14:40:44 <dasm> amotoki: yes. and at the end, clean temporary changes introduced for subprojects
14:41:31 <HenryG> ihrachys: that is covered by the sqlalchemy synonym for tenant_id/project_id.
14:42:08 <amotoki> an example is https://review.openstack.org/#/c/341279/1/neutron_lbaas/db/loadbalancer/models.py
14:42:24 <amotoki> it provides both tenant_id and project_id
14:42:56 <dasm> yes. under the hood, database has just "project_id" column, but from sqlalchemy point of view, data can be reached by both: tenant/project
14:43:25 <ihrachys> I guess we could not find a way to handle models with the actual tenant_id field.
14:43:30 <ihrachys> not a synonym
14:43:39 <dasm> ihrachys: it was suggested by zzzeek
14:44:42 <ihrachys> dasm: it == ?
14:44:55 <dasm> ihrachys: it == synonym solution.
14:46:04 <ihrachys> that's a good solution, but as we see, we still break out of tree code, so maybe we needed both the synonym and some boilercode in common_db_mixin to handle the actual tenant_id attribute. but I guess subprojects are doomed to suffer. :)
14:46:25 <ihrachys> ok, let's move on
14:46:26 <ihrachys> #topic Neutron-lib
14:46:33 <ihrachys> HenryG: where are we at with the library?
14:47:09 <HenryG> It is trundling along. Needs more reviewers.
14:47:57 <HenryG> The current big blob proposed to move into lib is common_db_mixin
14:48:18 <HenryG> https://review.openstack.org/337731
14:48:51 <HenryG> oops, wrong link
14:49:07 <HenryG> https://review.openstack.org/339875
14:50:36 <ihrachys> it's basically copy-paste from neutron right?
14:51:03 <HenryG> Yes, plus a lot of extra test cases for 100% coverage
14:51:27 <ihrachys> coverage is good. note that we basically expose db internals into the library.
14:51:50 <ihrachys> so next time we need to influence the model_query behaviour in some way, we will have a hard time to
14:52:22 <HenryG> I hope to refactor some things in it before it is consumed by neutron
14:52:42 <ihrachys> I would go as far as saying that subprojects should not be entitled to have direct access to queries, but that's probably not a widely accepted view
14:52:58 <HenryG> I would love to have that discussion
14:53:29 <ihrachys> ok, let's proceed in the review.
14:53:45 <ihrachys> everyone on the core team, please listen to your PTL and start reviewing neutron-lib as you do for neutron repo
14:54:03 <ihrachys> (and not only on the core team, everyone is encouraged)
14:54:15 <ihrachys> #topic On Demand Agenda
14:54:27 <ihrachys> I see "Feature Classification Framework/Matrix" from ankur-gupta-f on the list.
14:54:36 <ihrachys> but I thought it was discussed before, wasn't it?
14:54:42 <HenryG> We need https://review.openstack.org/337698 approved for rossella_s 's dashboard
14:54:50 <HenryG> (sorry)
14:54:57 <dasm> ihrachys it was discussed last week.
14:55:11 <dasm> ihrachys: main outcome was: more reviews :)
14:55:18 <ihrachys> dasm: ack
14:55:31 <ihrachys> HenryG: probably infra should be nudged
14:55:38 <rossella_s> indeed
14:55:46 <ihrachys> ok, I have another topic for the last 5 mins
14:56:17 <ihrachys> some weeks ago I sent an email describing the new stable process emerging in neutron: http://lists.openstack.org/pipermail/openstack-dev/2016-June/098552.html
14:56:44 <ihrachys> there were some questions/actionable items for people on the team
14:56:46 <ihrachys> there were no replies though :)
14:57:15 <ihrachys> basically, the idea is to do 'proactive backports', and get more involvement in the process from 'topic' subteams
14:57:53 <ihrachys> basically, make subteams (like qos, l3, or upgrades) to take some responsibility to provide backports for their spheres of influence
14:58:47 <ihrachys> armax also gave an idea that we should have a stable deputy role similar to bug deputy, for a person that would supervise the effort, making sure backports are produced in timely manner.
14:59:09 <ihrachys> first candidates for the role would be neutron-stable-maint members, but everyone would be encouraged to help, same as for bugs
14:59:30 <hichihara> Is it related to bug contact? http://docs.openstack.org/developer/neutron/policies/bugs.html#proposing-new-tags
14:59:58 <ihrachys> sadly, we don't have much time to reflect on that right now, so consider it an ask to read thru the email and follow up on devref updates, since we will probably run the idea in gerrit.
14:59:59 <dasm> we're running out of time
15:00:07 <amotoki> #link http://docs.openstack.org/project-team-guide/stable-branches.html#proactive-backports
15:00:14 <ihrachys> hichihara: it is not, it's a separate process.
15:00:16 <ihrachys> amotoki: thanks
15:00:22 <ihrachys> dasm: indeed.
15:00:28 <ihrachys> thanks everyone! keep up the good work!
15:00:31 <hichihara> ihrachys: I got it
15:00:31 <ihrachys> #endmeeting