22:00:22 <armax> #startmeeting neutron_drivers
22:00:23 <openstack> Meeting started Thu Feb 11 22:00:22 2016 UTC and is due to finish in 60 minutes.  The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
22:00:27 <armax> ihrachys: rock on
22:00:27 <openstack> The meeting name has been set to 'neutron_drivers'
22:00:40 <ihrachys> sleeping for the most part
22:00:47 <armax> ihrachys: have a redbull
22:00:51 <mhickey> Hello
22:00:57 <armax> mhickey: hello
22:01:00 <armax> #link https://wiki.openstack.org/wiki/Meetings/NeutronDrivers
22:01:14 <mestery> ihrachys: How can you sleep with excitement like this!
22:01:32 <armax> last two times we went over the list of approved RFE's
22:01:45 <armax> we completed the list
22:01:52 <armax> some are still in progress
22:01:56 <armax> some were turned incomplete
22:02:50 <armax> no completed nor released
22:04:01 <armax> as members of this team we have three lists of bugs to go through
22:04:10 <armax> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=NEW&field.tag=rfe
22:04:25 <armax> a list of RFE’s to get an initial screening and sanity check
22:04:39 <carl_baldwin> Empty now, right?
22:04:48 <armax> yes, I cleaned that up
22:04:51 <armax> once you think the RFE is not asking for insanity and it’s well formulated
22:04:55 <armax> then move the bug to CONFIRMED
22:05:06 <armax> the second list is
22:05:08 <armax> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Confirmed&field.tag=rfe
22:05:27 <HenryG> I see 18 there
22:05:28 <armax> that’s a list of RFEs that need deeper screening, some prelimar discussion
22:05:31 <armax> yup
22:05:57 <armax> when we feel like it’s ready for discussion during the meeting
22:06:02 <armax> we can move those to TRIAGED
22:06:15 <armax> then there’s the final list
22:06:18 <armax> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
22:06:32 <armax> the one we usually go through the meeting, bike shed and rant on
22:06:50 <armax> typically a bug can either go from rfe-approved or WONTFIX
22:07:53 * armax figured I’d remind my buddies of the redtape from time to time
22:08:10 <njohnston> I appreciate the review
22:08:22 <mhickey> me too
22:08:26 <armax> you guys with me or are you already bored out of your mind?
22:08:37 <ihrachys> I actually even learned something new
22:08:38 <carl_baldwin> With you.
22:08:40 <armax> njohnston, mhickey this stuff should be captured in here: http://docs.openstack.org/developer/neutron/policies/blueprints.html
22:08:52 <carl_baldwin> Just tweaking book marks and taking copious notes.
22:08:54 <mhickey> armax: ok, thanks
22:09:05 <armax> mhickey: it may not exactly match word by word
22:09:10 <armax> but mine is just the gist
22:09:24 <HenryG> I am looking starting with the oldest
22:09:33 <HenryG> bug 1370033
22:09:35 <openstack> bug 1370033 in neutron "Admin should be able to manually select the active instance of a HA router" [Wishlist,Triaged] https://launchpad.net/bugs/1370033 - Assigned to Hong Hui Xiao (xiaohhui)
22:09:36 <armax> yes, one more thing before we jump in
22:09:39 <armax> #undo
22:09:40 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0x982eb50>
22:09:49 <mhickey> armax: fyi i have set some bugs to wishlist during the week
22:09:49 <armax> #redo
22:09:54 <armax> whatever
22:10:01 <armax> mhickey: ack
22:10:16 <mhickey> armax: I may have got it wrong! :)
22:10:18 <armax> there’s a list of pending specs
22:10:27 <armax> mhickey: that’s fine we’re here to help
22:10:30 <armax> #link https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs,n,z
22:10:36 <armax> this list of the pending specs
22:10:44 <armax> some of these may be associated to blueprints or RFE's
22:10:55 <armax> as members of this team we’re tasked to move these along
22:11:18 <armax> just as we move and shake and twist and scrub and squash the other lists
22:11:34 <armax> you guys still with me?
22:11:43 * carl_baldwin is
22:11:51 * HenryG too
22:12:03 <armax> so, pretty please, take 30 to 60 mins out of working week to curate these lists
22:12:13 <armax> it’s your duty as a driver
22:12:15 <armax> if you can’t
22:12:18 * carl_baldwin was just pondering the difficulty in coordinating between launchpad and specs repo.
22:12:22 <armax> talk to me and we’ll figure something out
22:12:41 * carl_baldwin has added it to L3 meeting to help curate.
22:12:49 <armax> carl_baldwin: thanks
22:13:02 * carl_baldwin saying everything on his mind so armax knows he's here
22:13:15 <armax> so this is the part where I either here: ‘lets’ blow the drivers team up’ or ‘armax I promise I’ll do better'
22:13:18 * ihrachys populates his calendar with recurring todo entries
22:13:21 <armax> *hear
22:13:39 <ihrachys> blowing things is a always a great idea
22:13:46 <armax> or the usual silence is the 3rd option :)
22:13:55 <armax> I was not looking forward to
22:14:01 <armax> aaaaanyhow
22:14:46 <njohnston> I'm auditing the class, and my history is short, so I don't feel qualified to give an opinion.
22:15:02 <njohnston> (just breaking the silence)
22:15:10 <armax> njohnston: thanks, I appreciate it
22:15:27 <armax> ok, let’s dive in then
22:15:29 <armax> #link https://bugs.launchpad.net/neutron/+bugs?field.status%3Alist=Triaged&field.tag=rfe
22:16:59 <HenryG> why is bug 1370033 stalled?
22:17:01 <openstack> bug 1370033 in neutron "Admin should be able to manually select the active instance of a HA router" [Wishlist,Triaged] https://launchpad.net/bugs/1370033 - Assigned to Hong Hui Xiao (xiaohhui)
22:17:22 <armax> HenryG: it seems we’re unable to reach a consensus
22:17:30 <carl_baldwin> +1
22:17:31 <armax> I recall amuller rejected the design proposal
22:17:58 <armax> and albeit suboptimal, this use case can be tackled with external orchetration
22:18:05 <armax> so it turned out to be deprioritieze
22:18:14 <carl_baldwin> Yes, he questioned the need and that there were other, more user friendly, ways to accomplish what we needed.
22:18:14 <armax> deprioritazed
22:18:41 <carl_baldwin> *deprioritized
22:18:43 <carl_baldwin> :)
22:18:45 <HenryG> OK, so at this point in the cycle we say "punted to N" and move on to the next?
22:18:47 <armax> carl_baldwin: thanks!
22:19:01 <carl_baldwin> Are any of these up for Mitaka?
22:19:05 <armax> HenryG: well, I’d argue this should be canned at this point
22:19:19 <HenryG> carl_baldwin: that was my question too
22:19:48 <armax> if we don’t seem to agree or have the desire to reach closure, it’s best to mark it wontfix until priorities change
22:19:58 <armax> at that point the RFE can be resubmitted
22:20:12 <armax> and we can reassess should a strong operator push come from the field
22:20:13 <HenryG> armax: ok, I think you, carl_baldwin and amuller are better to make that decision
22:20:25 <carl_baldwin> armax: I agree.  Won't fix.
22:20:28 <armax> I am ready to finalize this
22:20:36 <armax> this has been in the queue for a while
22:20:44 <armax> next one
22:20:51 <armax> bug 1507499
22:20:51 <openstack> bug 1507499 in neutron "Centralized Management System for testing the environment" [Wishlist,Triaged] https://launchpad.net/bugs/1507499
22:21:01 <armax> this has showed up in various shapes or forms
22:21:08 <armax> there was another one that popped up recently
22:21:12 <HenryG> That one is ongoing and it keeps getting bigger and bigger
22:21:16 <armax> bug #1537686
22:21:16 <openstack> bug 1507499 in neutron "duplicate for #1537686 Centralized Management System for testing the environment" [Wishlist,Triaged] https://launchpad.net/bugs/1507499
22:21:24 <armax> so I decided to put it on the mid-cycle agenda
22:21:39 <armax> perhaps the f2f discussion may help us to get to the bottom of this
22:21:45 <armax> we can’t afford to ignore this for much longer
22:21:50 <armax> something has to be done
22:22:16 <armax> but at the same time we need to be realistic of what we can achieve given the circumstances
22:23:30 <carl_baldwin> Do we have people who want to work on this?
22:23:55 <ihrachys> carl_baldwin: we have one in our team who is looking closely at the use case
22:24:03 <armax> carl_baldwin: not sure yet, I recall assaf wanted to work on this area
22:24:05 <ihrachys> carl_baldwin: our team == RH team
22:24:08 <armax> not him directly
22:24:23 <armax> but before we find volunteer we need to agree on a direction to be taken
22:24:28 <armax> we can’t wind people around
22:25:16 <carl_baldwin> Right, we don't yet seem to agree on the direction.
22:25:37 <carl_baldwin> Do we need a spec?
22:25:48 <ihrachys> I think yes
22:26:45 <armax> we’d need someone leading this obviously
22:27:21 <armax> but at least we’d need some degree of consensus amongst ourselves that we have an handle on this
22:27:29 <armax> before we set someone off the wrong path
22:28:31 <HenryG> There is a very long list of varying wishes in all the bugs that are duped to that.
22:28:58 * carl_baldwin noticing the same thing
22:29:17 <armax> so formalizing that would be the first step
22:29:27 <armax> and I think only a seasoned dude can do that
22:30:02 <carl_baldwin> Worth discussing at the mid-cycle?
22:30:31 <armax> I would think so
22:30:39 <ihrachys> will there be any online access for mid-cycle discussions?
22:31:09 <armax> ihrachys:  most of us will be on irc and we’ll have etherpads
22:31:18 <ihrachys> ok, that's at least something
22:31:22 <armax> we should be able to relay this stuff online
22:32:23 <armax> ok, let’s defer this to the mid-cycle with the objective to get closure on it at least from a direction point of view
22:32:55 <armax> dougwig, mestery: what do you reckon?
22:33:39 <mestery> That's a pretty big thing, do we really want to spend time on it at the mid-cycle? Or is it just making a decision on whether to move forward with it or not?
22:33:57 <mestery> But yes
22:34:12 <mestery> F2F would likely be the best way to move it forward as long as you have someone lined up for it armax
22:34:19 <armax> we can carve out some time out of the agenda
22:34:25 <mestery> ++
22:34:27 <carl_baldwin> How much time could we box it with at the mid-cycle?
22:34:41 <armax> if we do some homework ahead of time
22:35:01 <armax> a couple of hours should be enough to have at least something solid to present to the rest of the folks
22:35:06 <armax> via ML or bug report or whatever
22:35:11 <HenryG> it needs a passionate owner
22:35:19 <mestery> HenryG: ++
22:35:48 <ihrachys> HenryG: owner == implementer?
22:35:49 <armax> HenryG: they don’t come that easily these days
22:35:59 <armax> ihrachys: not necesserily
22:36:03 <HenryG> armax: I know :(
22:36:21 <armax> ihrachys: a capable implemeter and a wise advisor
22:36:28 <armax> two owners
22:36:40 <armax> anyhoo, time check
22:36:46 <armax> bug 1521194
22:36:47 <openstack> bug 1521194 in neutron "Qos Aggregated Bandwidth Rate Limiting" [Wishlist,Triaged] https://launchpad.net/bugs/1521194
22:37:38 <armax> I think this turned out to be a nonissue
22:37:42 <ihrachys> IIRC it's a feature that depends on nova scheduler work
22:37:59 <ihrachys> and the premise that qos currently misbehaves is wrong
22:38:17 <ihrachys> so I would say, nothing we can do with it right now
22:38:28 <armax> yes, that’s one way to put it
22:38:35 <ihrachys> blocked by nova, and the new scheduler probably won't happen in a day
22:39:05 <armax> I suppose the resource allocation effort in Nova may help at some point
22:39:22 <ihrachys> there's a hope, yes.
22:39:26 <armax> to allow for a fairer b/w allocation, fairer as assumed by the submitter
22:39:44 <armax> but as of now, we may just have to document the side effect of the existing implementation
22:39:55 <ihrachys> for now, we should table the proposal. on QoS front, we have a lot of passionate proposals but few passionate implementers. it may wait.
22:40:02 <armax> or take this bug as a witness of that documentaiton
22:40:21 <armax> bug 1523222
22:40:22 <openstack> bug 1523222 in neutron "[RFE] Add LBaaSv2 TLS re-encryption to backend members" [Wishlist,Triaged] https://launchpad.net/bugs/1523222 - Assigned to Kobi Samoray (ksamoray)
22:40:28 <armax> this may need dougwig guidance
22:40:37 <armax> but it doesn’t look like dougwig is listening
22:41:14 <armax> the submitter is also MIA on other RFE's
22:41:25 <armax> I’d mark incomple a move on
22:41:36 <armax> if and when they want to revive they can do so
22:41:39 <HenryG> sounds good to me
22:41:47 <armax> too bad, but meh
22:42:18 <ihrachys> relax, you ain't a magician to make everything happen :)
22:42:56 <armax> ihrachys: I am super relaxed
22:42:58 <armax> :)
22:43:53 <armax> bug 1525059
22:43:54 <openstack> bug 1525059 in neutron "Add support for external vxlan encapsulation to neutron router" [Wishlist,Triaged] https://launchpad.net/bugs/1525059
22:45:18 <dougwig> shit, calendar mismatch again.
22:45:31 <armax> dougwig: here you are!
22:45:33 <dougwig> 1523222 can be kicked out of mitaka.
22:45:48 <armax> ack
22:46:05 <armax> as for 1525059 it looks like the submitter has got an handle on things
22:46:12 <armax> mestery: these guys work for you, correct?
22:46:17 <carl_baldwin> Sounds like we want 1525059 we just need to know the details of how to make it happen.
22:46:30 <ihrachys> re bug *059: makes sense. needs a spec. we seem to have a candidate for implementation in the comments.
22:46:32 <armax> carl_baldwin: that’s right
22:46:34 <mestery> armax: Aye
22:46:46 <armax> we need to figure out how l3 and l3 get tied togetehr though
22:46:56 <armax> so perhaps a full blown spec is indeed necessary
22:46:57 <ihrachys> not sure I like the idea of l2 agent wiring interfaces for routers, but I may miss something. could be discussed in spec.
22:47:07 <armax> ihrachys: that’s my concern
22:47:09 <carl_baldwin> armax: Maybe a light spec will suffice
22:47:16 <armax> carl_baldwin: indeed
22:47:23 <mestery> Mostly I think the limitation of external networks requiring VLAN seems unnecessary
22:47:34 <armax> we need to make sure that, at least from a modelling point of view, this can work with or withour agents
22:47:45 <carl_baldwin> armax: ++
22:47:58 <armax> mestery: would your dudes still push for the agent-based solutions?
22:48:06 <armax> or have they abandoned that route?
22:48:10 <mestery> armax: For the L3 agent? We'd have to, right?
22:48:21 <armax> mestery: ack
22:48:36 <armax> ok, let’s  get this nudged in
22:48:48 <armax> all in favor?
22:48:49 <mestery> coolio
22:48:50 <mestery> ++
22:48:52 <ihrachys> +
22:49:04 <armax> bug 1527671
22:49:05 <openstack> bug 1527671 in neutron "[RFE]Neutron QoS Priority Queuing rule" [Wishlist,Triaged] https://launchpad.net/bugs/1527671
22:49:32 <armax> has anyone given this any thought?
22:49:38 <armax> ihrachys, ajo  perhaps?
22:49:47 <njohnston> I am not really clear on how this differs from the Assured Forwarding use case built in to DSCP
22:49:47 <armax> or shall this bake a teeny tad longer?
22:49:55 <njohnston> I will ask davidsha tomorrow
22:49:58 <armax> njohnston: that’s a good point
22:50:05 <armax> you should do so on teh bug report
22:50:11 <njohnston> will do
22:50:15 <armax> njohnston: thanks
22:50:27 <armax> bug 1529109
22:50:29 <openstack> bug 1529109 in neutron "[RFE] Security groups resources are not extendable" [Wishlist,Triaged] https://launchpad.net/bugs/1529109 - Assigned to Roey Chen (roeyc)
22:50:45 <armax> the fix for this looks incredibly trivial
22:50:54 <armax> but the implications are nonetheless remarkable
22:51:20 <armax> sc68cal, kevinbenton and I had reserves on how the proposal was made
22:52:00 <armax> the implication is that, if we allow this in, we can extend the secgroup extension freely
22:52:28 <armax> and that’s been an area of contention and lack of consensus ever since the inception of this work
22:53:16 <dougwig> why would we not want to allow it to be extended?
22:53:40 <armax> because pontentially vendors can come in and add properties to the API to do security stuff their own way without following the path of fwaas or a more community driven approach
22:54:09 <dougwig> ahh, so it's about common abstraction across backends?
22:54:12 <armax> on the other end, secgroups has always been an amazon thing which we wanted to stay as close as possible
22:54:19 <armax> dougwig: yup
22:54:23 <armax> having said that
22:54:40 <ihrachys> armax: but we allow it for other resource types?
22:54:41 <armax> if we do prevent such extension mechanism to go in
22:54:46 <armax> ihrachys: yes we do
22:55:44 <armax> then we’d have difficulty having a consistent experience for things like tags or timestamps or notational attributes that should apply to all resourecs
22:56:08 <armax> these overlay pretty orthogonally on the API and are innocuous because are really backend agnostic
22:56:28 <armax> my suggestion would be to figure out a way to allow this in a controlled fashion
22:56:38 <armax> thoughts?
22:57:00 <ihrachys> I believe since we already have extensions for all resources, we should at least be consistent in having them for all resources.
22:57:40 <armax> I’ll leave you guys a few minutes to formulate your opinion
22:57:48 <ihrachys> not that I like extensions too much, but hey, closing a single hole in your API consistency does not help if you have a hundred others.
22:57:49 <armax> perhaps you can express it on the bug reprt
22:58:00 <armax> ihrachys: I hear you
22:58:05 <armax> last one in the list
22:58:11 <armax> bug 1539717
22:58:12 <openstack> bug 1539717 in neutron "Add F5 plugin driver to neutron-lbaas" [Wishlist,Triaged] https://launchpad.net/bugs/1539717 - Assigned to Jeffrey Longstaff (j-longstaff)
22:58:21 <armax> this seems straightforward enough
22:58:43 <dougwig> has to reference an open source package, have a third party ci, and be a shim.   should be straightforward.
22:58:59 <armax> dougwig: cool
22:59:15 <armax> so it’s a matter to provide design guidelines
22:59:33 <armax> to how to contribute the code
22:59:33 <armax> but it’s ready to roll
22:59:33 <armax> ok!
22:59:46 <armax> I’ll clean this list according to this discussion
23:00:01 <armax> please help feeding the triaged list for next week’s discusision
23:00:04 <armax> #endmeeting