14:01:24 <mestery> #startmeeting networking
14:01:25 <openstack> Meeting started Tue Jun  2 14:01:24 2015 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:26 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:29 <openstack> The meeting name has been set to 'networking'
14:01:31 <mestery> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
14:01:36 <neiljerram> o/
14:01:38 <mestery> We have a good amount to cover today
14:01:41 <watanabe_isao> amotoki_, :)
14:01:42 <mestery> #topic Announcements
14:01:43 <johnsom> o/
14:01:50 <mestery> First off, welcome back to everyone from the Summit!
14:01:54 <mestery> I hope everyone enjoyed it.
14:02:02 <neiljerram> Very much
14:02:03 <mestery> Thanks to neiljerram for posting some comments from a "first time attendee" point of view :)
14:02:21 <neiljerram> :)
14:02:24 <mestery> Some things I wanted the team to be aware of post-Summit from a cross-project perspective:
14:02:30 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2015-May/065211.html New release versioning
14:02:44 <mestery> All servers are changing how they version, moving to semvar similar to the clients
14:02:56 <mestery> E.g. Liberty won't be 2015.2, it will be 12.0.0 (or some such version)
14:02:59 <sahid> jaypipes: thanks for your reviews, i have replied to the first one and since i would like to address your comments.. - can you take a look?
14:03:02 <sahid> https://review.openstack.org/#/c/174313/16
14:03:13 <mestery> sahid: Wrong channel perhaps?
14:03:22 <mestery> sahid: This is the neutron meeting right now
14:03:31 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2015-May/065144.html No more stable point releases
14:03:35 <sahid> mestery: yes sorry
14:03:50 <mestery> I suspect both of these items will affect packagers the most.
14:03:57 <mestery> Bringing them up here so people are aware.
14:04:07 <mestery> Next announcement
14:04:10 * beagles wanders in a little late
14:04:13 <mestery> #link https://etherpad.openstack.org/p/neutron-liberty-mid-cycle Neutron mid-cycles
14:04:18 <dougwig> are they releasing independently, or will there will be an integrated/tested "this is L" package?
14:04:20 <mestery> #undo
14:04:20 <openstack> Removing item from minutes: <ircmeeting.items.Link object at 0x941c8d0>
14:04:50 <mestery> dougwig: Integrated release is dead, but in general, I think most formally-integrated-projects will release at the same time this fall
14:05:12 <mestery> #info We have two mid-cycles which are quickly approaching
14:05:26 <mestery> #link https://etherpad.openstack.org/p/neutron-liberty-qos-code-sprint QoS mid-cycle in Raanana Israel
14:05:36 <mestery> #link https://etherpad.openstack.org/p/neutron-liberty-mid-cycle US mid-cycle in Fort Collins CO
14:06:03 * mestery slows down a bit
14:06:15 <amotoki_> dougwig: I think it is a separate topic. I see Ironic is exploring more releases in liberty.
14:06:16 <mestery> Any questions on the mid-cycles?
14:06:52 <mestery> On the Ironic topic ...
14:07:01 <mestery> #link https://wiki.openstack.org/wiki/Meetings/Ironic-neutron Weekly Ironic/Neutron meeting on IRC
14:07:09 <mestery> Please see Sukhdev for more information and to join in!
14:07:27 <mestery> Any other announcements for the team?
14:08:08 * mestery looks around for enikanorov or enikanorov_
14:08:31 <mestery> #topic Bugs
14:08:37 <ajo> hi :)
14:08:46 <ajo> sorry to be late...
14:08:50 <mestery> In lieu of enikanorov_ and enikanorov being here, does anyone have any bugs they want to bring up?
14:08:54 <mestery> ajo: No worries, you're perfectly on time ;)
14:09:24 <neiljerram> I presume you don't mean RFE bugs, at this point?
14:09:42 <mestery> neiljerram: Yes, I was going to discuss that process later in the meeting :)
14:09:53 <watanabe_isao> mestery, sir the BP-spec policy in Announcements / Reminders
14:10:00 <mestery> watanabe_isao: Correct!
14:10:15 <mestery> OK, I know emagana had to miss today as well so lets move on to that topic then
14:10:21 <mestery> #topic New RFE Process
14:10:27 <mestery> #link https://github.com/openstack/neutron/blob/master/doc/source/policies/blueprints.rst
14:10:42 <mestery> For those who haven't been following the patches, thanks to the efforts of a bunch of people we have a new specs/RFE process for Liberty!
14:10:50 * mestery waits for people to read the link
14:11:09 <mestery> I see some people are already filing RFE bugs, which is great!
14:11:22 <mestery> And dougwig proposed and we merged a new trimmed down spec template, also great!
14:11:38 <ajo> mestery I guess that stuff that went through the normal spec+blueprint process, we don't need RFE, or is it beneficial for tracking somehow?
14:11:41 <mestery> And we have no deadlines this cycle. How great is that?
14:11:53 <mestery> ajo: Correct! Anything already proposed will be reviewed as-is.
14:11:58 <mestery> No need to drop it and file an RFE.
14:12:00 <ajo> mestery: it's awesome :)
14:12:05 <dougwig> at least through liberty-1.
14:12:09 <mestery> We'll review existing specs until Liberty-1
14:12:10 <armax> mestery: no deadline aka gavage
14:12:11 <mestery> dougwig: ++
14:12:19 <pc_m> mestery: Will there be periodic review of the RFEs proposed?
14:12:20 * armax rambles
14:12:22 <neiljerram> gavage?
14:12:30 <mestery> pc_m: Yes! The drivers team is meeting weekly and reviewing
14:12:32 <armax> neiljerram: force feeding :)
14:12:41 <russellb> so ... RFE == opportunity to get general idea reviewed/approved before writing spec?
14:12:41 <russellb> trying to distill this into tl;dr
14:12:43 <pc_m> mestery: Thanks
14:12:52 <mestery> #link https://en.wikipedia.org/wiki/Force-feeding
14:12:58 <mestery> russellb: Yes!
14:12:58 <pcarver> The ML3 spec was started (not by me) prior to the summit and new RFE process but I'd be happy to take a stab at creating an RFE for it if that's a good idea.
14:13:03 <armax> russellb: yes, pretty much
14:13:03 <russellb> mestery: ok thanks
14:13:12 <mestery> Exactly, we're trying to separate the "what" from the "how"
14:13:20 <mestery> cc marun :)
14:13:26 <marun> :)
14:13:35 <russellb> seems reasonable, just making sure i parsed it properly
14:13:43 <mestery> pcarver: In the case of ML3, it may make sense, per my email. Thank you for doing that!
14:13:48 <armax> pcarver: we thought that for things that are already flying by
14:13:56 <armax> pcarver: there’s no need to go back and add a RFE
14:14:06 <armax> but every case is different I suppose
14:14:11 <mestery> russellb: Absolutely! If you find issues or holes, please, let me know.
14:14:15 <pc_m> mestery: Are there guidelines yet for the RFEs? I know that was a TBD
14:14:27 <mestery> pc_m: marun was going to submit a template RFE
14:14:33 <mestery> marun: Did you get to that? If not, I can take a crack this week.
14:14:39 <marun> mestery: armax stepped up and did the work
14:14:41 <pc_m> mestery: That would be great
14:14:41 <armax> pc_m, mestery: no, guidelines have been filed
14:14:43 <dougwig> i think armax merged something
14:14:45 <mestery> marun: Cool!
14:14:57 <mestery> pc_m: It's in here at the bottom: https://github.com/openstack/neutron/blob/master/doc/source/policies/blueprints.rst
14:14:59 <armax> https://github.com/openstack/neutron/blob/master/doc/source/policies/blueprints.rst#rfe-submission-guidelines
14:15:03 <mestery> armax: Thanks for being awesome as usual :)
14:15:03 <armax> #link https://github.com/openstack/neutron/blob/master/doc/source/policies/blueprints.rst#rfe-submission-guidelines
14:15:13 * mestery gives armax two gold stars
14:15:20 <pc_m> armax: thanks!
14:15:21 * armax feels pretty
14:15:24 <mestery> The elusive double gold star!
14:15:26 <dougwig> armax: +1
14:15:39 <ajo> :)
14:16:03 <mestery> I encourage people that are having issues to reach out to me on IRC, email, or stop by my home and I'll work with you as we move to this new RFE process.
14:16:04 * armax keeps his gold stars dearly in his wall of fame
14:16:22 <mestery> It's going to be awesome, and I want everyone to succeed with it so I'm going to help as much as is needed here.
14:16:39 <watanabe_isao> mestery, sir, you said there is no dead line for RFEs. But how about the old spec (in back log), is the dead line for them lebarty-1?
14:16:56 <mestery> watanabe_isao: Yes, but only because we want to move away from the old waterfall specs.
14:17:07 <mestery> watanabe_isao: Post Liberty-1, you can re-file as an RFE.
14:17:15 <mestery> The deadline is only for reviewing existing specs filed under the old process.
14:17:22 <watanabe_isao> mestery, I see. Thank you.
14:17:23 <mestery> #action mestery to send email to ML about new process.
14:17:25 <markmcclain> mestery: it's summer folks might take you up on the offer to stop by your house to enjoy the good weather :p
14:17:39 <ajo> :-)
14:17:40 <xgerman> lol
14:17:50 <mestery> markmcclain: My door is open. We can sit on the porch in the evenings :)
14:17:57 <mestery> #link http://www.siliconloons.com/posts/2015-06-01-new-neutron-rfe-process/
14:17:58 <armax> me too me too
14:18:00 <ajo> I'd consider it if I wasn't 10^3's of kms away ;)
14:18:05 <mestery> I wrote a blog on the new approach as well for folks to consume.
14:18:09 <mestery> ajo: lol
14:18:36 <mestery> Any other questions on the new process before we move on?
14:19:19 <neiljerram> No question, just warm fuzzy feelings.
14:19:25 <mestery> neiljerram: :)
14:19:30 <mestery> OK, lets move on!
14:19:36 <russellb> kind of curious why the warm fuzzy feelings
14:19:41 <russellb> it's not less process, it's more, right??
14:19:42 * mestery waits
14:19:51 <neiljerram> It feels very positive.
14:20:00 <russellb> just that you get the idea acked first, which hopefully saves some wasted time
14:20:05 <mestery> I don't think more, it's just splitting the process up.
14:20:07 <mestery> russellb: ++
14:20:11 <neiljerram> Also separating out what from how sounds good to me.
14:20:12 <ajo> russellb: slimmed spec template
14:20:29 <russellb> mestery: ok, fair enough, 2 steps to hopefully help avoid wasted spec writing time
14:20:32 <russellb> ok, feel free to move on
14:20:36 <russellb> sorry :)
14:20:39 <mestery> russellb: Yup, exactly.
14:20:40 <armax> russellb: on no spec at all
14:20:54 <russellb> armax: ok that's a part i missed, and that's kind of important, heh
14:20:58 <mestery> lol
14:21:03 <ajo> :)
14:21:06 * mestery grabs russellb some more coffee
14:21:25 <russellb> i personally think specs are important for the bigger things
14:21:29 <armax> russellb: I imagine we’ll have to wait and see in 6 months time whether things improved or not
14:21:31 <russellb> or instead you waste even *more* time writing code
14:21:34 <dougwig> russellb: see the spec template: "Do you even need to file a spec? Most features can be done by filing an RFE bug
14:21:34 <dougwig> and moving on with life."
14:21:37 <armax> and iterate in case things have gone off a cliff
14:21:42 <mestery> russellb: Agreed!
14:21:56 <russellb> ok, so simple things == no spec, +1
14:21:58 * russellb sits down
14:22:00 <mestery> russellb: We're hopefully optimizing for the small things here
14:22:35 <dougwig> optimizing for small things, and getting consensus on smaller pieces at a time.   or just building a house of cards that will catch on fire.  we'll see.
14:22:54 <mestery> rofl
14:23:03 <mestery> OK with that comment from dougwig, lets move on to the next topic.
14:23:13 <mestery> #topic nova-network and neutron compatibility tasks
14:23:20 <mestery> #link https://etherpad.openstack.org/p/YVR-nova-network
14:23:29 <sc68cal> hello
14:23:37 <mestery> At the Summit, we had many good sessions with the nova team around closing the functionality gap between nova-network and neutron
14:23:50 <mestery> If you look on that etherpad, we have identified 9 tasks near the bottom
14:23:53 <mestery> We need owners for a few
14:23:59 * mestery waves at sc68cal who is driving a lot of this
14:24:09 <mestery> Sorry, 7 tasks now
14:24:13 * russellb took 1 \o/
14:24:24 <aduarte> .
14:24:24 <mestery> russellb: Yay! Thanks for taking the gate job for upgrade testing!
14:24:27 <neiljerram> I was thinking of looking at the DHCP hostname one, if no one else already has that.
14:24:34 <mestery> #info russellb takes ownership of the gate job to ensure rolling upgrades work
14:24:50 <mestery> neiljerram: I think mlavalle has that one already, but please reach out to him
14:24:57 <neiljerram> D'oh, sorry, there's already a name there.
14:25:12 <mlavalle> neiljerram, mestery: Yes I have that one
14:25:20 <mestery> We have two gaps left: distributed SNAT with DVR and "give me a network"
14:25:23 <mestery> sc68cal has filed a spec for the latter
14:25:27 <mestery> The former has nothing yet
14:25:50 <mestery> #link https://review.openstack.org/184857 "Give Me a Network" spec
14:26:05 <neiljerram> I plan to comment on "Give Me a Network", at least...
14:26:33 <mestery> neiljerram: Great!
14:26:43 <sc68cal> I don't really own the spec, it's just that etherpad ate anything that was typed during the session so I tried to quickly write down what I remembered before I forgot it all
14:26:48 <vikram> I Will also help in review..
14:26:55 <mestery> vikram: Thanks!
14:27:01 <mestery> sc68cal: Agreed! Thanks for at least starting it
14:27:38 <mestery> For DVR distributed SNAT, I think I'll talk to Swami and see what the plan is there.
14:27:48 <HenryG> For #3. ARP Spoofing we need to make a decision on how to move forward.
14:28:03 <mestery> HenryG: What is the holdup there?
14:28:06 <HenryG> The next patch is https://review.openstack.org/157634
14:28:07 <markmcclain> HenryG: you were reading my mind to bring this up
14:28:20 <mestery> :)
14:28:22 <HenryG> markmcclain: :)
14:29:10 <HenryG> I know markmcclain has reservations about needing to create a big ebtables manager class
14:29:31 <armax> mestery: for some reason dvr on linux bridge has disappeared from that list?
14:29:42 <mestery> armax: I don't think it was ever there, but lets add it.
14:29:56 <mestery> armax: Added it
14:30:09 <russellb> why does this have to be ebtables?  to work with LB, too?
14:30:10 <armax> it was in the notes at the very top
14:30:30 <russellb> seems much easier to do in ovs
14:30:35 <dougwig> dvr/lb - is that because provider nets provide north-south/east-west without needing a neutron router in the mix, so that case was sort of covered?
14:30:50 <mestery> russellb: Agreed, but keep in mind that we need to support LB as well
14:30:52 <markmcclain> HenryG: I do... I think we should take the opportunity to design the class for our usage vs the forklifted code
14:31:05 <russellb> mestery: *nods*
14:31:08 <HenryG> russellb: shared networks with LB is the common use case when migrating from nova network, I believe
14:31:14 <mestery> HenryG: ++
14:31:59 <marun> the current patch could definitely use a rewrite
14:32:08 <armax> dougwig: that sounds roughly familiar
14:32:15 <marun> can we consider it a prototype and start again?
14:32:27 <armax> dougwig: either way it looks like that’s not documented properly
14:32:31 <marun> maybe with a design doc?
14:32:32 <amotoki_> marun: which patch are you talking about?
14:32:37 <marun> https://review.openstack.org/#/c/157634/11
14:32:41 <ajo> markmcclain: jlibosva also agrees on that
14:33:06 <mestery> HenryG: Seems like consensus is building towards a rewrite of that patch. Anyone disagree here?
14:33:17 <markmcclain> I think we can contribute some resources to help with the effort
14:33:39 <mestery> markmcclain: Excellent!
14:33:40 <ajo> I can loop in for reviews at least
14:33:54 <marun> I'd like to see some work on defining what problem is being solved before implementation proceeds
14:34:05 <mestery> I know this code has a long and storied history of (not) merging, but it seems like we're driving towards better testable code here with this one.
14:34:08 <marun> If only for the sake of future maintainers
14:34:09 <ajo> marun +1 to devref ;)
14:34:11 <markmcclain> marun: +1000
14:34:12 <mestery> marun: And RFE perhaps?
14:34:22 <emagana> I am here...  better late than never..  my laptop crashed badly this morning~
14:35:00 <ajo> mestery: may be a simple initial devref works, since that's already a dependency for two things
14:35:01 <russellb> emagana: sounds about right.  i hate computers.  :-)
14:35:04 <ajo> (source mac filtering  + DVR/lb)
14:35:21 <mestery> ajo: Makes sense.
14:35:49 <marun> ajo: that sounds reasonable to me.  It would be a good place to have a conversation about high-level design.
14:36:22 <mestery> marun ajo: ++
14:36:29 <HenryG> OK, who is going to put up an initial draft?
14:36:35 <mestery> That was my next question :)
14:36:51 <markmcclain> I can take a stab at it
14:37:20 <mestery> #action markmcclain to write a devref document about ebtables code in support of source mac filtering and DVR/LB work
14:37:21 <mestery> markmcclain: Consider it done ;)
14:37:21 <ajo> markmcclain: loop in jlibosva, may be he has time to work on this, he already spent some time thinking about a new iptables manager design
14:37:36 <HenryG> markmcclain: I was hoping you would, since you seemed to have an idea of what you wanted. :) Thanks!
14:37:38 <ajo> markmcclain: even he made some prototypes
14:37:42 <markmcclain> ajo will do
14:37:50 <mestery> Excellent!
14:38:00 <ajo> markmcclain +1
14:38:03 <mestery> ajo: Hopefully jlibosva is ok with you volunterering him all over the place :)
14:38:24 <ajo> mestery, probably not :D, but I guess he will be happy to provide his conclusions to previous work
14:38:34 * jlibosva silently reads with mixed feelings :)
14:38:44 <ajo> jlibosva '':D ;) +1
14:38:50 <mestery> lol
14:38:55 * ajo hides
14:39:01 <mestery> OK, any other nova-network compatibility items to discuss?
14:39:05 <mestery> sc68cal: Anything you wanted to add?
14:39:10 <sc68cal> The linux bridge job is failing due to the structure of DevStack's neutron-legacy file
14:39:23 <russellb> thanks a bunch to everyone putting time on this
14:39:33 <sc68cal> there are many things placed into the main neutron-legacy file that were OVS specific
14:39:41 <sc68cal> so let's stop doing that in the future
14:40:15 * sc68cal points to PUBLIC_BRIDGE being defined in ovs_base but referenced in neutron-legacy
14:40:38 <mestery> sc68cal: I believe you have a patch on that one out for review already
14:40:50 <mestery> sc68cal: And thanks for shepherding this through!
14:41:01 * russellb offers sc68cal a gold star
14:41:08 <sc68cal> yep, but I talked with Sam-I-Am about it and we found some other parts that are OVS specific, that we may move into ovs_base
14:41:08 <mestery> lol
14:41:13 <sc68cal> russellb: oooooh :)
14:41:25 <amotoki_> Do we use some bug tag for nova-network compatibility? "nova-net"? I think we have several minor incompat things.
14:41:33 <mestery> sc68cal: If you hit obstacles that need some help removing, please ping me ASAP
14:41:41 <mestery> amotoki_: That's a good idea!
14:41:44 <sc68cal> amotoki_: +++ good idea
14:42:01 <sc68cal> mestery: thanks, will do. That's all from me - I'll be working on stuff today
14:42:11 <mestery> great!
14:42:11 <amotoki_> "nova-net" sounds good? if so, I will add it as an official tag.
14:42:16 <mestery> amotoki: Please do :)
14:42:28 <amotoki_> sure. please move on.
14:42:35 <russellb> "nova-network" would match the actual service name
14:42:37 <russellb> but *shrug*
14:42:57 <sc68cal> nova-net-compat?
14:43:05 <russellb> even better
14:43:14 <mestery> sc68cal: ++
14:43:15 <dougwig> the shorter the better, imo.
14:43:16 <amotoki_> sc68cal: sounds better.
14:43:16 <russellb> that's pretty explicit, i like it
14:43:24 <HenryG> Bike shedding alert!
14:43:30 <ajo> lol
14:43:38 <russellb> too busy yak shaving to bike shed any further
14:43:40 <dougwig> HenryG: lol
14:44:32 <mestery> Hey! It's yak shedding: https://twitter.com/mestery/status/605359030119354368
14:44:33 <mestery> :)
14:44:48 <sc68cal> :)
14:44:51 <HenryG> Sorry, didn't mean to offend, just trying to keep things moving. :)
14:45:01 <mestery> OK
14:45:03 <mestery> Lets keep rolling
14:45:05 <mestery> 2 more items to cover
14:45:14 <mestery> #topic QoS
14:45:18 <mestery> ajo: You're up!
14:45:24 <ajo> hi :)
14:45:43 <ajo> so basically, we have an agreement on how to do the api, and how to build a service plugin for qos,
14:45:52 <mestery> yay!
14:46:08 <ajo> and we're ok with doing it: out tree, in tree.
14:46:27 <mestery> ajo: Do you mean in openstack/neutron vs. something like openstack/neutron-qos?
14:46:36 <ajo> we couldn't decide what was best, every side has it's pro's and drawbacks...
14:46:38 <ajo> correct :)
14:46:48 <ajo> mestery: correct
14:46:59 * mestery gets out his paint brush
14:47:17 <ajo> in /neutron, has more core review, but needs more core attention, also has less overhead
14:47:28 <dougwig> ajo: that comes down to simpler integration vs faster velocity.
14:47:30 <mestery> ajo: Another option is a feature branch on openstack/neutron
14:47:30 <ajo> in /neutron-qos, requires less core review, introduceds more overhead
14:47:44 <sc68cal> have we had any successful feature branches in Neutron?
14:47:50 <mestery> ajo: And we look to merge it post Liberty-2 or something. We sync it weekly.
14:47:52 <mestery> sc68cal: Yes! LBaaS V2!
14:47:54 <marun> sc68cal: that's a good thing to think about
14:48:05 <ajo> good question, but
14:48:07 <marun> I'd vote for experimenting with a feature branch
14:48:12 <sc68cal> I thought it was moved into its own repo?
14:48:14 <marun> Because we should be doing more of that
14:48:15 <ajo> LBaaS isn't on openstack/neutron-lbaas ?
14:48:20 <mestery> sc68cal: IT was, but it started as a feature branch
14:48:23 <mestery> marun: ++
14:48:27 <armax> marun: ++
14:48:35 <sc68cal> hmm, that to me indicates that feature branches are not successful
14:48:42 <marun> feature branches *should* allow faster iteration with less overhead
14:48:44 <dougwig> sc68cal: the lbaas feature branch never got merged, so i'm not sure it's a success story of that process.
14:48:48 <rkukura> ajo: Is enforcing QoS likely to require siginficant support from ML2 port binding and ML2 mechanism drivers? If so, in-tree might have advantages.
14:48:59 <mestery> sc68cal: Why? Initially, LBaaS was in neutron and we did a feature branch for V2. Then, we made the decision to split services, which wasn't due to LBaaS V2 at all.
14:49:12 <ajo> rkukura: out-tree also guarantees better decoupling and better api contracts
14:49:20 <mestery> dougwig: At the least, I'd say it was partly succesful.
14:49:24 <sc68cal> mestery: we can discuss after meeting, I don't want to take up time :)
14:49:25 <ajo> well, not guarantees, but helps
14:49:25 <dougwig> i'd want a feature branch if it has to muck with a bunch of neutron.  i'd prefer external if it's a new extension and such, because then it's easier to play with with existing installs of neutron.  imo.
14:49:28 <markmcclain> I think if we're targeting L2 then a feature branch might come with too many complications
14:49:30 <mestery> QoS is tied to ML2?
14:49:49 <marun> markmcclain: which complications are you concerned about?
14:50:00 <ajo> mestery: nope, plugin wise
14:50:16 <marun> I think for large work we should either be doing feature branches our out-of-tree
14:50:20 <mestery> ajo: I was just confused by how it was tied to ML2, which would be bad considering we have plugins outside of ML2.
14:50:27 <marun> Otherwise we risk getting into patch series hell
14:50:31 <rkukura> mestery: I don’t know, but I’d think when using ML2, the port binding would need to take QoS into account to ensure requested QoS can be provided.
14:50:31 <ajo> mestery: ack
14:50:34 <marun> our -> or
14:50:56 <armax> I think we can start with a feature branch, assess how the code looks like and make a call whether to merge it or spin it off
14:51:06 <mestery> rkukura: Since ML2 is a control plane, sure, that makes sense. I was just concerned about tieing this to ML2 in some way.
14:51:09 <markmcclain> marun: generally merges... infra usually suggests that unless if lives beyond a cycle in tree is usually better
14:51:30 <amotoki_> i think feature branch fits qos work since it will require interations even if it turns out it needs to be coupled with L2.
14:51:30 <ajo> armax: that sounds right, we could decide by the end liberty-2 or so...
14:51:31 <ajo> my concern here
14:51:41 <marun> markmcclain: fair enough
14:51:43 <ajo> I'd like this to be available for people to try out by the end of liberty
14:51:45 <rkukura> feature branch makes sense to me
14:51:51 <ajo> if a feature branch risks it, I prefer an spin off
14:52:08 <armax> let’s start off with a feature branch and get to the finish line quickly
14:52:14 <mestery> #action mestery to work with ajo to find a place where QoS should live by next week.
14:52:15 <marun> markmcclain: that would seem to conflict with what I've heard from folks on the lk side of things
14:52:20 <mestery> ajo: ^^^ Sound ok?
14:52:28 <ajo> mestery, sounds very good
14:52:38 <mestery> OK
14:52:40 <mestery> 8 minutes left
14:52:44 <mestery> And one item on the agenda left
14:52:50 <mestery> Lets move on
14:52:55 <mestery> #topic Core and Vendor Decomp: Next Steps
14:52:55 <markmcclain> marun: right I think this is one of the subtle difference in how the underlying infrastructure for the communities functions
14:53:00 <mestery> armax HenryG: You're up
14:53:24 <armax> HenryG put a patch up
14:53:26 <armax> #link https://review.openstack.org/#/c/187267
14:53:26 <HenryG> I put up an initial draft in devref
14:53:39 <armax> the gist of it is
14:53:54 <armax> we want to take the core-vendor decomp work to the next phase
14:54:07 <mestery> Nice! Uplevel the decomp! ;)
14:54:18 <armax> and we’ll be working on the steps as are being defined in that patch
14:54:41 <HenryG> One question I have not addressed is:
14:55:02 <armax> so if everything goes according to plan plugin or driver can take place entirely out of tree
14:55:06 <HenryG> Do we leave a shim, or is it OK to move completely out of Neutron?
14:55:14 <armax> HenryG: out entirely
14:55:30 <russellb> +1
14:55:42 <HenryG> armax: OK, I will update the doc with that for people to comment on.
14:55:43 <armax> HenryG: a project can be marked as Neutron tented project by filing the governance patch
14:55:46 <russellb> i'd personally prefer to see things out entirely instead of split up
14:56:14 <russellb> all-in or all-out anyway
14:56:24 <marun> I agree with that
14:56:36 <marun> The shim thing was largely for political reasons
14:56:41 <armax> once we’re completed with this work, I think it’s sensible to consider M as the cycle where we look at what’s in what’s out and start deprecating
14:56:47 <marun> We risked stalling if we tried to impose that last cycle
14:56:50 <mestery> russellb: ++
14:56:57 <mestery> And now that we have the option of coming into the Neutron stadium
14:57:00 <russellb> makes sense
14:57:00 <mestery> The shims make even less sense
14:57:07 <armax> marun: right, the change in governance model somewhat addresses that aspect
14:57:23 <armax> marun: but we still need to judge the 4 O’s etc
14:57:27 <mestery> The bigger question I have is, for plugins/drivers that have not done anything yet, when do we boot them out of tree.
14:57:37 <armax> mestery: ^^^
14:57:38 <marun> armax: agreed. and efforts to provide better discoverability for neutron-related efforts should address some of the concerns around not being in-tree.
14:57:44 <armax> see my comment above
14:58:04 <mestery> armax: Yes, I've been looking at things which are proposed already, backends are coming under the Neutron stadium quite nicely.
14:58:11 <mestery> armax: And even some APIs as well.
14:58:22 <russellb> and i think there's room to do some classification of the things in the neutron tent, to still differentiate who is better a better citizen
14:58:45 <russellb> carrot badges
14:58:59 <marun> gamification ftw ;)
14:59:00 <armax> healthy!
14:59:29 <mestery> russellb: ++
14:59:31 <russellb> yup!
14:59:39 <mestery> we can't get rid of gamification no matter how hard we try
14:59:42 <mestery> 20 seconds left
14:59:43 <mestery> :)
14:59:50 <mestery> OK, thanks for joining us today folks!
14:59:55 <mestery> See you all next week!
14:59:59 <russellb> o/
14:59:59 <mestery> #endmeeting