15:30:47 <mestery> #startmeeting neutron-drivers
15:30:47 <openstack> Meeting started Wed Jun  3 15:30:47 2015 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:30:47 <marun> o/
15:30:48 <armax> \o/
15:30:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:30:51 <openstack> The meeting name has been set to 'neutron_drivers'
15:30:54 <mestery> #topic Agenda
15:31:00 * ihrachyshka lurks
15:31:05 <mestery> Disolve the drivers team and instead directly use lietenants
15:31:06 <mestery> :)
15:31:08 <mestery> thoughts?
15:31:39 <marun> +1
15:31:40 <mestery> I mean, not dissolve, but refocus
15:31:48 <armax> well, I think the drivers team should be made up by
15:31:49 <mestery> Since we have Lts. now, they need to be involved in evaluating RFEs
15:31:50 <armax> lietenants
15:31:54 <mestery> armax: ++
15:31:58 <mestery> dougwig amotoki ihrachyshka: Thoughts?
15:32:03 <marun> yeah, I was going to say. Still helpful to have a high-level group of ptl delegates
15:32:10 <mestery> marun: Exactly
15:32:13 <armax> this in turn means that marun and I give our seats to the other folks
15:32:23 <dougwig> seems reasonable, except for when the current LT silos don't cover something.
15:32:28 <mestery> armax marun: You both will forever be in my heart ;)
15:32:32 <armax> and include the rest of the folks
15:32:39 <marun> dougwig: the ptl is responsible for everything not delegated
15:32:43 <armax> mestery: I would personally still do the reviews etfc
15:32:47 <mestery> ++
15:32:47 <mestery> right
15:32:52 <mestery> I hope people keep reviewing!
15:32:54 <mestery> They should!
15:32:58 <mestery> Code, RFEs, etc.
15:33:11 <armax> but yesterday it occurred to me that I have not the right visibility into some of the lietenant areas for juding an approval
15:33:12 <mestery> I mean, even now, I am defering to Lts. for some of these specs/RFEs
15:33:17 <mestery> armax: Exactly
15:33:18 <amotoki> the driver team focus on the project management and mainly focuses on spec approvals.
15:33:27 <armax> amotoki: agreed
15:33:44 <marun> are drivers still the only ones to merge specs then?
15:33:44 <armax> so it makes sense to let lietenants have that right
15:33:53 <mestery> marun: Yes, and that would be made up of Lts.
15:33:54 <marun> I thought the lts should have that right
15:33:56 <marun> ah, ok
15:33:57 <armax> marun:  by the looks of it, yes
15:34:04 <mestery> marun: But, I expect after Liberty-1 we will have a negligble amount of specs
15:34:08 <marun> so lts are elevated to drivers essentially
15:34:09 <marun> makes sense
15:34:13 <amotoki> we can collaborate with lientenants and we can share our views.
15:34:17 <mestery> marun: yes, exactly!
15:34:26 <ihrachyshka> so drivers are now lieutenants + existing drivers?
15:34:28 <mestery> amotoki: Keep in mind, you and dougwig are Lts., so there is no change for either of you
15:34:38 <mestery> ihrachyshka: No, marun and armax would be out since they are not Lts.
15:35:12 <amotoki> mestery: i know, but only dougwig and me are intersections ;-)
15:35:19 <mestery> :)
15:35:37 <mestery> amotoki: So, you are advocating for keeping a separate drivers team to do project management, etc,? That's a fair point.
15:35:38 <ihrachyshka> how come armax is not in drivers team??? :)
15:35:42 <dougwig> i think it was a natural consequence, though it seems to me to be too quickly, but i don't have any objection.
15:35:46 <armax> ihrachyshka: because I am not a lt
15:35:53 <mestery> ihrachyshka: Personal choice :)
15:36:19 <armax> rest assured that my level of involvement is not going to change
15:36:29 <armax> at least for the reasonable time being :)
15:36:29 <amotoki> I don't think we should have more separate teams.
15:36:43 <marun> So long as the ptl can maintain relationships with all the lts this should be fine
15:36:55 <marun> if the number grows unmanageble, middle management may be required
15:37:00 <mestery> :(
15:37:08 <mestery> Reasonably, 7 is about the max
15:37:17 <armax> amotoki: what separate teams are your thinking of?
15:37:24 <marun> linux manages quite a deep hierarchy
15:37:25 <mestery> Although, I am going to start "IRC office hours" for "PTL to Lt. communication" each week
15:37:27 <marun> so it is possible
15:37:32 <armax> I think mestery needed to intereact on a regular basis with lietenants
15:37:35 <dougwig> an LT per tent repo is probably unmanageable already.  :)
15:37:39 <armax> that can happen in the context of this meeting
15:37:48 <mestery> dougwig: True dat.
15:37:53 <mestery> Actually
15:37:57 <mestery> Now that we're discussing this
15:38:03 <mestery> I am starting to understand amotoki's points
15:38:12 * dougwig left his tea brewing for half an hour. danger.
15:38:17 <mestery> the fact each repo in the neutron stadium has a Lt. now makes the team large already
15:38:24 <marun> I'm not sure everything in the tent needs direct ptl oversight though
15:38:27 <armax> mestery: care to elaborate?
15:38:34 <armax> marun: right
15:38:47 <mestery> marun: IT does! By coming in, they are agreeing to it, but how much time will it take? Debatable. We won't know until Liberty is done to be honest.
15:38:50 <marun> I mean, the argument for ovn's inclusion was that it wouldn't add work to ptl
15:38:52 <mestery> Experimentation is #ftw
15:38:58 <marun> If that's not true, we're in trouble
15:39:06 <mestery> For OVN, I'm already intimiately involved there, so it wasn't a problem
15:39:16 <marun> So they get special treatment :/
15:39:26 <mestery> I wouldn't say special treatment
15:39:26 <armax> mestery: I think this boils down to stuff that must go in neutron proper
15:39:26 <dougwig> marun: they are meant to be mostly standalone, but the ptl is there if needed.
15:39:31 <marun> Honestly, if we don't prioritize effort we'll be overworked indefinitely
15:39:40 <armax> or the interface with external parties
15:39:47 <mestery> right
15:39:48 <marun> Not everything in the tent is equally deserving
15:39:50 <mestery> marun: I agree!
15:39:50 <armax> for that we can keep an ad-hoc approach
15:39:58 <mestery> ++ marun
15:40:06 <amotoki> marun: ++
15:40:15 <dougwig> there's in the tent, and then there's in the same sleeping bag.
15:40:32 * marun thinks dougwig missed his calling as a comedian
15:40:51 <mestery> OK
15:41:02 <marun> So wrt lts getting direct oversight from ptl...
15:41:02 <mestery> So, this is all good feedback
15:41:30 <marun> Shouldn't that be on a prioritized basis on how important the area of responsibility is perceived to be to the project?
15:41:38 <mestery> marun: It is, yes!
15:41:41 <armax> so, to recap: drivers team == made up of neutron lt’s
15:41:59 <mestery> armax: I don't think everyone agreed to that yet :)
15:42:14 <mestery> amotoki still had concerns about dissolving the existing drivers team in favor of Lts. being the new drivers team
15:42:19 <armax> the tent projects lt’s as being defined by russellb patch https://review.openstack.org/#/c/187733/ will have ad hoc interaction with the neutron ptl?
15:42:24 <mestery> Also, do we allow LTs. from stadium projects into drivers? I would say no.
15:42:30 <marun> mestery: I think so long as you're comfortable directly interacting with the lts, it's fine.
15:42:31 <mestery> armax: Yes
15:42:33 <armax> mestery: what cocnern?
15:42:47 <mestery> armax: Correct
15:42:48 <marun> mestery: If/when it becomes too much work, then we can revsiit
15:42:56 <mestery> marun: Right, agreed.
15:42:59 <dougwig> i would suggest that the drivers team be "drivers + LTs", to give yourself some wiggle room for broader delegation.
15:43:05 <armax> mestery: ok, so does my summary make sense?
15:43:06 <mestery> marun: Thus, my idea of weekly IRC office hours for Lt. interaction
15:43:14 <armax> dougwig: no, I would oppose to the idea
15:43:17 <mestery> marun: This is how ttx has moved the general realease work to as well
15:43:25 <mestery> There are no longer 1:1s between ttx and the PTLs, just office hours
15:43:26 <marun> dougwig: nothing stopping lts from being anybody responsible for anything
15:43:28 <dougwig> armax: i mean, you can still stop being a driver.  :)
15:43:39 <mestery> dougwig: That works too
15:43:47 <armax> dougwig: but at that point if we enlarge the team so why why do we have the drivers team at all?
15:43:48 <marun> mestery: cool
15:44:09 <mestery> OK, let me write something up and share it with everyone on this.
15:44:11 <mestery> Does that sound fair?
15:44:12 <armax> dougwig: it’s either a small drivers team or no drivers teamm at all
15:44:17 * mestery gest out his DMV clipboard
15:44:18 <marun> I think this represents an expansion of driver responsibility along with increasing the membership.
15:44:20 <dougwig> so maybe he can delegate all the decomposed plugins to one person.  or maybe add nobody to that half of the group.  it's his organizational call.
15:44:24 <armax> mestery: I got number 4434343
15:44:28 <mestery> lol
15:44:30 <marun> and we're renaming it too
15:44:45 <marun> it is confusing, I'll admit
15:44:53 <armax> what are we renaming?
15:44:57 <marun> I wish we had been able to use the term 'maintainers', frankly.
15:44:58 <mestery> neutron-intent-based-lieutenant-policy-chaining? ;)
15:45:07 <amotoki> though i canot follow all discussions... lts are regarded as some kind of specialists of specific areas. on the other hand drivers team review specs and priorities. the role is a bit different but the goal is similar.
15:45:09 <dougwig> you forgot flavors
15:45:09 <marun> drivers -> lts
15:45:12 <mestery> marun: ++ to maintainers
15:45:18 <mestery> dougwig: Nuts!
15:45:20 <marun> or at least member of drivers team -> lts
15:45:49 <mestery> #action mestery to sort out neutron-drivers vs. Lts. and the path forward
15:45:51 <marun> or maybe amotoki's idea is drivers is lts + non-lt drivers?
15:45:54 <mestery> I gave myself a work item
15:46:05 <armax> not sure where the disconnect is: I think that what it’s being advocated here is that members of the drivers team are selected from the LT’s pool
15:46:17 <mestery> Are people ok with me coming up with a solution here and driving consensus?
15:46:17 <amotoki> I trust all drivers and lts and I have no worry about merging both.
15:46:31 <marun> I don't know if the distinction of driver with area of code responsibility vs driver with area of non-code responsibility is justified.
15:46:33 <armax> as they are the ones who need to care for their area of specialization, they have intimate knowledge of what needs to get done, fixed etc
15:46:37 <marun> mestery: yes
15:46:48 <mestery> OK
15:46:50 <dougwig> there is an interesting dynamic to this conversation, wherein armax and marun are opposed to the drivers continuing in their current form. if you're that adamant, why are you still in the group? aren't you really saying that you want out?
15:46:55 <mestery> We have 13 minutes left, shall we move on?
15:47:09 <marun> dougwig: It doesn't make sense for me to be in the group regardless.
15:47:11 * mestery waits for responses to dougwig's point
15:47:25 <armax> dougwig: you’re reading it wrong, but at this point yes,
15:47:27 <armax> I want out
15:47:32 <marun> dougwig: I have no vested interest in any given outcome, just that it should make sense to everyone involved.
15:47:59 <armax> because it makes no sense for me to +A a spec whose ultimate impact should be determined by the LT
15:48:11 <armax> that’s all I am saying
15:48:21 <dougwig> so you don't see your broader knowledge of neutron than most as having additional value in spec review?  (and it's broader, and with longer history, than mine.)
15:48:27 <armax> the drivers team main feat was the +A right
15:48:29 <armax> that’s all
15:48:39 <mestery> armax: Also, consistency
15:48:44 <armax> dougwig: I am not saying that I am stopping reviewing
15:48:55 <dougwig> armax: fair point.
15:49:05 <amotoki> my understanding for the driver team is not to rush to approve specs. I think it is important point.
15:49:07 <armax> only that the last say into whether something needs to be +A or not does not lie with me
15:49:09 <mestery> one of hte original goals of the small drivers team was consistency from release to release
15:49:11 <armax> dougwig: ^
15:49:17 <mestery> If we make hte team too big, we lose that
15:49:20 <mestery> amotoki: ++
15:49:47 <mestery> Lots more to discuss here I think, but this is all good! Thanks for all the feedback everyone!
15:49:48 <marun> I think this bears further thought, in any case.
15:49:52 <dougwig> mestery: yes, that's the thing that might get lost, although i see that as moving back onto the PTL's shoulders if this stays as simply "LTs".
15:49:55 <armax> amotoki: agreed, but the lt’ team is only 7 folks now, and we’d need a bit of extra help
15:50:05 <armax> especially if the core team grows, then the ratio is not too bad
15:50:11 <amotoki> armax: agreed.
15:50:31 <mestery> I'll write something up to share with folks by Monday.
15:50:47 <mestery> In either case, we'll iterate on gerrit and see what we come up with.
15:50:56 <mestery> Ideally, we keep this meeting to 9 more minutes :)
15:51:04 <mestery> Shall we look at at least a few RFEs now?
15:51:08 <armax> sounds good
15:51:16 <mestery> #topic RFE review
15:51:17 <mestery> #link https://bugs.launchpad.net/neutron/+bugs?field.tag=rfe
15:51:35 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1460177
15:51:35 <openstack> Launchpad bug 1460177 in neutron "Support metadata service with IPv6-only tenant network" [Undecided,Confirmed]
15:51:38 <mestery> Lets start with this one
15:51:48 <mestery> Because I think it's an example of a good RFE overall
15:52:28 <mestery> "metadata only works with IPv4, and we'd like it to work for tenants with IPv6 only networks."
15:52:31 <mestery> Thoughts by folks?
15:52:54 <russellb> +1 sane
15:53:15 <amotoki> it sounds reasonable for pure IPv6 world.
15:53:47 <mestery> OK, lets move it to triaged, which means that work can proceed on it. armax dougwig marun, good with this?
15:53:56 <marun> yes
15:54:04 <armax> I am wondering how cloud-init works with IPv6
15:54:32 <dougwig> aren't all ipv4 addresses also ipv6?
15:54:35 <russellb> says cloud-init can be configured with other URLs
15:54:42 <mestery> yes
15:54:45 <dougwig> i thought it was a simple no prefix scenario.
15:55:03 <dougwig> so i'm confused why that ipv4 won't work, but that's ok.
15:55:08 <dougwig> i'm too far into the weeds.
15:55:11 <armax> russellb: if that’s the case, then it should be fine
15:55:22 <amotoki> i understand we need to identify prbolems to support preu ipv6 world, but it is worth triaged.
15:55:47 <armax> I wonder if a more elegant approach would be adopting config-drive
15:55:57 <russellb> there's no adopting needed, that already works
15:56:15 <russellb> but metadata service is pretty well known and established, seems fine to make sure it works via ipv6, as well
15:56:22 <mestery> russellb: ++
15:56:25 <armax> russellb: +
15:56:28 <mestery> This one is good
15:56:41 <mestery> How about this one: https://bugs.launchpad.net/neutron/+bug/1461000
15:56:41 <openstack> Launchpad bug 1461000 in neutron "[rfe] openvswitch based firewall driver" [Undecided,Triaged] - Assigned to Jakub Libosvar (libosvar)
15:57:00 <mestery> This was an example of a not so good RFE (we're learning, I'm not picking on the submitters)
15:57:04 <mestery> But kuba's response is good
15:57:27 <mestery> kuba's update is solid
15:57:50 <mestery> I moved this to triaged I realized before consulting in this meeting, but it's fairly obvious we want this, does anyone disagree?
15:58:45 <russellb> seems obviously good to me :)
15:58:54 <marun> no disagreement
15:59:04 <amotoki> sounds good to me.
15:59:29 <mestery> added a note to the bug
15:59:48 <mestery> Lets do one more
15:59:50 <mestery> https://bugs.launchpad.net/neutron/+bug/1460222
15:59:54 <openstack> Launchpad bug 1460222 in neutron "Add 'labels', a list of opaque strings, to the neutron 'port' object" [Undecided,Triaged]
15:59:56 <mestery> armax: You moved this to triaged I think?
16:00:07 <armax> mestery: yes
16:00:15 <mestery> I'm fine with that, just letting other folks know.
16:00:29 <mestery> armax: Any idea who this should be assigned to?
16:00:36 <russellb> i think nova has a thing very similar, but they call it tags
16:00:37 * mestery notes it shouldn't be armax
16:00:39 <russellb> would be nice to be consistent
16:00:46 <russellb> but i'm fine with the concept
16:00:47 <mestery> russellb: Comment in the bug? :)
16:00:49 <amotoki> my question is whether we should allow 'labels' for all other resources.
16:00:51 <armax> acknoledging that we starteed the discussion
16:00:52 <mestery> Consistency is good
16:01:02 <dougwig> speaking as a vendor who has wanted to stash some meta-data in the past, it was always pushed back against as "locking in".
16:01:22 <armax> I am wondering if we can achieve the use case proposed with what we got already
16:01:25 <armax> like binding:profile
16:01:27 <mestery> dougwig: In effect, that is partially the goal from the proposer here as well to be honest
16:01:29 <dougwig> that's basically adding a key=value meta store to each object.  which i agree with, but which has already been rejected before.
16:01:30 <russellb> ugh, it's actually proposed as info interpreted by the backend
16:01:35 <mestery> dougwig: But the general concept seems ok
16:01:38 <russellb> more backend specific pass-through is harmful IMO
16:01:47 <mestery> russellb: Right
16:01:49 <mestery> That was my concern as well
16:01:52 <russellb> i assumed it'd be just used for clients to do filtering
16:02:10 <russellb> the more vendor specific stuff added, the less valuable neutron is as an abstraction
16:02:32 <dougwig> yes, this is purely an aid for vendor specifics. we should be upfront about that.
16:02:32 <mestery> russellb: Agreed, and the harder it becomes for people to switch backends, etc.
16:02:41 <armax> russellb: binding:profile is effectively already doing that
16:02:47 <mestery> Can you folks comment in the bug with this info too? russellb dougwig
16:02:47 <mestery> :)
16:02:51 * russellb will comment on the bug
16:02:55 <russellb> armax: right, and i think that's bad too :)
16:02:57 <marun> opaque bags of data for everyone!
16:02:59 <armax> so, we sort have that ship already sailed
16:02:59 <dougwig> flavors also does this, but puts the configuration control in the hands of operators.
16:03:03 <mestery> marun: lol
16:03:16 <russellb> armax: doesn't have to get worse
16:03:20 <mestery> Lets be honest, this is an attempt to end-run neutron, bottom line.
16:03:30 <armax> russellb: however that can be used for a number of other use cases, I was talking to Sukhdev  and he mentioned that he uses it for bare metal provisioning
16:03:47 <mestery> armax: Not everyone will use their special powers for good :)
16:03:50 <dougwig> if it didn't have use cases, we wouldn't have flavors being worked on.
16:03:58 <mestery> dougwig: ++
16:04:52 <armax> there was also another proposal made in the past about tagging core resoruces
16:05:03 <mestery> yes, the yahoo one from manesh right?
16:05:07 <armax> despite what some people think
16:05:10 <armax> mestery: yes
16:05:41 <armax> I think that pushing back is not really a viable long-term solution
16:05:53 <marun> There are too many valid use cases to ignore
16:06:07 <marun> So long as core neutron doesn't rely on these fields,  I think it's fine.
16:06:15 <mestery> marun: to quote you, "opaque bags of data for everyone!"
16:06:17 <amotoki> but we need a common way to interact with other projects. vendor specific way is not diresable.
16:06:27 <dougwig> i think all of those uses cases are covered by flavors, if we can ship it.
16:06:27 <HenryG> lol
16:06:37 <marun> mestery: but if neutron isn't using them, I don't think it matteres
16:06:38 <mestery> dougwig: We have to ship it in Liberty
16:06:43 <armax> marun: ++
16:07:01 <russellb> i think it does matter in terms of interop
16:07:01 <marun> mestery: I'm more concerned with neutron itself relying on opaque data bags.
16:07:02 <armax> amotoki: we give the tool, if the tool is misused is not our fault
16:07:05 <mestery> Lets be honest here, there are valid use cases for this, yes. Will people use this for nefarious purposes? Absolutely! Should we care? If it harms the concept of neutron and waters it down, yes.
16:07:07 <russellb> it means code written against one openstack does not work against another
16:07:09 <russellb> it makes interop worse
16:07:17 <mestery> marun: We can't rely on opaque data blogs agreed
16:07:24 <marun> russellb: that's a given
16:07:33 <marun> russellb: and a reality today
16:07:35 <armax> russellb: that’s an academic point to be honest
16:07:45 <marun> russellb: It does beg the question of how we can deal with that reality constructively.
16:07:47 <armax> russellb: no two openstack clouds are alike and interoperable, period.
16:08:00 <marun> russellb: without stalling useful efforts or requiring a bunch of rework to existing stuff
16:08:02 <russellb> take each use case and define a proper abstraction that serves it
16:08:10 <mestery> russellb: ++
16:08:10 <russellb> instead of just adding pass through data bags
16:08:23 <marun> russellb: easier said than done in a landscape of conflicting vendor requirements
16:08:33 <russellb> i do not disagree :)
16:08:42 <marun> :)
16:08:46 <dougwig> to level-set, flavors, as approved today, is nothing but a big table of opaque data bags associated with neutron objects, which must be enabled by operators and then can be seen by plugins/drivers. we have already approved this concept, in a way that doesn't promote lock-in, and doesn't touch the core data models.
16:09:15 <mestery> dougwig: ++
16:09:30 <marun> I think interop is a pipe dream where specialized behavior is being provided by specialized solutions
16:09:40 <armax> dougwig: so do you think that’s another viable appraoch to solving this use case?
16:09:44 <marun> at least above lowest-common-denominator capabilities
16:09:58 <armax> if so, we should capture that on the rfe bug
16:09:59 <marun> Given that, maybe we should find ways to make this clear to operators?
16:10:05 <amotoki> we allow some way for vendors, but it is better most things are common. it is one of our (neutron) important roles.
16:10:06 <dougwig> armax: yes, you could create ODL flavored ports.
16:10:28 <marun> So they can make decisions based on the long term cost/benefit of the loss of interop vs capabilities?
16:10:36 <mestery> ODL flavored ports, now with less testing! :)
16:10:38 <armax> dougwig: I would love pointers
16:10:40 <dougwig> armax: well, an operator could choose to define ODL flavored ports, which would then be accessible, to be clearer.
16:10:49 <armax> so that the bug author can explore with it too
16:10:57 <dougwig> i'll comment on the bug.
16:11:14 <armax> dougwig: thanks, much appreciated
16:11:26 <mestery> yes, lets comment on the bug and drive discussion there for ODL flavored ports
16:11:32 <mestery> dougwig: That is too rich not to keep using :)
16:11:45 <dougwig> that sounds kinda dirty, and i almost regret hitting enter.  :)
16:12:54 <dougwig> and we killed all conversation.
16:12:56 <mestery> OK
16:13:01 <mestery> Since we are still here
16:13:07 <mestery> And have 17 minutes or so left
16:13:07 * russellb got distracted sorry :)
16:13:09 <mestery> shall we keep going?
16:13:11 <armax> I think we should be vigilant on how certain tools provided by teh systems are used to make sure that people do not shoot themselves in the foot
16:13:14 <kevinbenton> so what purpose does neutron serve if we give up caring about interop...
16:13:25 <mestery> kevinbenton: The point is we are not giving up on interop
16:13:37 <mestery> kevinbenton: This bug will make interop worse, thus the discussion
16:13:37 <mestery> :)
16:13:44 <russellb> i think debating these features is very healthy fwiw
16:13:52 <mestery> russellb: ++
16:13:55 <russellb> gets at the heart of what neutron should be, and where lines are drawn
16:13:57 <russellb> really good stuff
16:14:23 <mestery> cool
16:14:27 <amotoki> russellb: +
16:14:29 <armax> I think we’re mixing the what we provide with how it’s being used
16:14:47 <mestery> I am firmly in the camp of "neutron is an abstraction and should be a DB/API layer"
16:14:51 <mestery> Just to be clear
16:14:58 <armax> when gunpowder was invented it clearly had various applications
16:15:05 <armax> we can make pretty fireworks
16:15:06 <mestery> lol
16:15:10 <armax> or kill people
16:15:12 <kevinbenton> i suppose that was directed at marun
16:15:30 <marun> kevinbenton: The reality is that interop has only ever been lcd
16:15:30 <kevinbenton> marun: what do you think the job of neutron is if interoperability is a pipe dream?
16:15:51 <kevinbenton> marun: lcd?
16:15:56 <marun> kevinbenton: and hopefully we bump lcd over time to encompass more features as they mature and become more widely distributed
16:16:01 <marun> lowest common denominator
16:16:11 <russellb> i read lcd as lsd ......
16:16:17 <mestery> lol
16:16:17 <dougwig> i don't think it's a pipe dream, and default neutron is interoperable.  but if an operator *chooses* to modify neutron to be non-interoperable, for their needs, why should we try to prevent that?
16:16:19 <mestery> marun: nothign wrong with that
16:16:19 <russellb> i was so confused ... and intrigued
16:16:19 <armax> russellb: LOOL
16:16:56 <kevinbenton> well stuff like port tags could easily lead to everyone developing a similar feature with a different data format
16:16:58 <marun> When we see opaque bags of data becoming the norm
16:17:03 <marun> and I'm looking at you, ml2
16:17:12 <marun> It's pretty clear that interop is starting to fall by the wayside
16:17:12 <dougwig> kevinbenton: i think port tags just got shot down.
16:17:24 <mestery> ++
16:17:29 * russellb throws a data bag at dougwig
16:17:31 <mestery> "shot down! In a blaze of glory!"
16:17:38 <marun> When we have a client that can only configure the backend with arbitrary key value pairs
16:17:45 <marun> we're not doing a good job of interop either
16:18:03 <marun> I'm not saying we're doomed, but we have been falling behind.
16:18:27 <mestery> marun: Right, thus the need to take the reigns back a bit
16:18:29 * marun digresses
16:18:30 <mestery> And focus on the platform
16:18:39 <kevinbenton> not terribly, the very basic l2 wiring doesn't rely on the data bags
16:18:51 <marun> kevinbenton: right, that's lcd
16:18:59 <mestery> "ODL flavored ports" and "data bags", only in a neutron meeting
16:19:01 <marun> kevinbenton: necessary but not sufficient to run most clouds
16:19:07 <mestery> Look
16:19:17 <mestery> part of the problem with neutron is that vendors still want to differentiate
16:19:22 <mestery> At the expense of their customers
16:19:29 <marun> 'part'? ;)
16:19:32 <mestery> Look at all the stuff we've let into the client for example
16:19:37 <mestery> "vendors gotta vend"
16:19:39 <russellb> marun: ha
16:19:40 <marun> It's the cost of doing business, yeah
16:19:42 <mestery> Our job is to keep growing lcd
16:19:44 <armax> mestery: amen to that
16:19:56 <dougwig> *cough*, some of their customers want that differentiation too.
16:20:01 <kevinbenton> marun: no, monolithic plugins skirt the provider extension and they provide l2. ml2 raises the requirements to expose the encap info
16:20:05 <mestery> dougwig: Right, thus, "vendors gotta vend"
16:20:08 <russellb> i think differentiation is possible without opaque data bags
16:20:16 <russellb> you can have a proper abstraction that not every backend implements
16:20:17 <mestery> russellb: ++
16:20:33 <russellb> and implementations of abstractions can be superior in other ways too, performance, ease of deployment, whatever
16:20:33 <marun> russellb: just have to get people to work together to develop those common abstractions
16:20:37 <amotoki> APi should define both protocol and its behaivor. If we don't define the behavior, it means we don't provide a proper abstraction. it is from operators view.
16:20:42 <marun> russellb: we can definitely improve in that regard
16:20:44 <armax> I think we’re dereiling the conversation badly
16:20:45 <russellb> marun: totally ... and i view that as a core part of what neutron is
16:20:50 <armax> not sure whetehr that was intended
16:20:50 <russellb> or should be
16:20:51 <kevinbenton> port tags as a service
16:20:59 <dougwig> i thought we already decided against data bags.  i'm nots sure why we're still arguing.
16:21:06 <russellb> are we violently agreeing?
16:21:10 <mestery> right
16:21:10 <marun> yes
16:21:11 <russellb> i mean, that can be fun sometimes
16:21:13 <mestery> we're agreeing
16:21:15 <mestery> :)
16:21:18 <mestery> data bags are out!
16:21:21 <marun> dougwig: arguers gonna argue
16:21:24 <kevinbenton> we came to agreement too soon, we have argument quotas
16:21:34 <mestery> lol
16:21:40 <mestery> OK, I'd say that's it for this week.
16:21:41 <dougwig> then let's talk service chaining.
16:21:41 <armax> bah
16:21:44 <armax> I am lost
16:21:47 <mestery> rofl
16:21:48 <kevinbenton> what am i supposed to do with all of this indignant outrage!?!?
16:21:57 <marun> service _flavor_ chaining (ftfy)
16:22:00 <dougwig> kevinbenton: go murder a puppy
16:22:04 <mestery> rofl
16:22:05 <russellb> woah
16:22:09 <russellb> that escalated quickly
16:22:09 <armax> you guys clearly taking me for a ride
16:22:21 <kevinbenton> he's from idaho, they do things differently there
16:22:25 <mestery> armax: You're like a 57 corvette my friend
16:22:31 <armax> bye bye now
16:22:36 <mestery> lol
16:22:37 <marun> heh
16:22:47 * mestery reigns everyone back in
16:22:47 <mestery> OK
16:22:49 <mestery> focus. FOCUS!
16:23:04 <mestery> I'm proposing the meeting is over, unless someone has another RFE they want to look at in 7 minutes?
16:23:13 <HenryG> A quick one
16:23:17 <mestery> HenryG: Please
16:23:20 <HenryG> Bug 1460720
16:23:20 <openstack> bug 1460720 in neutron "Move ipv6_gateway L3 config to CLI" [Undecided,New] https://launchpad.net/bugs/1460720 - Assigned to Abishek Subramanian (absubram)
16:23:31 <HenryG> The rfe tag was removed
16:23:34 <mestery> HenryG: I think I wasn't in favor of this even being an RFE
16:23:36 <mestery> I removed the tag in fact :)
16:23:46 <HenryG> But it changes the api, just wanted to make sure
16:24:25 <mestery> HenryG: Ah, ok! In reality, the RFE wasn't written well (had too much "how"), again, not picking on the submitter, the process is new
16:24:31 <mestery> HenryG: Bottom line, I made a mistake here and I'll correct it
16:24:54 <amotoki> agreed that moving something to client side sounds a big change.
16:25:27 <HenryG> yes, it should say "Add API to configure v6 gateway"
16:26:01 <HenryG> So add rfe tag back?
16:26:02 <mestery> OK, thanks amotoki HenryG.
16:26:05 <mestery> I added it back
16:26:06 <mestery> refresh
16:26:10 <amotoki> HenryG: do we still have IPv6 meeting in Liberty?
16:26:16 <kevinbenton> no
16:26:17 <HenryG> I can update the title and description
16:26:26 <kevinbenton> amotoki: sean disbanded it
16:26:36 <HenryG> We discuss v6 in the L3 meeting if needed
16:26:39 <amotoki> I think it is worth discussed among IPv6 experts.
16:27:11 <mestery> #action HenryG to make sure Bug 1460720 is discussed during an upcoming L3 meeting with carl_baldwin and team
16:27:11 <openstack> bug 1460720 in neutron "Move ipv6_gateway L3 config to CLI" [Undecided,New] https://launchpad.net/bugs/1460720 - Assigned to Abishek Subramanian (absubram)
16:27:41 <HenryG> mestery: thanks!
16:27:43 * carl_baldwin adds it to the agenda…
16:27:51 * mestery ^5s carl_baldwin.
16:27:51 <HenryG> carl_baldwin: thanks!
16:27:53 <mestery> OK
16:27:56 <dougwig> well, this has been a surreal meeting.
16:27:56 <mestery> That's a wrap!
16:28:02 <mestery> lol
16:28:04 <mestery> Thanks folks!
16:28:06 <russellb> thanks for letting me crash it
16:28:17 <mestery> russellb: Anytime :)
16:28:17 <mestery> HenryG too!
16:28:19 <mestery> #endmeeting