14:01:14 <armax> #startmeeting networking
14:01:15 <openstack> Meeting started Tue Jul  5 14:01:14 2016 UTC and is due to finish in 60 minutes.  The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:17 <haleyb> hi
14:01:18 <hichihara> hi
14:01:18 <HenryG> o/
14:01:19 <openstack> The meeting name has been set to 'networking'
14:01:21 <hoangcx> hi
14:01:23 <annp> Hì
14:01:25 <andreas_s> hi
14:01:27 <korzen> hello
14:01:32 <john-davidge> o/
14:01:40 <blogan> hi
14:01:41 <rossella_s> hi
14:01:47 <bcafarel> howdy
14:01:52 <andy__> wow
14:01:54 <carl_baldwin> Hi
14:02:00 <amuller> hiya
14:02:07 <annp> Hi
14:02:12 <andy__> hi
14:02:12 <akamyshnikova_> hi
14:02:29 <armax> Today is national holiday for Ihar, so he won’t be joining
14:02:30 <namnh> Hi
14:02:32 <jschwarz> hello
14:02:38 <amotoki> \o
14:02:48 <armax> let’s dive in
14:03:08 <armax> The agenda, as usual
14:03:10 <armax> #link https://wiki.openstack.org/wiki/Network/Meetings
14:03:15 <armax> #topic Announcements
14:03:33 <armax> Some mid-cycles are approaching
14:03:45 <armax> for more details
14:03:47 <armax> #link https://wiki.openstack.org/wiki/Sprints#Newton_sprints
14:04:24 <armax> please sign up if you plan to attend, make sure you watch out the etherpads and contribute in the area of your interest, even if you don't
14:05:12 <armax> please be aware of the Nova FFE process
14:05:19 <armax> #link http://lists.openstack.org/pipermail/openstack-dev/2016-July/098666.html
14:05:33 <armax> if you have something in your work plan that affects
14:05:36 <armax> Noca
14:05:38 <armax> Nova
14:06:10 <armax> I strongly advise you to stay on top of the Nova’s schedule
14:08:02 <armax> Another thing I wanted to mention is this thread
14:08:04 <armax> #link http://lists.openstack.org/pipermail/openstack-dev/2016-June/097930.html
14:09:17 <armax> at one point we had gate-neutron-dsvm-functional-py34 in the check queue
14:09:32 <armax> and we demoted it to experimental because it was not working as it should have
14:09:45 <armax> if there’s anyone interested in this low hanging fruit activity
14:10:09 <armax> perhaps we can see if we can restore it and replace it with the py27 counterparts?
14:10:20 <armax> singular, counterpart
14:11:27 <HenryG> armax: I will sync up with you on that later
14:11:39 <armax> thanks HenryG
14:11:52 <armax> at the time we demoted I recall there was something wrong with the DB migrations
14:11:59 <armax> but don’t quote me on that
14:12:34 <armax> ok, enough with reminder
14:12:35 <armax> s
14:12:41 <armax> unless someone has anything to add?
14:13:16 <armax> no? Ok, moving on
14:13:29 <armax> #topic Blueprints
14:13:43 <armax> that’s our current workload
14:13:45 <armax> #link https://launchpad.net/neutron/+milestone/newton-2
14:14:07 <armax> the next milestone is in a week
14:14:10 <armax> I mean
14:14:21 <armax> N-2’s deadline is in a week-ish
14:14:30 <armax> #link http://releases.openstack.org/newton/schedule.html
14:14:59 <armax> Can I trouble the assignee/approvers of blueprints to update the whiteboard to reflect the latest status of the work you’re following?
14:15:15 <ajo> of course you can
14:15:32 <rossella_s> armax yes :)
14:15:33 <armax> please captures things outstanding, things that landed and potential blockers
14:16:08 <armax> Once the milestone is cut we can over what items can realistically land safely for Newton
14:16:15 <armax> ajo, rossella_s: thanks for the support!
14:16:44 <armax> we have currently 22 blueprints outstanding, we can probably squeeze a handful more, but only if we behave
14:17:51 <armax> ok if nobody has anything to add, let’s move on
14:17:59 <armax> but before I do
14:18:26 <armax> please remember http://status.openstack.org/reviews/
14:18:33 <armax> and the teeny tiny link at the top
14:18:40 <armax> kudos to rossella_s
14:18:53 <armax> if you wake up in the morning and you don’t know what to review
14:18:55 <rossella_s> armax thanks
14:19:06 <armax> that link helps you stay focussed and review what matters for the release
14:19:20 <HenryG> +1 rossella_s
14:19:27 <armax> not that we all have this problem, but you never know, I thought I’d better remember
14:19:34 <hichihara> I use :)
14:20:06 <armax> hichihara: good :)
14:21:07 <armax> next topic
14:21:09 <armax> #topic Bugs
14:22:17 <armax> deputy for last week was rossella_s
14:22:24 <armax> rossella_s: anything you want to share?
14:22:28 <rossella_s> I was in charge of bugs last week...it was a quiet week, nothing to report apart from https://bugs.launchpad.net/neutron/+bug/1598525
14:22:28 <openstack> Launchpad bug 1598525 in neutron "KeyError: 'processor_architecture' on ./stack.sh" [Critical,Confirmed]
14:22:39 <rossella_s> this should be fixed by infra
14:22:56 <armax> yes, that has been fixed
14:23:22 <armax> #link http://grafana.openstack.org/dashboard/db/neutron-failure-rate
14:23:32 <armax> shows that things have gone back to sanity
14:23:34 <armax> though...
14:24:17 <armax> there’s been an interesting spike lately
14:24:57 <armax> not sure if it’s related to 1598525 as I only saw it affecting the functional job
14:25:12 <armax> as far as jobs are concerned
14:25:28 <armax> please be aware of https://review.openstack.org/#/c/319770/ and
14:25:36 <armax> https://review.openstack.org/#/c/336099/
14:25:48 <armax> if you are a maintainer of a project that depends on the ovs agent
14:26:04 <armax> please make sure that the switch to native interfaces is something you’re happy with
14:26:32 <armax> I know that the switch to ovsdb caused a little hiccup to OVN
14:26:58 <armax> another potential hiccup might be caused by https://review.openstack.org/#/c/181023/
14:27:03 <armax> this is the switch to pluggable ipam
14:28:07 <rossella_s> lot's of switches :)
14:28:33 <armax> I just noticed bug 1599086
14:28:33 <openstack> bug 1599086 in neutron "Security groups: exception under load" [Critical,In progress] https://launchpad.net/bugs/1599086 - Assigned to Gary Kotton (garyk)
14:28:44 <armax> marked as critical, can someone look into it?
14:28:57 <armax> kevinbenton: ^
14:29:17 <rossella_s> armax, I had a brief look before the meeting, garyk has a patch for it
14:29:31 <armax> rossella_s: I am not sure we can blindly retry
14:29:52 <armax> rossella_s: but I don’t fully understand the failure mode
14:30:06 <rossella_s> armax, that's what I thought too...I remember a conversation with you about all these retries
14:30:41 <rossella_s> armax, me neither, I didn't have the time to look more into it
14:30:52 <armax> rossella_s: ok, thanks
14:31:20 <armax> is there anyone interested in being deputy for the week of July 18?
14:31:35 <armax> this week we’re covered by johndperkins and next week by blogan
14:31:40 <armax> kudos to both of them
14:32:13 <armax> ok, while you go and check your calendars…
14:33:15 <armax> I wanted to remind you that there’s another potential low hanging fruit activity related to bug 1552960
14:33:15 <openstack> bug 1552960 in neutron "Tempest and Neutron duplicate tests" [High,In progress] https://launchpad.net/bugs/1552960 - Assigned to Assaf Muller (amuller)
14:33:46 <armax> if anyone is interested helping moving this activity along, please reach out to amuller
14:33:53 <amuller> I will buy a beer to anyone who merges a patch related to that bug in Barca
14:34:10 <armax> and I’ll match amuller’s offer
14:34:17 <ajo> :-)
14:34:55 <armax> I’d rather see some of the patches targeting this work than some silly trivialfix for a grammar typo
14:35:05 <armax> but that’s just me
14:35:26 <armax> I should probably start -2 stuff and tell people to go and work on that instead
14:35:32 * armax has got a great idea!
14:36:07 <armax> ok, anyone for deputy the week after the next?
14:36:24 <mlavalle> armax: I'll do July 18th
14:36:30 <armax> mlavalle it is!
14:36:42 <armax> #action mlavalle bug deputy for the week of July 18th
14:36:50 <armax> mlavalle: thanks!
14:38:00 <armax> ok
14:38:01 <armax> moving on
14:38:12 <armax> #topic Docs
14:38:28 <armax> anything to bring up?
14:39:09 <armax> if not, we can dive in into the special sections of the meeting OSC and Keystone v3 respectively
14:39:24 <armax> #topic OSC
14:39:40 <amotoki> i just proposed many backports to mitaka. if you write something which can be backported to mitaka, please add 'backport: mitaka' tag to doc commit msg.
14:39:48 <amotoki> oh... OSC....
14:40:00 <armax> amotoki: that’s good too
14:40:08 <hichihara> amotoki: you are very slow
14:40:14 <armax> rtheis: ^ anything you want to add on OSC
14:40:21 <korzen> I have started some defref about hot to use objects in Neutron: https://review.openstack.org/336518
14:40:25 <armax> rtheis: is there anything the team should be aware of?
14:40:30 <rtheis> https://review.openstack.org/#/c/309587/
14:40:43 <rtheis> amotoki is working the initial plugin support
14:40:49 <amotoki> I confirmed it worked with most cases.
14:40:50 <armax> rtheis: great, thansk
14:41:00 <amotoki> without and with SSL (insecure and verify)
14:41:07 <rtheis> hopefully we can get that merged soon which opens the way for the plugins
14:41:07 <amotoki> i believe it can go.
14:41:18 <armax> amotoki: ack
14:41:46 <rtheis> Also, osc is working on an osc-lib which can be used by plugins for common functionality
14:42:21 <armax> the failures seem genuine though
14:42:22 <rtheis> as soon as it is ready, I think we'll have neutron plugin us it
14:42:28 <armax> #link http://logs.openstack.org/87/309587/7/check/gate-tempest-dsvm-neutron-src-python-neutronclient/7f533dc/logs/devstacklog.txt.gz#_2016-07-04_14_54_18_332
14:42:34 <armax> is there a missing dependency?
14:43:07 <amotoki> am looking at this
14:43:21 <armax> anyhow, good job, let’s get this pushed asap
14:43:26 <armax> a reminder for the team
14:43:46 <armax> neutronclient changes will follow the stricter requirements feature freeze
14:44:12 <armax> so if you have things that must go in the neutronclient be aware that once feature freeze kicks in you’ll have a harder time getting an exception
14:44:43 <armax> QOS folks got burned last cycle for this very reason
14:44:48 <armax> ajo: ring any bell?
14:44:58 <ajo> it does
14:44:59 <ajo> it does :)
14:45:14 <armax> ok, anything else to add?
14:45:32 <armax> amotoki, rtheis thanks for pushing this activity
14:45:47 <armax> #topic Keystone v3
14:45:50 <rtheis> yw
14:45:53 <armax> HenryG, dasm ^
14:46:02 <armax> anything worth sharing?
14:46:15 <dasm> one thing: currently i'm dealing with db migrations
14:46:19 <HenryG> dasm has the big change out for review
14:46:27 <sbelous_> is there any plan to make gate-tempest-dsvm-neutron-identity-v3-only-full-nv voting? anybody knows?
14:46:41 <amotoki> the review is https://review.openstack.org/#/c/335786/
14:46:47 <dasm> yes, and it occured that this db migration breaks a lot of other subprojects
14:46:51 <armax> sbelous_: I did not know, but I’ll look into it
14:47:12 <armax> dasm: ack
14:47:13 <HenryG> thanks for alerting to that job sbelous_
14:48:12 <armax> dasm: let’s take this offline on how to best manage the merge of this patch
14:48:23 <sbelous_> armax: thanks!
14:48:24 <dasm> armax: ok.
14:48:26 <armax> we may want to help some of the subprojects out
14:48:59 <HenryG> at least do one that the others can copy
14:49:24 <armax> dasm, HenryG do we expect that after dasm’s patch merges that no more migrations using ‘tenant_id’s are valid?
14:49:50 <HenryG> armax: I would say we can impose that rule now
14:50:00 <armax> HenryG: you mean after merge?
14:50:13 <amotoki> HenryG: does it mean we always need to use contract migrations?
14:50:41 <amotoki> HenryG: sorry. it is not true. ignore me
14:51:07 <HenryG> armax: any patches now that touch tenant_id will interfere with dasm's patch
14:51:13 <armax> HenryG: of course
14:51:19 <armax> HenryG: but that’s how it is
14:51:28 <armax> we currently have dasm’s conflicting with dasm’s patch
14:51:39 <armax> and there are others that are affected as well
14:52:26 <ajo> So it's correct to keep telling people to use project_id on API & DB layers on new patches,
14:52:30 <HenryG> most of the conflicting patches are not directly with tenant_id
14:52:34 <ajo> I'm just remembering that I'm doing that later, but that I had to check
14:52:48 <ajo> later->lately
14:53:02 <armax> ajo: if we are 99% ready to pull the trigger on the tenant->project transition yes
14:53:17 <armax> what I want to avoid is a mixed tenant/project id user experience
14:53:56 <armax> the goal would be at teh end of Newton to have one or the other
14:53:58 <armax> not both
14:54:06 <ajo> ah, ok
14:54:23 <ajo> I will keep that in mind while reviewing
14:54:43 <armax> I imagine we may want to enforce a mini-freeze while we handle dasm’s patches
14:54:58 <HenryG> armax: yup
14:55:10 <armax> I’ll sit down with HenryG to figure out a plan and share it with the core review team
14:55:23 <armax> so that we know which patches to block/defer/rebase
14:56:28 <ajo> makes sense
14:57:17 <hichihara> I hope that the mini-freeze is very short so that it doesn't interrupt our development
14:57:25 <siam0ss> Hi
14:57:26 <amotoki> sounds reasonable. I think API patch will come after that.
14:58:01 <amotoki> i think it can lead to more discussion.
14:58:14 <armax> amotoki: or before, depending on how quickly we can whip dasm’s patch into shape
14:58:28 <dasm> amotoki: that's the plan to tackle api after db. but we can discuss this later.
14:58:48 <armax> oh hang on I misunderstood
14:59:06 <hichihara> 1min
14:59:18 <armax> amotoki: what API patch(es) are you talking about?
14:59:43 <amotoki> armax: what in my mind is a patch which accepts project_id.
14:59:49 <amotoki> am i missing it?
14:59:56 <armax> amotoki: right
14:59:58 <armax> ok
15:00:07 <armax> I am with you
15:00:25 <armax> we’ll have to adapt the API layer to handle both tenant and project id too
15:00:27 <HenryG> Time. Let's switch to the neutron channel.
15:00:29 <amotoki> i try my best on the series of reviews.
15:00:35 <armax> #endmeeting