21:00:12 <armax> #startmeeting networking
21:00:12 <openstack> Meeting started Mon Nov  9 21:00:12 2015 UTC and is due to finish in 60 minutes.  The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:16 <openstack> The meeting name has been set to 'networking'
21:00:23 <xgerman> o/
21:00:29 <armax> welcome to the first Neutron meeting after the summit
21:00:30 <markmcclain> o/
21:00:30 <ajo> \o
21:00:37 <armax> I bet some of you were off last week
21:00:44 <armax> I certainly was
21:00:56 <haleyb> hi
21:01:01 <armax> and I appreciate whoever held the fortress while I was gone
21:01:02 <kevinbenton> Hi
21:01:08 <sc68cal> o/
21:01:08 <russellb> hi
21:01:17 <emagana> hello
21:01:18 <mlavalle> hi
21:01:35 <armax> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
21:01:35 <HenryG> o/
21:01:47 <armax> agenda looks thin…but appearances can be deceiving
21:02:07 <armax> #topic Announcements
21:02:24 <armax> the most prominent one is an update on the way we track release notes
21:02:45 <armax> if you are not familiar with it, please have a look at the following
21:02:47 <armax> #link  http://lists.openstack.org/pipermail/openstack-dev/2015-November/078301.html
21:02:56 * ajo looks
21:02:57 <johnsom_> o/
21:03:11 <kevinbenton> TCP Reno
21:03:34 <armax> mestery, being our release liason
21:03:37 <garyk> does that change the way that we use UpgradeImpact flags etc in commit messages?
21:03:40 <armax> has been on top of the new process
21:03:44 <armax> with a few patches
21:03:44 <njohnston> o/
21:03:45 <armax> #link https://review.openstack.org/#/q/owner:mestery+topic:add-reno,n,z
21:03:55 <blogan> \o/
21:03:57 <armax> garyk: I wouldn’t think so
21:03:57 <russellb> in short, update release notes as a part of patches that justify release notes?
21:03:59 <russellb> sounds nice.
21:04:12 <ihrachys> pretty cool
21:04:19 <armax> another one pending
21:04:23 <armax> #link https://review.openstack.org/#/c/242223/
21:04:42 <armax> so bottom line: we’re moving away from capturing the notes in the wiki
21:04:55 <carl_baldwin> ++
21:05:01 <armax> this is the superslim TL;DR
21:05:03 <njohnston> ++
21:05:32 <ajo> nice
21:05:39 <armax> it’s worth noting that to my knowledge the overarching openstack release team will be moving away from looking at Launchpad for blueprints
21:05:46 <armax> when it comes release time
21:06:24 <Arkady_Kanevsky> hello
21:06:25 <armax> it’s also my understanding that each project is still free to use LP as they see fit
21:06:38 <Arkady_Kanevsky> correct phone bridge - 1-888-875-9370,,3;9518007#
21:06:42 <pc_m> What about RN for adv svcs?
21:06:48 <armax> as some of you are aware, we have a few processes in place
21:06:49 <russellb> Arkady_Kanevsky: i think you're in the wrong channel
21:06:56 <armax> Arkady_Kanevsky: you might be in the wrong channel
21:07:09 <xgerman> +1
21:07:18 <armax> #link http://docs.openstack.org/developer/neutron/policies/blueprints.html#blueprints-and-specs
21:07:41 <armax> we use Launchpad to track features via RFE bugs mostly
21:07:58 <armax> pc_m: they are tracked in the neutron repo
21:08:30 <armax> pc_m: but I’ll double check
21:08:51 <pc_m> armax: So commit in svc repo and then in neutron for RN.
21:08:55 <armax> pc_m: it general the rule of thumb is: if you got deliverables, then you might want to have release notes
21:09:18 <armax> pc_m: adv-svcs is sorta borderline
21:09:34 <russellb> they're included in the "neutron" deliverable, governance wise
21:09:41 <armax> russellb: correct
21:09:58 <armax> so do not intend deliverable as strickly as a package
21:10:54 <armax> bear also in mind that from now on, Launchpad blueprints are going to be used to track high-visible bug RFE’s
21:11:18 <armax> I have been cleaning up the blueprint slate for a while, and I’ll continue to do so
21:11:23 <armax> any question?
21:11:28 <dougwig> then why file them as rfe's?
21:11:39 <dougwig> should we tweak the process to just file bp's instead?
21:11:54 <armax> dougwig: no, because...
21:12:01 <russellb> no, i think there should be a 4th place to file a feature, before you actually get to code
21:12:04 <armax> dougwig: bug reports allow us to have a nice conversation
21:12:14 <armax> dougwig: which the BP page doesn't
21:12:41 <ajo> I guess blueprints can be ok for more complex deliverables
21:12:44 <armax> dougwig: honestly this is all done mostly to overcome the limitations of LP as a tool
21:12:53 <dougwig> armax: wow, that's some broken tooling, but i don't want to derail "announcements".
21:12:57 <dougwig> jinx
21:13:03 <ajo> :)
21:13:07 <armax> dougwig: this is old news
21:13:15 <armax> dougwig: we all know that LP is ‘broken’
21:13:17 <armax> btw
21:13:24 <armax> this is all black on white here:
21:13:25 <armax> #link http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements
21:13:38 <dougwig> those of us who avoid it except when necessary (i.e. everyone except the PTL) don't always think of these warts.
21:13:47 <armax> if something is not clear, needs to be rephrased, the usual way to address this is to file a patch
21:14:56 <armax> any more questions/time on this announcement?
21:16:09 <armax> I wanted to mention, that I will follow up this week with a few emails, in relation to the summit aftermath and the ramping up of Mitaka
21:16:45 <armax> I’ll tag them with “”Mitaka Release””, so stay tuned
21:17:17 <armax> this brings me to the next topic
21:17:27 <armax> #topic Blueprints
21:17:48 <armax> we are in the first milestone of the realease
21:17:49 <armax> #link https://launchpad.net/neutron/+milestone/mitaka-1
21:17:57 <armax> this ends on Dec 1st
21:18:12 <armax> or thereabouts
21:18:14 <armax> #link https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
21:18:33 <russellb> that looks aggressive
21:18:43 <xgerman> +1
21:18:44 <dougwig> wow, renaming tenant_id by 12/1?  scary.
21:18:46 <armax> russellb: yes, we are only a few weeks away
21:18:56 <russellb> or is everything just targeted at mitaka-1 for now?
21:19:00 <russellb> looks like it
21:19:05 <armax> this is mostly targeting liberty backlog
21:19:07 <russellb> ok
21:19:19 <russellb> so, need to shake out what's expected to land now vs some future point
21:19:45 <ihrachys> for rename, not sure we can do it everywhere. I remember oslo.context actually uses 'old' terms due to compat reasons.
21:19:45 <armax> there are a couple of ways in which we can look at this
21:20:04 <armax> ihrachys: as for the rename, someone will have to look into it
21:20:15 <armax> m-1 may be just scoping, actual definiton of work
21:20:17 <ihrachys> not sure why essential
21:20:44 <dougwig> ihrachys: i'm sure a backwards compat shim/member of some sort will have to be in place anyway.
21:20:51 <dougwig> but i'm off topic.
21:21:10 <armax> ihrachys: most projects have swiched already, we can discuss the priority offline though
21:21:25 <ZZelle_> armax, does it affects only neutron internals or also neutron APIs?
21:21:37 <garyk> yeah, the api's are the main concern
21:21:40 <ajo> ans neutron-client
21:21:43 <ajo> ans->and
21:21:48 <garyk> that needs to be backwards compat etc.
21:21:50 <armax> ZZelle_: if it were for the internals I wouldn’t care so much
21:21:56 <ajo> garyk : +1
21:22:05 <armax> ZZelle_: we’ll have to look at how the other projects have handled it
21:22:13 <garyk> we can let russellb take care of the nova changes :)
21:22:18 <garyk> that can and will take eons
21:22:23 <dougwig> if it's just the api, it's easy, make it accept both and write one. it's all the subprojects that i worry about more.
21:22:41 <blogan> indeed
21:22:51 <kevinbenton> dougwig: it needs to return both as well
21:22:53 <armax> dougwig: right, the work requires some planning
21:22:58 <garyk> dougwig: can you please elobarate
21:23:35 <garyk> are you referring to lbaas etc or the decoupled ones?
21:23:49 <dougwig> garyk: which part?  the rest api needs to take either, and as kevin said, likely needs to return both.  for anyone importing neutron models, i expect we'll want to put in a tenant_id method that fetches project id, or chaos will ensue.
21:24:04 <amuller> I have to say for an 'essential' level blueprint the 'why' part is really lacking
21:24:06 <armax> we should take this offline, as there’s clearly some very involved work required
21:24:13 <dougwig> armax: +1
21:24:29 <armax> amuller: the work needs an owner
21:24:33 <garyk> dougwig: i wamted to hear about your concerns for the subprojects
21:24:56 <dougwig> garyk: they import neutron, and grep -r misses those refs.
21:25:03 <armax> amuller: keystone v2 is going away
21:25:07 <garyk> ok, understood
21:25:17 <ajo> armax, that's a good reason
21:25:47 <amuller> I hope they had an amazing reason to make backward incompatible changes in the keystone api
21:26:02 <amuller> because this is a huge waste of time IMO
21:26:11 <armax> amuller: not sure talking about this here is going to make a difference
21:26:16 <amuller> ya just ranting
21:26:26 <armax> amuller: it might not even be as bad as it sounds
21:26:39 <kevinbenton> up next: splitting the scheduler out of nova ;)
21:26:41 <armax> amuller: all I have done flagging it was to make sure we have someone looking into it
21:26:58 <sc68cal> kevinbenton: lol
21:27:02 <armax> and tell us what needs to get done, so that we don’t embarass ourselves
21:27:07 <amuller> kevinbenton: don't forget adding a migration script from nova network
21:27:18 <russellb> amuller: they did not, but that ship sailed years ago
21:29:38 <armax> to answer the question about the planning, we could target every work item to the ongoing milestone and let stuff roll over that hasn’t completed.
21:30:03 <armax> being careful we don’t oversubscribe ourselves too much
21:30:31 <armax> one might argue that just the stuff targeting M1 might be enough for the entire release
21:30:38 <russellb> looks like it could be :)
21:30:52 <dougwig> it looks like more than a release, given our history
21:31:05 <armax> but if one drills down and see that some stuff has nearly complete the picture is not as bad
21:31:08 <russellb> some of this won't make it, some unexpected other stuff will
21:31:19 <armax> that said, we gotta figure out a better way to track progress of each individual effort
21:31:57 <armax> I have been mulling over a few options
21:32:10 <armax> and I am going to share my proposal with you with those emails I mentioned before
21:32:15 <armax> proposal/s
21:32:56 <armax> this is mostly because when we look at a BP I can’t never figure out for the life of me whether it’s complete or not
21:33:02 <armax> even if we claim that it is
21:33:15 <armax> anyhoo
21:33:21 <ajo> makes sense
21:33:29 <ajo> LP is very limited on that
21:33:48 <armax> as for this very meeting
21:34:12 <armax> we should probably get going to the next section
21:34:26 <armax> anyone else wants to add anything else before we move on?
21:35:01 <armax> going once, going twice, ...
21:35:18 <kevinbenton> 1+1
21:35:20 <armax> #topic Bugs
21:35:22 <russellb> ==2
21:35:55 <armax> so here we haven’t meet for the past 2 weeks
21:36:31 <armax> this week’s deputy is ajo
21:36:49 <armax> ajo: thanks for joining at this late hour for you
21:37:00 <ajo> Correct, I started triaging this afternoon
21:37:07 <ajo> and I'm still on it,
21:37:18 <armax> during the past few weeks numbers have kept on growing
21:37:36 <armax> we are now at ~257 bugs filed since Mitaka started
21:37:55 <ihrachys> sounds insane
21:38:16 <armax> ihrachys: I need to provide the breakdown for RFE’s
21:38:23 <ajo> happy, to join, sometimes it's others early morning..
21:38:29 <ajo> yes, sounds like a lot
21:38:47 <armax> ihrachys: but unless my scripts are totally busted, that’s what we got so far
21:38:50 <garyk> ajo: i can help out tomorrow morning
21:39:07 <armax> ajo: anything newsworthy?
21:40:00 <ajo> armax: nothing that sounded extreme, I saw a bug about instances not being able to do TCP connections when on the same host, but different network
21:40:03 <armax> garyk: we have a tag ‘needs-attention’ that we use
21:40:18 <ajo> I think kevinbenton nailed it down to the user running a non-liberty version,
21:40:19 <armax> garyk: in order to help back-to-back deputies coordinate the screening process
21:40:47 <garyk> ok
21:41:01 <ihrachys> ajo: note we support other releases too
21:41:19 <ajo> ihrachys , of course, we suggested him to explain which version he was running on, and
21:41:27 <ajo> ihrachys , to test an specific patch to confirm if that fixes it
21:41:41 <ajo> kevinbenton did, in fact, I just asked for the version
21:41:58 <ajo> armax, when do we exactly use "needs-attention" ?
21:42:01 <armax> yes, deputies, don’t be shy to mark incomple any bug report that doesn’t provide enough information
21:42:28 <ajo> armax : ack
21:43:14 <armax> ajo: I use it to mark bugs that may need an extra pair(s) of eyes
21:43:37 <dougwig> is there a bug deputy manual? because i won't remember all these tidbits when my turn rolls around.
21:43:46 <ajo> armax: ok, I'll use when I don't know who to send it to.
21:43:49 <armax> dougwig: http://docs.openstack.org/developer/neutron/policies/bugs.html
21:44:11 <armax> dougwig: I am surprised this question come from you :)
21:44:56 <dougwig> i knew about those docs, i meant something finer grained.  tags in common use, common criteria for triage, etc.
21:45:20 <armax> dougwig: but yes, these things are easy to forget
21:45:23 <dougwig> needs-attention is new, and i will likely forget about it, e.g.  maybe it's just me and my terrible memory.
21:45:48 <armax> dougwig: it’s in that link above, more can be added to further clarify the usage
21:46:02 <armax> dougwig: or even remove it if we start realizing that it’s not that usefucl
21:46:04 <armax> useful
21:46:20 <dougwig> whoa, indeed, i guess i had never read that far.
21:46:31 <armax> I initially thought about it as a way to have people swarm around a specific issue
21:46:31 * dougwig hides in shame.
21:46:45 <armax> rather that have them randomly wander around LP
21:49:05 <armax> ajo: anything more on bugs?
21:49:23 <ajo> nothing outstanding sorry for not having a sound report for the meeting, it seems that today it was a local holiday and I got dragged out home until now -2h
21:49:45 <armax> ajo: no worries, we’ll ramp up after the slow weeks pre-during-post summit
21:49:50 <ajo> I will ping the right people if I find something serious, but I didn't find anything serious "enough" yet, just things that we need to fix, and incomplete reports
21:50:07 <armax> emagana: ping on docs?
21:50:10 <armax> #topic Docs
21:50:18 <emagana> Hi!
21:50:25 <armax> Hi
21:50:31 <emagana> We did not have meeting last week, so nothign from me this week
21:50:38 <armax> ok cool, tnx
21:50:39 <emagana> I will report next week
21:50:50 <armax> #topic Open Discussion
21:51:09 <armax> we got 10 minutes to go over some of the topics proposed in teh on demand agenda
21:51:19 <kakuma> Hi armax, the ryu team announced about ofagent deprication in ML.
21:51:23 <armax> top of the pile is pc_m’s request
21:51:29 <armax> Decision on whether advanced services functional tests should run on Neutron commits - to reduce the change of cross-project breakage. (pc_m)
21:51:38 <kakuma> We believe it is added to a release note in mitaka. Is this ok?
21:51:44 <armax> kakuma: please wait your turn
21:51:51 <pc_m> armax: That was from last meeting.
21:52:03 <armax> pc_m: but we didn’t seem to have reached any consensus :)
21:52:35 <armax> pc_m: a few of us have a lengthy discussion(s) at the summit
21:52:39 <armax> dougwig: hint hint
21:52:40 <pc_m> armax: Talked to Doug at summit. Plan was to first modify existing jobs to use a single template (to clean up).
21:53:04 <dougwig> sigh.  :)
21:53:09 <pc_m> armax: We could then add one of the jobs to Neutron, if desired. I'd suggest the strongswan one.
21:53:18 <kakuma> sorry
21:53:26 <armax> pc_m: a single template just for vpnaas?
21:53:29 <amuller> where do we draw the line and why? there's what, we have the 3 advanced services, but the networking-foo projects are kinda in the same boat no?
21:53:33 <dougwig> armax had the idea of moving the adv.services (and other semi-related neutron jobs) to the post-merge queue, so reduce gate breakage and check queue time.
21:53:37 <armax> amuller: yes
21:53:53 <dougwig> in the meantime, lbaas jobs have been removed from the gate, as check queue coverage covers 99.9% of what i'm worried about.
21:53:56 <amuller> and there's like 4,000 networking-foo projects, I think infra will be... chaffed
21:54:28 <garyk> amuller: body fglie
21:54:32 <garyk> body glide
21:54:45 <armax> so the idea so far is the following
21:55:06 <dougwig> i'm totally cool with not *gating* on some of these related jobs.  i think the question is whether we put those jobs into neutron's check queue, or some other build queue (post-merge, periodic, etc)
21:55:38 <armax> all projects will eventually need to depend on neutron-lib
21:55:44 <sc68cal> I'd be happy with neutron-fwaas in the check queue, but not gating
21:55:57 <armax> and we can check/gate all neutron projects on that one
21:56:03 <amuller> if we're concerned about infra resources then putting something in the check queue is the worst case
21:56:15 <armax> in the intermin we move jobs to the post-merge queue
21:56:26 <amuller> post-merge as armax is saying is a lower level of magnitude
21:56:38 <armax> and if we see that it goes on fire quickly we’ll revise the decision
21:56:46 <dougwig> amuller: i've been told by infra that we shouldn't be debating the use of infra resources, they should be. at present, they have no directives as to quantity of check jobs.
21:56:55 <armax> in the meantime we’ll have to ramp up on neutron-lib quickly
21:57:16 <armax> it’s not a matter of resources
21:57:17 <salv-orlando> plan makes sense to me
21:57:26 <ajo> ++
21:57:32 <amuller> dougwig: That may be, but I happened to be present in one of the infra design sessions (The one about multinode testing) and they were saying that they're above capacity currently
21:57:33 <armax> it’s a matter of defining a process that scales sensibly
21:57:36 <salv-orlando> also as armax says you can revise and/or revert at any time
21:57:40 <garyk> armax: that should be one of the BP's in the milestones. no?
21:57:40 <armax> with the amount of stadium stuff we’ve got now
21:57:43 <armax> and we’ll have in the fture
21:57:45 <armax> future
21:57:59 <salv-orlando> and to amuller point I do not thing networking-xxx and advanced services should be in the same bucket
21:58:13 <armax> garyk: neutron-lib you mean?
21:58:23 <dougwig> which jobs are we moving?  we have 23, some of which are very expensive (and multinode).  how many?
21:58:34 <ihrachys> they are NOT in the same bucket. networking-* are not part of official neutron releases.
21:58:40 <dougwig> err, which jobs are we proposing moving, rather.
21:58:41 <garyk> armax: yes
21:58:52 <salv-orlando> the latter are integrating part of openstack/networking, the formers instead are "glue" between openstack networking and something else and avoiding cross breakage is entirely and only their interest
21:58:59 <kevinbenton> TIME IS RUNNING OUT!
21:59:11 <armax> garyk: I think we have it, I’ll make sure I target it
21:59:12 <ajo> kevinbenton ':D
21:59:24 <salv-orlando> ihrachys: sorry, I had the feeling amuller considered them at the same level
21:59:37 <dougwig> i.e. moving lbaas+fwaas+vpnaas, in the interests of scale, and not moving any of the many dvr jobs, well, we're just not addressing the root node use issue.
21:59:38 <ihrachys> salv-orlando: it looked like it, yes
21:59:57 <ajo> shall we move to #neutron ?
22:00:05 <kevinbenton> dougwig: perhaps we should just start with the lbaas job? ;)
22:00:08 <ajo> #openstack-neutron, sorry
22:00:09 <armax> #endmeeting