21:01:29 <mestery> #startmeeting networking
21:01:30 <openstack> Meeting started Mon Mar 30 21:01:29 2015 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:34 <openstack> The meeting name has been set to 'networking'
21:01:41 <mestery> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
21:01:49 <mestery> #topic Announcements
21:01:59 <mestery> #info We're in the feature freeze now
21:02:06 <mestery> Be even more cautious with what you're merging now.
21:02:16 <mestery> If a bug isn't marked as RC and you have quesitons, feel free to ping me
21:02:19 <mestery> #info RCs: April 9-23
21:02:38 <mestery> We'll circle back to the final 4 BPs which are targeted to the RC later in the meeting.
21:02:59 <mestery> OK, lets keep moving, a packed agenda awaits us!
21:03:00 <mestery> #topic Bugs
21:03:02 <mestery> enikanorov: Hi!
21:03:09 <enikanorov> mestery: hi
21:03:13 <marun> hi
21:03:28 <enikanorov> i'd like to mention just one bug now
21:03:39 <enikanorov> https://bugs.launchpad.net/neutron/+bug/1438321
21:03:40 <openstack> Launchpad bug 1438321 in neutron "Fix process management for neutron-server" [High,Confirmed] - Assigned to Elena Ezhova (eezhova)
21:03:59 <enikanorov> this is an issue that will be introduced if we sync with oslo-incubator
21:04:15 <enikanorov> neutron server will not be able to handle signals properly
21:04:40 <mestery> enikanorov: Thanks for bringing this one up
21:04:55 <enikanorov> moreover, the code around service process management need to be reworked, but for now we just need to take care about how not to break what is working
21:05:15 <anteaya> I'm missing something why would you sync with oslo-incubator?
21:05:43 <dougwig> because we use oslo incubator modules, and sync regularly.
21:05:46 <enikanorov> anteaya: there are some parts of oslo that are not in a common library yet and are synced
21:06:02 <mestery> I wanted to bring the two bugs up that are not marked as RC but are targeted there:
21:06:03 <mestery> https://bugs.launchpad.net/neutron/+bug/1381536
21:06:05 <openstack> Launchpad bug 1381536 in neutron "ResourceClosedError occurs when neutron API run in parallel" [High,Confirmed] - Assigned to Eugene Nikanorov (enikanorov)
21:06:05 <anteaya> oh a module in oslo-incubator
21:06:17 <anteaya> okay sorry, I mis-understood
21:06:20 <mestery> This one doesn't appear to be actively worked on at the moment
21:06:30 <mestery> enikanorov: Are you planning to fix this one in the RC?
21:06:33 <enikanorov> mestery: correct, it's better to find someone else
21:06:38 <enikanorov> to work on it
21:06:50 <mestery> enikanorov: Ack, I'll remove you for now, leave it in the RC for a bit and see if I can find someone. Thanks enikanorov!
21:06:51 <armax> enikanorov: when did we sync with oslo incubator last?
21:06:53 <salv-orlando> enikanorov: do we have some traces in logstash?
21:06:53 <enikanorov> i might take a look at it, but can't promise
21:07:28 <mestery> We also have hte VLAN transparent and MTU cleanups, pritesh and ideas there?
21:07:29 <mestery> https://bugs.launchpad.net/neutron/+bug/1434667
21:07:31 <openstack> Launchpad bug 1434667 in neutron "VLAN transparent feature cleanup" [High,Confirmed] - Assigned to pritesh (pritesh)
21:07:39 <mestery> https://bugs.launchpad.net/neutron/+bug/1434671
21:07:40 <openstack> Launchpad bug 1434671 in neutron "MTU advertisement feature cleanup" [High,In progress] - Assigned to Timothy Swanson (tiswanso)
21:07:56 <pritesh> mestery: i have made some progress on it, will post the patch as soon as i can
21:07:59 <mestery> We can also discuss this during the bike shedding on APIs later in the meeting if people prefer :)
21:08:03 <mestery> pritesh: OK, thanks for the update!
21:08:03 <enikanorov> armax: march 6 apparently
21:08:22 <mestery> Any other bugs? enikanorov? Anyone?
21:08:30 <pritesh> mestery: also tim is on the mtu stuff, so he will also be posting a patch soon for it.
21:08:30 <armax> enikanorov: I see, so just a handful days after that change merged
21:08:37 <mestery> pritesh: Ack
21:08:48 <armax> enikanorov: I mean https://review.openstack.org/#/c/156345/
21:09:43 <enikanorov> armax: i'm wrong. the merge is from march,6 but the commmit is feb 27
21:09:50 <enikanorov> armax: so the breaking change is not it
21:10:05 <amotoki> it seems not to be imported yet.
21:10:13 <armax> enikanorov: so you’re saying that we don’t have a problem, yet?
21:10:25 <enikanorov> armax: correct
21:10:30 <armax> enikanorov: at least not until we effectively sync down?
21:10:36 <enikanorov> armax: exactly
21:10:38 <armax> (which we shouldn’t now, anyway)
21:11:09 <armax> so enikanorov, it makes sense to demote this bug from high to low
21:11:16 <mestery> armax: And target Liberty-1 as well.
21:11:22 <sballe> o/
21:11:23 <armax> mestery: ya
21:11:26 <enikanorov> ok, since everyone knows now, I'd agree :)
21:11:33 <mestery> :)
21:11:54 <armax> done
21:12:23 <salv-orlando> armax: what do you mean by "sync down"?
21:12:35 <armax> talking about bugs, marun was going to file one that is tracking a breakage of the functional job
21:12:47 <marun> https://bugs.launchpad.net/neutron/+bug/1438426
21:12:48 <openstack> Launchpad bug 1438426 in neutron "Functional job setup broken by devstack" [Critical,New] - Assigned to Maru Newby (maru)
21:12:48 <armax> salv-orlando: down from oslo incubator to neutron
21:12:51 <marun> should be an easy fix
21:13:11 <marun> It's a good prompt to start pinning so it doesn't happen so easily
21:13:14 <armax> that’s the bug I was talking about
21:13:19 <salv-orlando> armax: ah ok... I was looking at it from the neutron side so it was a sync-up for me ;)
21:13:29 <mestery> Ha!
21:13:49 <mestery> OK, shall we move on to the rest of the agenda now?
21:13:59 <mestery> Lots of fun awaits!
21:14:02 <mestery> Lets move on
21:14:05 <mestery> #topic Docs
21:14:11 <emagana> Hello!
21:14:13 <mestery> emagana: How are the Kilo docs cmoing along?
21:14:36 <emagana> mestery: Moving Slow! We wanted to have more people involved on the networking guide
21:15:05 <mestery> #info Docs team would like more people involved in the networking guide
21:15:09 <emagana> If anyone is interested to contribute, please contact me!
21:15:20 <anteaya> emagana: have you considered having a docs sprint?
21:15:37 <mestery> anteaya: Good idea1
21:15:39 <anteaya> emagana: book the sprint irc channel and pick either a 24 hour or 48 window
21:15:39 <emagana> anteaya: That is a good idea!
21:15:57 <emagana> Can I ask here how many will be interested?
21:16:02 <emagana> Or Just over email?
21:16:03 <anteaya> put togehter an etherpad so that any fool who shows up can be useful and get the high priorities done
21:16:21 <anteaya> emagana: pick a date taht works for you and doesn't conflict with anything else major
21:16:21 <emagana> anteaya: Fine! Will send it out later today!
21:16:22 <mestery> anteaya: lol, "any fool"
21:16:23 <mestery> :)
21:16:25 <anteaya> and post to the email
21:16:44 <anteaya> at the very leaset you end up doing all the work which is no different than now
21:16:54 <anteaya> you might even get some non-neutron folks to help
21:17:00 <mestery> #action emagana to setup a docs sprint on the ML
21:17:04 <mestery> emagana: Action item!
21:17:15 <emagana> anteaya: :-)   Docs team is doing the hard work!
21:17:15 <anteaya> emagana: talk to me after and I'll help you book teh channel
21:17:25 <anteaya> emagana: tat is what always happens
21:17:35 <emagana> anteaya: sounds good!
21:18:18 <emagana> mestery: Nothing else form my side... but as always I would like to let anyone the opportunity to share about Docs
21:18:29 <mestery> emagana: Thank you sir!
21:18:44 <mestery> OK, lets move on now. 42 minutes left and we have some urgent items to cover.
21:18:49 <mestery> #topic Kilo-RC1 FF Specs
21:18:59 <mestery> Overall, we've done a good job of merging 6 of the 10 FFEs!
21:19:07 <mestery> I'd like to cover the 4 remiaing in order of difficultty
21:19:08 <mestery> :)
21:19:17 <mestery> #link https://blueprints.launchpad.net/neutron/+spec/restructure-l3-agent
21:19:29 <mestery> carl_baldwin: I think this one has 1 patch left and looks likely to land soon. Thoughts?
21:19:30 <kevinbenton> so is this the most or least difficult?
21:19:35 <mestery> kevinbenton: Least
21:20:01 <HenryG> I'll +2 that shortly, it's basically done
21:20:13 <mestery> HenryG: My thoughts exactly, I think we can merge the final patch.
21:20:18 <mestery> See, that one was easy!
21:20:20 <carl_baldwin> I think this one is doing pretty well.
21:20:37 <mestery> carl_baldwin: It should be in the merge queue soon it looks like
21:20:39 <mestery> OK next one
21:20:40 <mestery> #link https://blueprints.launchpad.net/neutron/+spec/ipv6-router
21:20:46 <mestery> HenryG: I think this one looks close too.
21:20:55 <HenryG> yup
21:21:03 <mestery> actually
21:21:08 <mestery> looks like carl_baldwin pushed it into the merge queue, woot!
21:21:22 <absubram> carl_baldwin: ty for that! :)
21:21:22 <HenryG> Thanks carl_baldwin !
21:21:29 <mestery> next up
21:21:30 <mestery> #link https://blueprints.launchpad.net/neutron/+spec/multiple-ipv6-prefixes
21:21:33 <mestery> HenryG: This one looks much more tenuous
21:21:36 <mestery> HenryG: Lots of patches left
21:21:52 <HenryG> It can be marked as completed, sort of
21:21:59 <mestery> lol
21:22:01 <mestery> Did the main patch merge?
21:22:04 <HenryG> yes
21:22:08 <mestery> woot!
21:22:15 <mestery> HenryG: Followup bugs for the remaining patches?
21:22:37 <HenryG> There is one other patch that would be nice to have, for "nicer to use"
21:22:56 <HenryG> But that can also be deferred to L if it is contentious
21:22:59 <mestery> HenryG: Link?
21:23:06 <salv-orlando> mestery: I have not reviewed this work... but the follow up patches should do cleanups of smooth issues
21:23:20 <mestery> salv-orlando: Cool, thanks for hte input!
21:23:28 <salv-orlando> if the follow up patches "complete" the feature by adding nice-to-have things, maybe it's better to defer
21:23:38 <mestery> HenryG: ^^^^
21:23:40 <HenryG> mestery: https://review.openstack.org/156360
21:23:44 <amotoki> HenryG: could you update the whiteboard per discussion here?
21:23:48 <mestery> I would agree with salv-orlando, if hte patches just smooth things then we can be done
21:23:51 <mestery> amotoki: ++
21:24:23 <HenryG> Yes, will update the whiteboard
21:24:36 <mestery> HenryG: OK, lets followup there, and see about deferring or marking as complete once we review that. Thanks!
21:24:51 <mestery> And now, the most difficult one left:
21:24:53 <mestery> #link https://blueprints.launchpad.net/neutron/+spec/subnet-allocation
21:25:00 <mestery> This one has spawned the API discussion on the ML
21:25:12 <mestery> SO, changing subject quick
21:25:19 <mestery> #topic API Discussion (core vs. extension)
21:25:21 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2015-March/060200.html
21:25:32 <mestery> amotoki: This is your item on the agenda I believe, thanks for starting this discussion
21:25:48 <dougwig> is this another debate, or can we just apply the policy decided for vlan/mtu and move on?
21:26:17 <mestery> dougwig: That seems sensible to me to be honest. carl_baldwin amotoki salv-orlando, thoughts?
21:26:30 <amotoki> mestery: yes. I just replied to the dev list and I am fine with the shim extension and keeping the code as-is.
21:26:41 <mestery> carl_baldwin: Sound ok for Kilo?
21:27:00 <salv-orlando> I think that from a "legal" perspective we should not add anything to core until a process for evolving the core has been approved
21:27:07 <carl_baldwin> My hands are busy at the moment.  Could someone summarize the vlan/mtu resulotion?
21:27:23 <amotoki> I can work with the empty/shim extension.
21:27:36 <salv-orlando> on the practical perspective, I believe that with a bit of common sense it should be easy to realize that subnetpools should be core
21:27:50 <salv-orlando> but then if someone brings the arguments like - why subnetpools and not mut?
21:27:53 <salv-orlando> sorry mtu
21:28:05 <salv-orlando> then I'd say... subnetpools should an extension too. period.
21:28:09 <mestery> I'm all for being practical to be honest
21:28:23 <mestery> I know hte authors of subnet pools have put in a lot of hard work
21:28:32 <kevinbenton> I think we might need a bi-weekly Neutron dev status that has ongoing feature development. Way to many people were surprised by too many things at the end of this cycle...
21:28:51 <mestery> kevinbenton: Next cycle, I plan to -2 all API changes in specs, that shoudl make things easier ;)
21:28:59 <kevinbenton> mestery: that works too
21:28:59 <mestery> kevinbenton: I jest of course
21:29:01 <mestery> kevinbenton: But you riase a good point
21:29:08 <mestery> But lets focus back on subnet pools now
21:29:11 <mestery> It's the issue at hand
21:29:13 <dougwig> mestery: too close to truth for a funny. :)
21:29:17 <salv-orlando> kevinbenton: because there are many moving parts it's natural. For instance a guy optimized subnet show and did not realize he probably screwed subnet-list ;)
21:29:59 <salv-orlando> mestery: yeah I think that's the best decision
21:30:13 <mestery> salv-orlando: Wait, waht was the best decision?
21:30:19 <salv-orlando> the API will not change anymore, forever and ever.
21:30:29 <mestery> salv-orlando: lol
21:30:48 <mestery> Seriously, amotoki has proposed the empty extension for this. carl_baldwin salv-orlando are you both ok with this?
21:30:49 <anteaya> salv-orlando: the celebrations have started
21:30:50 <salv-orlando> I think when we'll be in Vancouver you should go on whistler mountain, and then come back with the neutron API carved in stone
21:31:00 <salv-orlando> mestery: I am fine
21:31:02 <mestery> salv-orlando: Do I need a bear and some flowing robes?
21:31:03 <anteaya> it is a nice drive
21:31:05 <kevinbenton> it will just be a lisp interpreter
21:31:06 <mestery> beard
21:31:09 <mestery> although a bear would be funnier
21:31:10 <amotoki> as far as I looked the code, it is better to keep the main code as-is at this stage of dev cycle.
21:31:13 <anteaya> bears too
21:31:17 <markmcclain> salv-orlando: haha
21:32:02 <sc68cal> I bring you 15...... crash... 10 neutron core APIs
21:32:02 <mestery> OK, so lets move forward with that approach
21:32:27 <mestery> #info Add emptoy extension for subnet pools per amotoki's suggestion and move forward with this in Kilo
21:32:34 <carl_baldwin> I am okay with amotoki’s proposal
21:32:42 <mestery> carl_baldwin: Thanks!
21:33:09 <salv-orlando> cool, I will then resume the spec on "unifying" the core and exposing "features", and we'll move the discussion there
21:33:23 <mestery> salv-orlando: Yay!
21:33:29 <mestery> #topic Open Discussion
21:33:33 <mestery> That went much faster than I thought.
21:33:36 <salv-orlando> there won't be any summit session on this - mostly because I hope we've now realized how pointless those sessions are
21:33:37 <mestery> So, Open Discussion!
21:33:48 <mestery> lol
21:34:16 <kevinbenton> service chaining + naming the core/maintainers
21:34:37 <kevinbenton> more seriously, i'm wondering if there is a way we can move forward with ebtables
21:34:49 <mestery> kevinbenton: For Kilo? It seems unlikely at this stage of hte release
21:34:51 <kevinbenton> get the necessary config options and dependency stuff merged
21:34:57 <mestery> kevinbenton: For Liberty? Yes! Lets do it early!
21:34:58 <kevinbenton> but have it disabled
21:35:24 <salv-orlando> kevinbenton: what use would be that? ;)
21:35:44 <mestery> kevinbenton: Seriously, at this stage I don't think we should add ebtables back in. But for Liberty, yes, lets do it!
21:35:49 <kevinbenton> then the 'fixes' (i.e. the functionality) can be back-ported
21:36:04 <mestery> Did everyone see my email about proposing specs for Liberty that were proposed for Kilo but fialed to land code?
21:36:09 <mestery> It's an expedited procedure
21:36:14 <mestery> So, lets make use of it!
21:36:29 <pc_m> Can we talk about whether https://review.openstack.org/#/c/164466/ et al should go into the RC or defer to L? Have heard arguments on each side.
21:36:40 <salv-orlando> mestery: yes saw that.
21:36:44 <kevinbenton> right, but it just means as of Kilo, neutron shared networks can't be used :(
21:37:30 <mestery> kevinbenton: I don't know how we can realistically land this at this stage
21:37:39 <mestery> I think we'll look to cut the RC next week, we're that close to the end.
21:37:41 <Sukhdev> kevinbenton: what do you mean by shared networks can't be used?
21:37:43 * mestery says in an ominous voice
21:37:48 <salv-orlando> kevinbenton: do you reckon that we should consider merging that blueprint and deal with the concerns around its impl in Liberty?
21:38:03 <kevinbenton> Sukhdev: arp poisoning will still work just fine
21:38:21 <kevinbenton> Sukhdev: so basically if you have two tenants, they have to have complete trust in each other
21:38:30 <kevinbenton> Sukhdev: if they are on the same network
21:38:31 <salv-orlando> kevinbenton: everyone needs their poison. I get scotch, shared networks get ARP
21:38:53 <Sukhdev> salv-orlando :-)
21:38:55 <amotoki> kevinbenton: is it related to https://bugs.launchpad.net/neutron/+bug/1274034 ?
21:38:56 <openstack> Launchpad bug 1274034 in neutron "Neutron firewall anti-spoofing does not prevent ARP poisoning" [High,In progress] - Assigned to Juergen Brendel (jbrendel)
21:39:05 <kevinbenton> amotoki: yep
21:39:19 <salv-orlando> kevinbenton: what's your opiniopn about merging the current code?
21:39:22 <Sukhdev> kevinbenton: Thanks for clarification
21:39:24 <kevinbenton> amotoki: unfortunately iptables can't help, so an entire new filtering stack had to be integrated
21:39:25 <dougwig> maybe it's just me, but i don't see "shared" networks as being unusable if they're, umm, shared.
21:39:32 <ZZelle_> salv-orlando, the change is too large
21:39:44 <kevinbenton> dougwig: actually nova has been getting by fine with it for a long time
21:39:52 <kevinbenton> dougwig: because they have protection against this
21:40:07 <kevinbenton> salv-orlando: the whole chain is too big for this cycle
21:40:20 <mestery> kevinbenton: Which ones do you think we can land this cycle yet?
21:40:22 <amotoki> it has been open for multiple cycles and we need to focus on closing it... but the change is not small...
21:40:23 <mestery> kevinbenton: The framework pieces?
21:40:23 <dougwig> is this something that helps with using provider vlan's as the replacement for the nova-net vlan model, then?
21:40:25 <kevinbenton> salv-orlando: i was suggesting shipping all of the non-backportable components
21:40:29 <salv-orlando> ZZelle_, kevinbenton: I however do not see how we can have somehting fully functional without the whole chain
21:40:58 <kevinbenton> salv-orlando: yes, i was (gasp!) suggesting shipping a broken/disabled feature
21:41:09 <ZZelle_> salv-orlando, kevinbenton, the integration with neutron code is small so it can be merged in Lemmings and backport in Kilo
21:41:18 <ZZelle_> s/backport/backported/
21:41:27 <kevinbenton> ZZelle_: so there are a few things that can't backport like dependencies and config options
21:41:39 <markmcclain> not certain that's precedent we want to revive
21:41:40 <ZZelle_> kevinbenton, oups
21:41:41 <kevinbenton> that's why i was thinking we could push them this cycle
21:41:45 <salv-orlando> kevinbenton: I understand that the security concern might grant an exception to bring in more technical debt.
21:42:05 <salv-orlando> but I've spoke with markmcclain and marun before and I also understand their point
21:42:22 <salv-orlando> which markmcclain has brought up ;)
21:42:53 <kevinbenton> yeah, i suspect we will have to let it slide...
21:43:30 <marun> kevinbenton: so l2pop wasn't a solution in the end?
21:43:31 <kevinbenton> I will continue attempting to hack L2pop to eat these bad ARP requests to see if their is some kind of bandaid we can shit
21:43:34 <kevinbenton> ship*
21:43:35 <kevinbenton> whoops
21:43:41 <mestery> kevinbenton: lol
21:43:49 <markmcclain> kevinbenton: haha
21:43:57 <salv-orlando> It's a fine balance. I slightly tend to favour deferral, also because at the end of the day this was not perceived as a priority from operators, was it?
21:43:59 <kevinbenton> where is the '#strikefromlog' action
21:43:59 <mestery> kevinbenton: Your autocrrect knows you too well ;)
21:44:29 <salv-orlando> kevinbenton: that was intentional, at least if you have a qerty keyboard ;)
21:44:53 <kevinbenton> ok, i'm going to stop wasting open discussion time. i was just making one last grasp at straws
21:44:57 <dougwig> he might just have a really filthy auto-correct db
21:45:08 <mestery> kevinbenton: Thank you for caring :)
21:45:16 <kevinbenton> i will report results on l2pop hacking later
21:45:29 <mestery> #info kevinbenton to report details on l2pop hacking to avoid arp poisoning
21:45:39 <mestery> Any other bikes to paint or yaks to shave today?
21:45:44 <ZZelle_> speeking of security, is it possible for https://bugs.launchpad.net/neutron/+bug/1427228 to go into the RC? As it improves metadata proxy security (when enabled)
21:45:46 <openstack> Launchpad bug 1427228 in neutron "Allow to run neutron-ns-metadata-proxy as nobody" [Undecided,In progress] - Assigned to Cedric Brandily (cbrandily)
21:45:58 <sc68cal> mestery: how about linux bridge as the default for devstack
21:46:09 <mestery> sc68cal: it doesn't work as your patch shows!
21:46:23 <mestery> sc68cal: We need to fix it, likely in liberty unless the fixes are simple
21:46:38 <mestery> ZZelle_: Done!
21:46:44 <pc_m> mestery: Should https://review.openstack.org/#/c/164466/ go into RC or defer to Liberty? Heard mixed suggestions from cores. If we do now, there will be one mech for Kilo. If we defer, there will be two.
21:46:46 <dougwig> i know that devstack is pushing LB as the default.  are we all in favor of that as well?  i'm not sure i would've learned OVS if it wasn't shoved in front of me by default.
21:46:49 <ZZelle_> mestery, great
21:47:00 <anteaya> sc68cal: heh
21:47:08 <sc68cal> I think the main point is that we're trying to boil the frog
21:47:10 <mestery> pc_m: Looks like amotoki and HenryG are on board with it
21:47:11 <dougwig> plus, wouldn't that make the install guide and default devstack differ?
21:47:12 <sc68cal> on the holdouts to neutron
21:47:14 <salv-orlando> dougwig: rather than asking why linux bridge, I wonder why not OVS?
21:47:25 <salv-orlando> when did OVS become evil?
21:47:26 <pc_m> mestery: OK.
21:47:28 <mestery> sc68cal: AGreed, but given we're in the FF, I don't know what we can do around LB at this point.
21:47:30 <anteaya> sc68cal: oh can we not have that conversation now
21:47:44 <sc68cal> anteaya: yes, sorry :(
21:47:45 <anteaya> I see 15 minutes of my life wanting me back
21:47:46 <mestery> sc68cal: I agree wwe should get LB up to speed, but the timing is bad now :(
21:47:53 <mestery> sc68cal: FF and all, RC branch cutting, etc.
21:47:53 <dougwig> anteaya: lol
21:47:56 <dougwig> salv-orlando: agree
21:47:59 <mestery> sc68cal: Hoepfully the patches are easily backportable
21:48:29 <HenryG> mestery: But pc_m's patch must be followed by a couple more patches to be complete.
21:48:39 <kevinbenton> can someone give a quick summary? is it that devstack wants to default to linux bridge and we let the bridge rust for the past two cycles?
21:48:42 <mestery> HenryG: I marked the bug as RC1 so we can track it
21:48:48 <mestery> kevinbenton: yes
21:48:58 <dougwig> kevinbenton: aye.  the contention is that OVS is "too hard" for new users/users of nova-net.
21:48:59 <mestery> good summary there for not knowing hte issue
21:49:02 <pc_m> HenryG: Two, one is trivial, the other is also very simple.
21:49:04 <sc68cal> kevinbenton: sdague had a decent e-mail on the list laying out the reasoning
21:49:15 <sc68cal> i'll grab link
21:49:17 <HenryG> mestery: thanks. It's just leg work, and convincing armax :)
21:49:36 <mestery> HenryG: Let me work on armax
21:49:42 <sc68cal> http://lists.openstack.org/pipermail/openstack-dev/2015-March/060071.html
21:49:42 <armax> HenryG: everyone has a price
21:49:49 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2015-March/060071.html
21:50:05 <kevinbenton> it is a little concerning that the default will be an untested chunk of code... but i suspect I'm rewalking an already made argument here
21:50:11 <banix> as soon as we switch to LB we will be asked about nova-net parity!
21:50:34 <mestery> OK lets close thise one out
21:50:39 <amotoki> btw, how about neutronclient release? When is it scheduled? after merging RC1 BPs?
21:50:41 <anteaya> mestery: ++
21:50:43 <mestery> The ML is the right place for the rest of this discussion, please join in!
21:51:05 <mestery> amotoki: I was wondering the same, amuller had requested a release pre-kilo, but I was planning a post-kilo release.
21:51:10 <mestery> amotoki: Any preference?
21:51:14 <anteaya> please at least read the nova-net to neutron threads
21:51:33 <anteaya> your opinions are needed
21:51:40 <amotoki> mestery: my vote is after merging RC Bps. we canavoi more release :)
21:51:54 <amotoki> *can avoid*
21:51:59 <mestery> amotoki: Excellent, we're on the same page.
21:52:09 <mestery> #info mestery to role client relase post kilo BP finalizeation
21:52:17 <mestery> OK, thanks for coming this week folks1
21:52:20 <mestery> We're in the final push!
21:52:27 <dougwig> #endmeeting #endmeeting!
21:52:32 <mestery> Next week we'll likely look at summit sesison planning!
21:52:34 <mestery> Yay!
21:52:39 <mestery> See you all on the internets!
21:52:40 <mestery> #endmeeting