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