14:01:15 <ihrachys> #startmeeting networking
14:01:16 <jschwarz> ihrachys, yeah!
14:01:16 <openstack> Meeting started Tue Mar 29 14:01:15 2016 UTC and is due to finish in 60 minutes.  The chair is ihrachys. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:18 <dasm> o/
14:01:19 <openstack> The meeting name has been set to 'networking'
14:01:20 <johnsom> o/
14:01:23 <rossella_s> hi :)
14:01:24 <njohnston> o/
14:01:28 <ihrachys> hi everyone! :)
14:01:29 <hoangcx> hi :0
14:01:30 <haleyb> hi
14:01:34 <korzen> \o
14:01:36 <HenryG> o/
14:01:38 <aimeeU> hi :0
14:01:38 <njohnston> Hi, Dr. Nick!
14:01:41 <xgerman> O/
14:02:07 <yamahata> hi
14:02:11 <sridharg> hi
14:02:21 * ihrachys notes good representation this time :)
14:02:23 <ihrachys> #topic Announcements
14:02:48 <ihrachys> first thing first... there was a time zone switch this weekend in some parts of the world
14:02:59 <ihrachys> make sure your meeting times are set using UTC :)
14:03:10 <dasm> ihrachys: and two weeks ago in other parts ;)
14:03:22 * jschwarz is glad he got this meeting right on the first try
14:03:28 <ihrachys> dasm: right. people like when it's complex.
14:03:36 <akamyshnikova> hi
14:03:40 <sbelous_> hi
14:03:52 * ihrachys waves those who join
14:03:54 <ihrachys> now, let's look at what we have for Mitaka
14:04:00 <pc_m> hi
14:04:04 <ihrachys> 1. RC2 is tagged:
14:04:05 <ihrachys> #link https://review.openstack.org/#/c/295398/
14:04:26 <ihrachys> unless something really bad is spotted in Mitaka, this will be our final
14:04:44 <amuller> Quite an accomplishment :)
14:04:45 <ihrachys> atm we are not aware of anything that would require another RC
14:04:54 <ihrachys> but if you do, you should yell right now
14:05:41 <ihrachys> now, as you probably know, there is a new process to track feature deliverables for Mitaka called 'post mortem'
14:05:43 <ihrachys> #link https://review.openstack.org/#/c/286413/
14:06:02 <ihrachys> your glorious PTL kindly asks everyone involved to get thru the list again and fill in gaps if any
14:06:50 <ihrachys> if all goes right, RC2 is the final, and we will celebrate the git hashes; and Armando will be able to have some rest.
14:07:07 <ihrachys> that said, not for long!
14:07:30 <ihrachys> for Newton, we have schedule posted:
14:07:31 <ihrachys> #link http://releases.openstack.org/newton/schedule.html
14:07:49 * ihrachys kindly suggest to check whether it makes sense for us
14:08:49 <reedip__> So next week is the final release , lucky number 13...
14:09:06 <ihrachys> heh
14:09:21 <ihrachys> since master is now open for Newton, please rush to propose your new cool features for Newton :)
14:09:37 <ihrachys> note that there are some tweaks for the RFE process made for Newton:
14:09:39 <ihrachys> #link https://review.openstack.org/#/c/296120/
14:10:04 <dasm> ihrachys: big refactor for tenant_id->project_id is retargeted for Newton \o/
14:10:27 <ihrachys> specifically, now every RFE will have a blueprint posted [even if a stub], and an approver from the active team members will be assigned to those features approved by drivers team.
14:11:22 <ihrachys> the goal is to make sure that all RFEs have dedicated reviewers assigned that will be responsible for working with implementers to get it in
14:11:38 <HenryG> Also note that our fearless PTL has declared that "Stability is the priority" for Newton. That probably means less features will be approved this time.
14:12:12 * njohnston is wondering if this spec can merge now, since the code implementing it has already merged?  https://review.openstack.org/#/c/190285/
14:12:15 <ihrachys> I approve this message ^
14:12:15 <ihrachys> :-)
14:12:36 <ihrachys> njohnston: yes. we'll get back to it in next weeks.
14:12:45 <hichihara> Who are "active team members"?
14:12:45 <ihrachys> should be a no-issue
14:13:01 <hichihara> Does it mean core team?
14:13:05 <njohnston> OK, I wasn't sure if there was a freeze that would thaw on neutron-specs at a particular point in time.
14:13:28 <ihrachys> hichihara: I don't think there is strict definition, but the group definitely includes core reviewers plus some more seasoned folks.
14:13:54 <hichihara> ihrachys: I got it. Thanks.
14:13:54 <ihrachys> hichihara: the main point in having an approver is to make someone care about review velocity on daily/weekly basis
14:13:57 <reedip__> What about the status of neutronclient ??
14:14:31 <ihrachys> hichihara: in theory, if someone is active but is not core, and the person pulls proper reviewers into patches and makes sure the process is smooth, then it can be any person.
14:14:34 <reedip__> not to play a spoiltsport, but it seems there are several reviews open there, for a long time now ...
14:14:40 <ihrachys> reedip__: elaborate?
14:14:51 <amotoki> reedip__: what do you mean?
14:15:11 <hichihara> ihrachys: make sense
14:15:18 <amotoki> we maintain neutronclient (CLI side) until OSC has feature compat and after that we maintain library side.
14:15:55 <ihrachys> reedip: are they critical, or they may wait until reviewers get to them?
14:16:33 <reedip__> ihrachys : not all of them, but I have been trying to get the focus of reviewers on one of the item , but failed to do so ...
14:16:51 <reedip__> If this is the right forum, then I can bring it up now...
14:17:02 <ihrachys> in ideal world, all patches will get immediate response. in reality, reviewers need to prioritize, so it's not uncommon to leave some patches off the plate for some time, especially when everyone deals with release stuff.
14:17:26 <ihrachys> reedip__: let's discuss it in #openstack-neutron channel after the meeting.
14:17:37 <reedip__> okay , got it ihrachys
14:17:43 <ihrachys> ok, one more thing to note while we are in the announcement section
14:17:57 <ihrachys> Armando started to collect ideas for the design sessions we'll have
14:18:05 <ihrachys> #link https://etherpad.openstack.org/p/newton-neutron-summit-ideas
14:18:24 <ihrachys> he will work on crafting some draft schedule for Neutron this week
14:18:45 <ihrachys> I suggest you update the etherpad with your ideas, if you have some and if you haven't already done it.
14:18:59 <amuller> The number of suggestions is surprisingly low
14:19:23 <amuller> Where is everyone's ideas?
14:19:28 <amuller> Now's your time!
14:19:51 <ihrachys> that's a good marketing pitch
14:20:15 <ihrachys> so... do as Assaf told ^ he is a wise guy :)
14:20:39 <ihrachys> I think that's it for announcements. anyone else having another announcement to make?
14:21:05 <ihrachys> ok, moving on
14:21:15 <ihrachys> #topic Bugs
14:21:34 <HenryG> Very quiet week on bugs
14:21:48 <HenryG> Only one worth mentioning
14:21:55 <HenryG> It showed up last night
14:22:05 <HenryG> Bug 1563028
14:22:05 <openstack> bug 1563028 in Trove "Routes version 2.3 broke the way we register routes" [Critical,In progress] https://launchpad.net/bugs/1563028 - Assigned to Amrith (amrith)
14:22:22 <HenryG> Affects Neutron too
14:22:24 <ihrachys> HenryG: we are guarded with constraints, right?
14:22:35 <amuller> ihrachys: yeah
14:22:37 <HenryG> ihrachys: yes, but for how long?
14:22:43 <amuller> HenryG: Do we have a process for detecting stuff like this?
14:22:58 <amuller> I mean, how was that bug noticed?
14:23:03 <HenryG> amuller: I don't know
14:23:04 <amuller> was it just a manual / chance thing?
14:23:06 <ihrachys> amuller: the gate for upper constraints file update, which is in requirements repo
14:23:18 <amotoki> I think g-r change detects it hopefully
14:23:36 <amuller> ihrachys: when we try to apply the version bump to neutron, or in the global requirements repo change?
14:23:38 <amotoki> I mean g-r change jenkins check, but it does not cover all.
14:23:41 <ihrachys> as long as there is a job in their gate to catch it, it should trigger the failure.
14:23:57 <ihrachys> amuller: upper constraints are managed in single place - in requirements repo
14:23:58 <HenryG> Anyway, the fix is easy if someone wants to take it. Just do like the Trove fix.
14:24:00 <amuller> ihrachys: if we're only detecting this via the g-r repo CI then we obviously have a huge hole there
14:24:15 <ihrachys> amuller: once the bump lands there, it immediately applies to all projects
14:24:53 <ihrachys> amuller: there is no hole. the idea is that we should add more specific jobs to g-r gate for constraints file if current list is not enough to catch something.
14:24:55 <amuller> ihrachys: right since our tox.ini just picks up the reqs from global repo
14:25:23 <amuller> ihrachys: so the vision is to add dozens of jobs to g-r repo? Doesn't seem like a scalable approach =D
14:25:37 <ihrachys> amuller: only 'representative' list of those jobs.
14:25:48 <ihrachys> amuller: and to trigger them only for constraints bumps
14:26:15 <ihrachys> obviously, sometimes the mechanism will fail, which will indicate the need to expand the coverage for one of those jobs, or add a new one.
14:26:23 * amuller nods
14:26:58 <ihrachys> no silver bullet. but it's worth checking whether the Routes bug we started discussion from is indeed triggered in the g-r gate
14:27:17 <amotoki> at least we can avoid a situation where all fails
14:27:37 * HenryG sees Cedric has assigned himself the bug
14:27:39 <amuller> amotoki: Of course this is much better than before we had upper constraints :)
14:28:19 <ihrachys> right. without constraints, we would currently run in fire drill mode trying to manage gate casualties
14:28:55 <ihrachys> HenryG: thanks for the update and taking on the job.
14:29:01 <ihrachys> this week amotoki is the deputy
14:29:13 <amotoki> yeah
14:29:17 <ihrachys> we need a volunteer for the next week Apr4-
14:29:25 <ihrachys> anyone?
14:29:42 * ihrachys notes that it's not necessarily a core reviewer
14:29:44 <dasm> ihrachys: i thought we're replaying all deputies
14:29:54 <ihrachys> dasm: replaying == ?
14:30:05 <dasm> starting from beginning of list of deputies
14:30:07 <HenryG> recycling?
14:30:15 <ihrachys> :D
14:30:15 <ihrachys> no, it did not happen
14:30:25 <reedip__> ihrachys: I can try ...
14:30:29 <dasm> HenryG: recycling won't work. everything will be scratched :)
14:30:54 <dasm> reedip__: ++
14:30:55 <ihrachys> reedip__: ok great. please sync with me or armax or amotoki on the process.
14:31:02 <hichihara> reedip__: Cool
14:31:05 <HenryG> Go reedip__ !!
14:31:06 <reedip__> ihrachys : yes, I will
14:31:08 <ihrachys> reedip++
14:31:15 <ihrachys> WOOHOO
14:31:29 <ihrachys> ok, I am back from excitement
14:31:47 <ihrachys> one more thing to cover in the Bugs section before we move on
14:32:15 <ihrachys> our tremendous PTL would like us to become more aware of what's going on with the gate
14:32:27 <ihrachys> we have lots of jobs in check queue, lots of them non-voting
14:32:33 <ihrachys> often times they are failing
14:32:57 <ihrachys> with no clear understanding of when they will get in better shape to allow enabling votes for them
14:33:08 <ihrachys> (which is the supposed end goal for any job added to the check queue)
14:33:35 <ihrachys> #link http://grafana.openstack.org/dashboard/db/neutron-failure-rate?panelId=5&fullscreen
14:34:01 <ihrachys> that's one of the dashboards that show sad state for some jobs we have
14:34:15 <ihrachys> fullstack is 50% failure rate :-|
14:34:24 <ihrachys> functional is at 15%
14:34:46 <HenryG> fullstack fixes are in queue
14:34:57 <dasm> HenryG: link?
14:35:02 <ihrachys> HenryG: hopefully yes
14:35:18 <hichihara> fullstack is OK for me because of non-voting but functional test is bad ;)
14:35:31 <HenryG> I agree functional is worrysome
14:35:38 <ihrachys> we will need to have specific people assigned to jobs we have to provide reports about gate state
14:35:58 <ihrachys> one idea is e.g. to have bug deputy provide that kind of report. or that will be another role for that.
14:36:07 <ihrachys> the main point is obviously not the report itself
14:36:18 <ihrachys> but getting traction and actual fixes in, and getting jobs voting
14:36:39 <HenryG> dasm: the main one is https://review.openstack.org/298056
14:36:45 <ihrachys> if the community CANNOT manage the number of jobs, we may need to discontinue some of them.
14:36:52 <dasm> HenryG: thx
14:36:53 <ihrachys> which would be a sad story for everyone
14:37:16 <njohnston> +1 to having another role, someone to provide long term oversight and who can recognize patterns, which is a very specific set of eqpertise you have to work at
14:37:24 <njohnston> expertise
14:37:24 <HenryG> I need to check the PG job and see if we can make it voting again
14:37:37 <dasm> njohnston: ++
14:37:53 <ihrachys> so I encourage folks that have jobs for their respective components/features/jobs to take another look on the set we have and make visible progress there
14:38:21 <ihrachys> it is probably in line with the vision that PTL has for the release to be more focused on code stabilization than new features.
14:38:43 <hichihara> The role needs infra, devstack, tempest, neutron, and so on. not easy.
14:39:33 <ihrachys> I am not actually sure the role should cover the deep dive into logs. even making the team aware about current pain points and stabilization patches up for review would make a huge difference.
14:40:07 <amotoki> the role can raise stability problem at least
14:40:07 <ihrachys> anyhow, I will leave it up to PTL to cover the details. I think Armando should come up with some specific proposal to get us back on track with the gate.
14:40:13 <amotoki> it is very good start
14:41:23 <ihrachys> amotoki: right. even someone who merely notifies e.g. dvr or linuxbridge folks about their job starting to misbehave 'this Monday' would help us a lot to manage problems in due manner.
14:41:55 <amotoki> indeed
14:42:28 <ihrachys> ok, let's move on
14:42:29 <ihrachys> #topic Docs
14:42:45 <ihrachys> I don't see Sam-I-Am around. prolly may need to skip the section.
14:43:15 <ihrachys> #topic Open Agenda
14:43:41 <ihrachys> I don't see any specific topics in the agenda
14:43:57 <ihrachys> ok, then I will just throw my itch here :)
14:43:59 <ihrachys> #link http://lists.openstack.org/pipermail/openstack-dev/2016-March/090235.html
14:44:18 <ihrachys> as some of you probably know, we ran proactive backporting effort during Mitaka dev cycle
14:44:39 <ihrachys> we basically backported a lot of fixes to stable branches in a more systemic way
14:44:56 <ihrachys> that said, we have not seen enough diversity in contributions
14:45:17 <ihrachys> I *hope* that stable branches are of interest to different groups in the community
14:46:02 <ihrachys> so I encourage those folks to read the link and get involved in the process. in the end, it helps everyone who relies on stable branches (which, I suspect, is 80%+ of users we have)
14:46:06 <haleyb> yes, especially the dvr fixes :)
14:46:45 <ihrachys> haleyb: especially dvr: fixes are often times quite twisted and require domain knowledge from those who work actively on the feature.
14:47:16 <haleyb> ihrachys: i will look at the l3/dvr fixes, i have the page up somewhere
14:47:17 <ihrachys> it would be cool to see more active contributors to master to spend some cycles on delivering fixes to users thru stable pipeline.
14:47:27 <haleyb> for backports
14:47:30 <ihrachys> haleyb: thanks!
14:47:32 <ihrachys> #link https://etherpad.openstack.org/p/stable-bug-candidates-from-master
14:47:50 <ihrachys> ^ that's the etherpad where we currently manage the list of work items for potential backports.
14:48:01 <amotoki> as you may know, when you are involved in the stabler branches, please read the stable branch policy!
14:48:28 <ihrachys> yeah, right. it's linked in the etherpad, but just in case:
14:48:30 <amotoki> especially http://docs.openstack.org/project-team-guide/stable-branches.html#appropriate-fixes
14:48:37 <ihrachys> #link http://docs.openstack.org/project-team-guide/stable-branches.html
14:49:07 <ihrachys> ok, I made my pitch :)
14:49:16 <ihrachys> anyone else with something for the open agenda/
14:49:16 <ihrachys> ?
14:49:25 <electrocucaracha> ihrachys: I noticed that you have serveral references to a tool that you uses some get some data.  I'm wondering where is that tool
14:49:46 <ihrachys> electrocucaracha: oh that's actually still in review but:
14:49:49 <ihrachys> #link https://review.openstack.org/#/q/project:openstack-infra/release-tools+owner:%22Ihar+Hrachyshka+%253Cihrachys%2540redhat.com%253E%22
14:50:20 <electrocucaracha> got it, thanks
14:50:25 <ihrachys> I will post more tools for the process in the next weeks.
14:50:55 <ihrachys> ok, I guess we can call it a day. thanks everyone for joining the meeting!
14:51:01 <ihrachys> #endmeeting