21:00:46 <mestery> #startmeeting networking
21:00:47 <openstack> Meeting started Mon Jul 20 21:00:46 2015 UTC and is due to finish in 60 minutes.  The chair is mestery. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:48 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:50 <openstack> The meeting name has been set to 'networking'
21:00:54 <tongli> o/
21:00:57 <mestery> #link https://wiki.openstack.org/wiki/Network/Meetings Agenda
21:01:03 <mestery> #topic Announcement
21:01:14 <mestery> #info Liberty-2 is next week
21:01:15 <mestery> #link https://wiki.openstack.org/wiki/Liberty_Release_Schedule
21:01:25 <ajmiller> Hi
21:01:39 <mestery> We've reached the 2/3 point (or 3/4 or 4/5, depending on if you count RC candidates and how many you count)
21:01:47 <mestery> Lets keep the review momentum going
21:02:15 <mestery> Lets move on to bugs now
21:02:16 <mestery> #topic Bugs
21:02:24 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1468433
21:02:25 <openstack> Launchpad bug 1468433 in neutron "Pre reference plugin code movement" [Critical,In progress] - Assigned to Henry Gessau (gessau)
21:02:27 <uvirtbot> Launchpad bug 1468433 in neutron "Pre reference plugin code movement" [Critical,In progress]
21:02:33 <mestery> HenryG has a DB patch left for this one and we can mark it as implemented
21:02:35 <Sam-I-Am> now i'm here...
21:03:02 <mestery> sc68cal: I see 2 bugs marked as "linuxbridge-gate-parity", want to cover those here?
21:03:12 <sc68cal> sure
21:03:14 <mestery> For reference
21:03:15 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1312016
21:03:16 <openstack> Launchpad bug 1312016 in neutron "nova libvirtError: Unable to add bridge brqxxx-xx port tapxxx-xx: Device or resource busy" [High,In progress] - Assigned to Darragh O'Reilly (darragh-oreilly)
21:03:17 <uvirtbot> Launchpad bug 1312016 in neutron "nova libvirtError: Unable to add bridge brqxxx-xx port tapxxx-xx: Device or resource busy" [High,In progress]
21:03:35 <mestery> sc68cal: Lets start with that one
21:03:48 <sc68cal> fix is here - https://review.openstack.org/193485
21:04:09 <sc68cal> so I think we're making very good progress
21:04:12 <mestery> #link https://review.openstack.org/193485
21:04:16 <mestery> sc68cal: Excellent!
21:04:22 <mestery> Next up is
21:04:23 <mestery> #link https://bugs.launchpad.net/neutron/+bug/1465837
21:04:24 <openstack> Launchpad bug 1465837 in neutron "Linux bridge: Dnsmasq is being passed None as an interface" [Medium,New] - Assigned to Sean M. Collins (scollins)
21:04:25 <uvirtbot> Launchpad bug 1465837 in neutron "Linux bridge: Dnsmasq is being passed None as an interface" [Medium,New]
21:04:28 <mestery> This one looks stalled a bit
21:04:39 <mestery> Is it still a blocker in any way?
21:04:57 <sc68cal> No, at this point it doesn't seem to trigger test failures
21:05:03 <mestery> Nice!
21:05:11 <mestery> Thanks sc68cal! Any other LB bugs we should be aware of?
21:05:15 <sc68cal> it does still emit errors in the logs, but the priority can probably be changed
21:05:31 <sc68cal> I just saw someone -2 a backport to kilo
21:05:40 <sc68cal> https://review.openstack.org/202845
21:06:09 <kevinbenton> I think that's just because Kilo is about to release
21:06:11 <mestery> sc68cal: Looks like you'll want to propose that one perhaps
21:06:13 <mestery> right
21:06:48 <sc68cal> ok - I will do that - once we get the kilo backports and 193485 merged we should have a very high pass rate
21:06:54 <sc68cal> and look into making the LB ci job voting
21:06:55 <mestery> sc68cal: Awesome!
21:07:00 * mestery nods in agreement
21:07:03 <Sam-I-Am> me likey all the lb stuff :)
21:07:05 <mestery> Any other bugs anyone wants to discuss here?
21:07:12 <john-davidge> #link https://bugs.launchpad.net/neutron/+bug/1471316
21:07:13 <openstack> Launchpad bug 1471316 in neutron "_get_subnetpool_id does not return None when a cidr is specified and a subnetpool_id isn't." [High,In progress] - Assigned to John Davidge (john-davidge)
21:07:26 <uvirtbot> Launchpad bug 1471316 in neutron "_get_subnetpool_id does not return None when a cidr is specified and a subnetpool_id isn't." [High,In progress]
21:07:28 <john-davidge> consensus seems to be coming round to a fix being needed
21:07:41 <mestery> Lots of fun discussion there john-davidge
21:07:56 <john-davidge> if we can get some positive reviews ont eh associated fix that would be great #link https://review.openstack.org/#/c/198437/
21:08:03 <mestery> #link https://review.openstack.org/#/c/198437/
21:08:24 <john-davidge> mestery: there sure is!
21:08:28 <mestery> john-davidge: I see 5 -1s, looks like before further review a re-spin might be needed
21:08:56 <mestery> john-davidge: We'll drive consensus in the review though, thanks for bringing this one up!
21:09:01 <mestery> Anything else from anyone?
21:09:09 <mestery> Bug related specifically
21:09:20 <john-davidge> mestery: The -1s are all about disagreeing with the premise rather than the implementation it seems
21:09:30 <mestery> john-davidge: Yes, agreed
21:09:44 <mestery> OK, lets move on in the agenda
21:09:45 <mestery> #topic Docs
21:09:48 <mestery> Sam-I-Am: Hi there!
21:09:53 <mestery> Sam-I-Am: I hear you ahve some updates for the team?
21:10:32 * mestery pokes Sam-I-Am to try and wake him up
21:10:43 <sc68cal> might be typing wall of text :)
21:10:55 <mestery> lol
21:11:25 <Sam-I-Am> hi there
21:11:35 <Sam-I-Am> too much going on at once
21:11:41 <Sam-I-Am> so here's whats up
21:12:05 <Sam-I-Am> seems like a lot of neutron docs are in the dev docs, but they should probably go in the networking guide
21:12:31 <Sam-I-Am> i suppose a lot of this was due to the ease of RST and not having to go through the docs review process, but the networking guide is RST and we're pretty lenient on content
21:12:52 <Sam-I-Am> so, do we want to audit the dev docs and see what should move to the networking guide?
21:13:12 <Sam-I-Am> similarly, should new docs consider the networking guide instead of devdocs if its more of an operational thing?
21:13:17 <amuller> Sam-I-Am: you mean the devref .rsts? like neutron/doc/source/devref/*?
21:13:31 <amuller> Sam-I-Am: the question is who is the audience
21:13:33 <amuller> developers or operators
21:13:37 <amuller> that should be the distinction
21:13:49 <russellb> amuller: +1
21:13:52 <sc68cal> +1
21:13:57 <amotoki> +1 for amuller
21:13:58 <russellb> there's certainly overlap at times
21:14:03 <Sam-I-Am> the stuff that ends up on docs.openstack.org/developer
21:14:04 <mestery> Also, what are we documenting? The reference implementation or the design and how to develop for neutron?
21:14:17 <sc68cal> I think in some cases we have features that land, are documented in devref, but need user focused docs to close the loop
21:14:31 <Sam-I-Am> ^ this
21:14:34 <mestery> The issue with conflating "Neutron, the platform" and "Neutron, the reference implementation" strikes again
21:14:38 <russellb> sorta kinda related ... are docs on using plugins other than ref impl fair game for the networking guide?
21:14:55 <mestery> russellb: Open Source ones, I'd say yes.
21:15:04 <mestery> russellb: Vendor ones, I lean no, and say docs should be in the vendor repos
21:15:09 <russellb> define open :)
21:15:12 <mestery> lol
21:15:17 <amotoki> in most cases developers write devref along with corresponding codes to help others (reviewers/developers) understand a feature.
21:15:20 <mestery> Open Source network virtualization solutions
21:15:33 <Sam-I-Am> i say for now the networking guide covers the reference stuff... we have lots of work to do there still.
21:15:40 <mestery> Sam-I-Am: +1000
21:15:47 <sc68cal> russellb: I think at the very least, networking guide should link to plugin docs (if they exist)
21:15:50 <mestery> And that leaves the things amuller is concerned about alone and safely in neutron devref
21:16:00 <kevinbenton> Why does open source matter in this case? From a user perspective wouldn't documenting as many solutions as possible be good?
21:16:03 <mestery> amuller: +1000 on that too
21:16:11 <russellb> sc68cal: yeah that's pretty low cost
21:16:21 <Sam-I-Am> the issue with third-party stuff is the docs have a tendency to go stale
21:16:33 <russellb> we're not actually far enough along in OVN for this to matter, but that's why i'm asking
21:16:34 <Sam-I-Am> we dont have as much control over it, nor do we know if its accurate
21:16:39 <mestery> kevinbenton: It matters because why should we be documenting vendor solitions in the networking guide? Who would be documenting those? Who would review them?
21:16:43 <mestery> Who would validate the documentation works?
21:16:43 <sc68cal> +1 - if someone wants to put their plugin stuff in the networking guide, we'd put them on the hook for keeping them updated - IMO
21:16:46 <mestery> Seems like a mess
21:17:16 <mestery> sc68cal: So you want to chase those people down?
21:17:23 <russellb> if you don't put that stuff there, you end up in first-class second-class citizen situation
21:17:25 <mestery> We already split out the code, we pull the docs back in? Makes no sense to me
21:17:29 <Sam-I-Am> sc68cal: how do we know if they're updated?
21:17:32 <sc68cal> mestery: hmm - good point
21:17:38 <kevinbenton> So we shouldn't document anything then
21:17:39 <salv-orlando> fwiw the same reason about commercial solution apply also to open source
21:17:43 <mestery> kevinbenton: +1000
21:17:47 <salv-orlando> depending on how loose that community is with neutron
21:17:53 <kevinbenton> Because we are pulling out the reference
21:18:09 <mestery> IF the doc team wants to take on documenting vendor plugins, I say let them have it
21:18:11 <kevinbenton> And a third party open source thing can be just as flaky as a vendor
21:18:14 <mestery> But who will they look to for reviews?
21:18:32 <mestery> I'd say this is a documentation team discussion at this point frankly
21:18:38 <Sam-I-Am> mestery: i think we're trying to un-vendor as much as possible, except in the config reference
21:18:39 <kevinbenton> The same thing applies to OVN, odl  and contrail
21:18:40 <regXboi> wait - are we saying that we are deprecating the networking guide?
21:18:41 <mestery> With participation by whoever wants to join in
21:18:46 <salv-orlando> I think kevinbenton has a point here. By pulling out the reference stuff every solution is equal wrt users, with the exception of upstream gating
21:18:59 <salv-orlando> kevinbenton: and HDN. Please do not forget HDN
21:19:11 <dougwig> it would be nice to know what plugins exist, what they do, how they differ, when you're making a deployment decision. right now, you're left wading through sales guys and false promises. i'm not advocating docs cover vendor stuff, but such an overview of "here's how you can run neutron" would be pretty spiffy.
21:19:13 <Sam-I-Am> regXboi: umm i hope not :)
21:19:26 <mestery> dougwig: That's a very slipper slope
21:19:26 <regXboi> Sam-I-Am: I hope not too...
21:19:34 <ZZelle_> regXboi, nope, just that doc should live in the right place
21:19:37 <dougwig> mestery: then bring a sled, and have fun!
21:19:39 <kevinbenton> regXboi: nah, just making a point that our division of what's in and out doesn't make much sense
21:19:40 <mestery> lol
21:19:53 <mestery> kevinbenton: I'm only saying the docs folks can make that decision
21:19:56 <mestery> we shouldn't be making it
21:20:00 <mestery> I've stated my opinion
21:20:02 <mestery> But it's not up to me
21:20:04 <sc68cal> Is perhaps just linking to other plugin docs from the NWG a good compromise?
21:20:10 <mestery> It's up to the core reveiwers on the networkign guide
21:20:11 <Sam-I-Am> dougwig: we dont mind listing various third-party options, but docs surely doesnt have the horsepower to make them awesome or keep them updated. we have enough trouble with vendor communication already.
21:20:24 <mestery> Sam-I-Am: That's another problem
21:20:37 <amotoki> docs team has this wiki page https://wiki.openstack.org/wiki/Documentation/VendorDrivers
21:20:38 <dougwig> Sam-I-Am: right, i'm really really not advocating that docs take that on. just a halfway daydream that it'd be a nice bit of info somewhere.
21:20:40 <Sam-I-Am> we'd need vendors to commit bodies
21:20:48 <amotoki> thought I am not sure it works now.
21:20:55 <salv-orlando> mestery: I think you
21:21:09 <mestery> salv-orlando: I think me too
21:21:11 <salv-orlando> are correct. It does not mapper how open source or integrated you are. If you are contributing to the doc stuff
21:21:17 <mestery> salv-orlando: +1000
21:21:36 <mestery> I absolutely abhor this saying now, but in this case it's true:
21:21:45 <mestery> "Code (and docs) are the coin of the realm."
21:22:01 <Sam-I-Am> so...
21:22:02 <armax> when we initially started the decomp this list  was put goether
21:22:02 <armax> https://github.com/openstack/neutron/blob/master/doc/source/devref/sub_projects.rst
21:22:14 <salv-orlando> it's not like documentating a neutron setup with some commercial backend appears in the networking guide is an heresy, is it?
21:22:14 <regXboi> mestery: rotfl, because I *know* how much that hurt
21:22:22 <mestery> regXboi: :)
21:22:27 <armax> can we add a link to the respective docs for each affiliated project?
21:22:42 <mestery> salv-orlando: Absolutely not! I don't know why we're bike shedding on it here though, we can do that on the review in the networking guide proper.
21:22:47 <armax> and cross reference this page with the networking docs?
21:22:57 <sc68cal> armax: +1
21:23:09 <mestery> armax: +0.5
21:23:28 <armax> armax: +0.1
21:23:31 <amuller> isn't this the place for that? https://www.openstack.org/marketplace/drivers/
21:23:34 <dougwig> in big(O) notation, mestery just gave armax a big fat zero.
21:23:37 <amuller> for a list of drivers
21:24:07 <Sam-I-Am> if you have to pay for it, the people you have to pay should be documenting it and housing the docs, imo
21:24:15 <regXboi> so.... we are now thinking of pointing to devrefs from the networking guide?
21:24:16 <mestery> dougwig: I'd never give armax a big fat zero, 0.5 was to reference he mostly has my buy-in but I reserve judgement to backpedal later
21:24:19 <Sukhdev> I like the progression form +1 to +0.1 :-)
21:24:25 <kevinbenton> Dougwig: In big O these are all zero :)
21:24:29 <Sam-I-Am> regXboi: no
21:24:29 <mestery> Sam-I-Am: Stop bringing reason into this
21:24:29 <dougwig> mestery: eh, i was pulling legs.
21:24:30 <mestery> :)
21:24:39 <Sam-I-Am> mestery: you're welcome?
21:24:41 <mestery> Sukhdev: :P
21:24:41 <regXboi> Sam-I-Am: that's the answer I wanted to hear :)
21:24:44 <mestery> Sam-I-Am: lol :)
21:25:02 <dougwig> kevinbenton: i think most are '1', actually, with a few zeroes, and a hint of an 'n' way earlier.
21:25:17 <mestery> #info Everyone is encouraged to submit patches to the networking guide for the drivers and plugins which will be reviewed by the networking guide core reviewer team
21:25:26 <Sam-I-Am> regXboi: the original topic was - if it seems admin/oper/user oriented, it should go into the appropriate docs (which is most likely the networking guide for y'all)
21:25:48 <sc68cal> mestery: ouch. that might melt the docs team down
21:26:09 <Sam-I-Am> devref has been path of least resistance for a lot of projects because it doesnt involve docbook or the docs team
21:26:12 <regXboi> Sam-I-Am: I'm fully on board with that - it makes me wonder if DocImpact needs some teasing apart :(
21:26:18 <russellb> Sam-I-Am: "review" could be, "keep your stuff isolated to its own section and bit rot is your problem"
21:26:51 <russellb> Sam-I-Am: though i wouldn't worry much until someone actually shows up with patches ...
21:27:01 <kevinbenton> russellb: +1. It keeps a consistent experience for users on where to find documentation
21:27:24 <mestery> russellb: Heh :)
21:27:56 <Sam-I-Am> we saw what impact the scenarios in the networking guide had on a few things, so adding more docs there is hopefully going to make things even better for the project
21:28:51 <Sam-I-Am> pretty sure if we audited devref we'd find stuff we could move (or keep from getting stale in devref)
21:28:54 <Sam-I-Am> for example... http://docs.openstack.org/developer/neutron/devref/layer3.html
21:28:58 <Sam-I-Am> we have lots better diagrams in the networking guide
21:29:04 <Sam-I-Am> and users will stumble upon this stuff
21:29:30 <mestery> Sam-I-Am: Would you be willing to audit devref and provide an update next week?
21:30:04 <Sam-I-Am> mestery: sure, although it might take 2 meeting cycles
21:30:21 <mestery> Sam-I-Am: No worries, we're a volunteer organization which runs on unicorn tears, so 2 cycles is just fine
21:30:27 <Sam-I-Am> haha
21:30:42 <mestery> :)
21:30:48 <Sam-I-Am> so, i think we're clear on the original topic?
21:30:50 <regXboi> unicorn tears?
21:30:56 <mestery> Sam-I-Am: Yes, I hope
21:31:17 <salv-orlando> is it indigo, then?
21:31:20 <Sam-I-Am> a) audit devref b) if something needs docs, anything not dev-specific should go into networking guide
21:31:26 <Sam-I-Am> the docs team doesnt bite
21:31:34 <mestery> Sam-I-Am: Ack
21:31:41 <amuller> Sam-I-Am: some of the content could be split up so the more conceptual stuff could move to the networking guide, then an .rst in devref could link to that conceptual overview / introduction and spell out more developer oriented details
21:31:50 <amuller> (I'm looking at https://review.openstack.org/#/c/150918/2/doc/source/devref/router_high_availability.rst as an example)
21:31:59 <regXboi> amuller: +1
21:32:03 <Sam-I-Am> amuller: we could do that
21:32:54 <Sam-I-Am> amuller: it'll be a process, but at least we can start in that direction
21:33:09 <mestery> OK, I think we've got a direction
21:33:12 * mestery hopes no one asks which direction
21:33:16 <Sam-I-Am> up
21:33:17 <mestery> Shall we move on in the agenda?
21:33:19 <mestery> lol
21:33:21 <Sam-I-Am> yes
21:33:26 <regXboi> mestery: dead horse browning motion :)
21:33:29 <mestery> Sam-I-Am: Thanks for an exciting update! It's been a while since we've had a docs update that exciting
21:33:38 <Sam-I-Am> woot
21:33:42 <mestery> OK, lets move, I need to poke kevinbenton a bit next
21:33:42 <Sam-I-Am> maybe there will be more :)
21:33:43 <regXboi> er *brownianing*
21:33:49 <mestery> #topic pecan wsgi work
21:33:50 <kevinbenton> Lol
21:33:55 <mestery> kevinbenton: :)
21:33:58 <mestery> #link https://review.openstack.org/#/q/project:openstack/neutron+branch:feature/pecan+status:open,n,z
21:34:02 <mestery> That's the reveiw link for the pecan patches
21:34:09 <mestery> Thanks to blogan and salv-orlando (among others) for their reviews there
21:34:13 <mestery> kevinbenton: How is it coming along?
21:34:33 <kevinbenton> mestery: i need to check the latest, but we were sort of starved for reviews
21:34:50 <mestery> kevinbenton: I think salv-orlando dropped in and laid down the heavy fire for you recently
21:34:51 <kevinbenton> mestery: blogan got us 1 +2
21:35:23 <kevinbenton> mestery: ok. If I can enslave him then we should be able to pick up the pace
21:35:28 <mestery> lol
21:35:35 <mestery> thanks for your work here kevinbenton and blogan
21:35:39 <russellb> looks like it needs another rev?  after an update i'd be happy to review that series
21:35:48 <mestery> russellb: Sweet! Tahnks for the help!
21:36:07 <salv-orlando> mestery, russellb: frankly I believe we should merge back as soon as we have functional parity
21:36:14 <mestery> salv-orlando: +1000
21:36:21 <russellb> +1
21:36:22 <regXboi> salv-orlando: +max_int
21:36:25 <russellb> sounds like a nightmare to maintain
21:36:31 <salv-orlando> kevinbenton has done a good job. It's not perfect, but it's better then what we have now
21:36:54 <kevinbenton> salv-orlando: let's not get out of control here :)
21:36:54 <mestery> OK, so lets see if we can things merged back ASAP
21:36:55 <salv-orlando> I mean why would we question about replacing a shaky wsgi home grown framework that only a few of us know how it works
21:36:58 <blogan> mestery, kevinbenton: i'll be able to do more work/reviews on it the end of this week
21:37:00 <salv-orlando> there's not even devref for it
21:37:07 <kevinbenton> What I have do e is duck taped together
21:37:22 <mestery> kevinbenton: The previous version was stuck together with Scotch tape
21:37:23 <mestery> :)
21:37:34 <salv-orlando> kevinbenton has ported bit and bobs from the old framework but at least it's all implemented as pecan hooks and controllers
21:37:35 <blogan> and baby tears
21:37:36 * regXboi tries to resist obvious duck puns
21:37:47 <salv-orlando> so you know what you're talking about at least
21:37:50 <mestery> lol
21:37:57 <kevinbenton> I'll work on a devref to help explain how the current patches work
21:38:04 <mestery> kevinbenton: Excellent!
21:38:08 <kevinbenton> And I'm on pto right now
21:38:16 <kevinbenton> So it won't happen until Monday next week
21:38:18 <mestery> kevinbenton: That's why you're only working 40 hours lately! :)
21:38:19 <salv-orlando> kevinbenton: you're too young for PTO
21:38:35 <russellb> kevinbenton: you're bad at PTO
21:38:39 <mestery> Anything else on pecan?
21:38:42 <dougwig> says the european, who likely gets 40 weeks off per year.
21:38:43 <kevinbenton> Neutron has aged me 20 years
21:38:49 <mestery> rofl
21:38:57 <russellb> kevinbenton: goes for all of openstack i think
21:39:06 <Sam-I-Am> kevinbenton: drinking returns your youth
21:39:12 <mestery> That's our new team motto! "Join Neutron and add 20 years to your looks!"
21:39:14 <mestery> I think it'll work
21:39:14 <russellb> i got gray hair from openstack
21:39:15 <Sam-I-Am> also, welcome to open sores
21:39:45 <Sam-I-Am> russellb: a gray beard just means you can be grumpy about everything and get away with it
21:39:49 <armax> russellb: I have no hair left
21:39:52 <armax> russellb: luck you
21:39:55 <russellb> :)
21:39:56 <armax> *
21:39:57 <armax> lucky
21:39:57 <mestery> lol
21:40:02 <russellb> yeah now i'm just a grumpy old unix beard
21:40:08 <salv-orlando> dougwig: 40 weeks off + national public holidays of course
21:40:13 * mestery thinks about a kickstart for Rogain for armax
21:40:21 <mestery> *kickstarter
21:40:26 <armax> mestery: I tried, it doens’t work
21:40:26 <Sam-I-Am> i think the neutron meetings at vancouver caused my appendix to want out
21:40:27 <sc68cal> Sam-I-Am sacrificed an internal organ on the altar of openstack
21:40:29 <mestery> lol
21:40:33 <kevinbenton> Once we reach pecan parity, we will have some decisions to make about extension backwards compatibility
21:40:39 <Sam-I-Am> sc68cal: yeah, that
21:40:51 <kevinbenton> If we ever want to get rid of huge piles of dictionaries
21:41:16 * salv-orlando kevinbenton wants to start a yak shaving session
21:41:19 <mestery> :)
21:41:20 <kevinbenton> https://twitter.com/ktbenton/status/623245923678695424
21:41:23 * salv-orlando goes and grabs shears
21:41:25 <blogan> sounds like a good old fashioned dictionary burning is neded
21:41:39 <mestery> kevinbenton: I think you just broke the fourth wall
21:41:50 <mestery> #link https://en.wikipedia.org/wiki/Fourth_wall
21:41:54 <mestery> OK
21:41:55 <mestery> lets move on
21:42:00 <mestery> before we cross dimensions
21:42:12 <mestery> #topic Remove the Use of Shell From Neutron
21:42:17 <mestery> regXboi: you're at bat
21:42:18 * regXboi wakes up
21:42:22 <mestery> Also: Is anyone AGAINST this?
21:42:28 <salv-orlando> nope let's not do that. We might end up in a dimensions where we're actually productive. nightmare!!!
21:42:30 * mestery never knows
21:42:34 <mestery> salv-orlando: rofl
21:42:37 <Sam-I-Am> haha
21:42:39 <regXboi> I hope nobody is against this
21:42:39 <dougwig> long live csh!
21:42:41 <dougwig> oh wait.
21:42:49 <salv-orlando> mestery: that's what we've always aimed for isn't it
21:42:50 <regXboi> the question is how to break it up
21:42:51 <Sam-I-Am> dougwig: who has the gray beard?
21:43:02 <amuller> Removing shell? Oh my, last time I tried converting some of our testing bash scripts to Python I got two -2's
21:43:04 <salv-orlando> and otherwis_ has done that already for calls to ovsdb
21:43:09 <mestery> salv-orlando: We have grand aspirations and perspirations indeed
21:43:14 <mestery> regXboi: Please explain
21:43:22 <armax> amuller: I don’t think this is what regXboi is after
21:43:23 <salv-orlando> mestery: from the summits I know a lot about both
21:43:27 <mestery> amuller: It's about adding pyroute2 support to ip_lib
21:43:31 <amuller> armax: I gathered :(
21:43:32 <regXboi> folks - we've got experience with python with shell scaling poorly
21:43:34 <mestery> salv-orlando: lol
21:43:51 <regXboi> so the idea was to identify the uses of shell and see if we could replace them with direct python
21:43:51 <dougwig> i just ran "rm /bin/sh", and now my computer is broken. so, i am against removing it.
21:43:55 <armax> regXboi: I thought that rootwrap daemon helped with that quite a bit
21:43:58 <Sam-I-Am> dougwig: haha
21:44:01 <regXboi> armax: not really
21:44:04 * mestery takes dougwig's laptop away
21:44:12 <salv-orlando> regXboi: no news to us I think, we had a few mailing list threads in the past, especially on rootwrap limitations
21:44:23 <regXboi> so - we've already got a patch for Ryu
21:44:31 <regXboi> and I'm proposing a set of patches for pyroute2
21:44:40 <mestery> regXboi: +1000.5
21:44:41 <salv-orlando> but as armax said we were hoping the rootwrap daemon would remove a lot of the overhead
21:44:48 <armax> regXboi: how so, I remember seeing numbers that were impressive, but don’t mind me, I am happy to get rid of shelling out for other reasons
21:44:49 <amuller> regXboi: are you seeing performance issues with using 'ip', in the L3 agent?
21:44:49 <regXboi> and seeing if we can pull some of the missing ovs calls into the Ryu patch
21:44:52 * sc68cal thinks of all the brctl calls
21:45:12 <Sam-I-Am> sc68cal: aaaaaaaaaaa
21:45:13 <ZZelle_> regXboi, how to run_as_root without shell?
21:45:14 <regXboi> amuller: the issues we saw were with ip, bridge and brctl - all three
21:45:25 <kevinbenton> Is gus around??
21:45:28 <dougwig> that daemon is really just a different implementation of removing the forks. so i'm not hearing any objections in principle.
21:45:30 <amuller> regXboi: in LB or L3 agent?
21:45:49 <regXboi> amuller: in LB and L3 both
21:45:50 * sc68cal is looking at https://pypi.python.org/pypi/pybrctl/0.1.1
21:46:11 <amuller> regXboi: Do you have a PoC working with some benchmarking showing the diff?
21:46:19 <kevinbenton> Angus Lees already had a patch for root wrap daemon using ip lib
21:46:32 <mestery> amuller: I think regXboi is talking at scale here too (regXboi, correct me if I'm wrong)
21:46:35 <otherwis_> pybrctl just wraps CLI anyway.
21:46:36 <sc68cal> bah, it uses shell under the covers.
21:46:36 <kevinbenton> Privsep daemon
21:46:38 <regXboi> mestery: yes
21:46:40 <mestery> scale meaning size of deployment
21:46:46 <armax> yay to yet another library in the reqs list!
21:46:47 <mestery> sc68cal: Of course it does! :)
21:46:53 <mestery> armax: We're doing our part
21:47:12 <regXboi> sc68cal: yeah I looked at it until I found that
21:47:23 <regXboi> amuller: not yet
21:47:24 <otherwis_> kevinbenton: yeah. I thought I heard him say something about making it an oslo project at some point?
21:47:36 <kevinbenton> https://review.openstack.org/#/c/155631/
21:47:39 <salv-orlando> anyway, I think amuller was asking about details which might enable us to pinpoint bottlenecks, and I would like to see that before suggesting solutions as well
21:47:57 <amuller> salv-orlando: I'm asking because I'm trying to figure out if I care about this or not :)
21:48:09 <regXboi> so folks - has anybody done a security audit on this beast?
21:48:16 <otherwis_> it seems like it would be a good fit for the rootwrap project. Maybe do whitelists of python classes/functions/modules/whatever instead of CLI programs/args?
21:48:18 <kevinbenton> otherwis_: yes, he already benchmarked it and showed huge improvements
21:48:19 <regXboi> running shell is going to raise flags
21:48:32 <otherwis_> kevinbenton: good to hear.
21:48:46 <armax> regXboi: but that would happen all acraoss the gigantic openstack circus
21:48:50 <kevinbenton> regXboi: please sync up with gus when he is online
21:48:54 <armax> openstack *is* a wrapper around bash
21:49:07 <armax> if I really want to be extreme in my definition
21:49:13 <kevinbenton> regXboi: he is working with the oslo team
21:49:14 <ajo_> Yeah, I think rootwrap support for api calls would be a good way. Or just a thread with separate privilege level..
21:49:21 <mestery> armax: EVen on a vSphere Hypervisor?
21:49:23 <salv-orlando> armax: and libvirt. bash and libvirt, libvirt and bash
21:49:26 <russellb> parts of network integration at least :)
21:49:32 <regXboi> kevinbenton: what TZ is gus in so I can plan to be around/awake?
21:49:37 <ajo_> lol armax ;)
21:49:42 <Sam-I-Am> regXboi: australia
21:49:45 <ajo_> hi, btw ;)
21:49:47 <regXboi> ouch
21:49:49 <mestery> ajo_: Please stop taking vacation advice from kevinbenton and return to PTO :)
21:49:50 <armax> please do not quote me on it
21:49:51 <kevinbenton> regXboi: sydney
21:49:52 <armax> I don’t want to get sued
21:50:11 <kevinbenton> Most of the l2 agent can be handled with pyroute
21:50:26 <mestery> Note: 10 minutes left
21:50:29 <regXboi> kevinbenton: that was the thought
21:50:32 <mestery> kevinbenton: ++
21:50:32 <salv-orlando> kevinbenton: l2? pyroute wraps also iptables?
21:50:38 <ajo_> mestery, lol :) I wanted to sync a bit while the sea breeze blows on me :)
21:50:52 <regXboi> salv-orlando: iptables is the exception - afaik, there is no api
21:50:55 <mestery> ajo_: You need to post a twitter picture with your view, tag it neutron meeting and link it here like kevinbenton
21:51:00 * regXboi grumbles about that fact
21:51:09 <mestery> regXboi: It's an oppurtunity is what it is
21:51:19 <kevinbenton> salv-orlando: don't poke holes in my words
21:51:28 <mestery> OK
21:51:30 <mestery> Lets move on
21:51:33 <mestery> #topic Open Discussion
21:51:34 <kevinbenton> :)
21:51:37 <armax> regXboi: there are othe system interactions that have no API avaialble
21:51:40 <otherwiseguy> iptables: https://github.com/ldx/python-iptables
21:51:46 <dougwig> that last bit was pretty much already an open discussion.
21:51:47 <ajo_> hehehe mestery , just 2 minutes ;)
21:51:49 <mestery> Note: We can continue painting the shell bike shed here too
21:52:07 <otherwiseguy> python-iptables says it uses the C library
21:52:08 <kevinbenton> armax: right, gus's approach was move as many into native APIs as possible
21:52:09 <mestery> dougwig: Exactly my point, though I'm slow on the uptake due to lack of sleep lately
21:52:17 <mestery> otherwiseguy: What is the license for python-iptables?
21:52:24 <armax> kevinbenton: right
21:52:32 <ZZelle_> salv-orlando, what is the status about micro-versioning?
21:52:33 <dougwig> regXboi: i doubt the security argument will get much traction, because openstack has such a soft and gooey center. but reducing context switches at scale is a pretty big deal, if we've got them in a common execution path.
21:52:33 <armax> but I wouldn’t want to use random libraries
21:52:33 <regXboi> armax: then we leave them as shell
21:52:48 <otherwiseguy> If it links with iptables C library, I assume something compatible with that. :)
21:52:53 <salv-orlando> ZZelle_: I am trying to figure out how to make it works together with current extension, as an alternative
21:52:59 <armax> so I wonder if that will result into writing all these wrappers ourselves
21:53:00 <salv-orlando> and working on top of the pecan framework
21:53:01 <mestery> dougwig: The image of openstack as soft and gooey makes me laugh
21:53:05 <regXboi> kevinbenton: that's exactly where I'm thinking, so I'll go sync with him
21:53:10 <armax> when we had the universal wrapper being root-wrapper!
21:53:16 <otherwiseguy> python-iptables is Apache 2.0
21:53:34 <mestery> otherwiseguy: thanks :)
21:53:41 <salv-orlando> ZZelle_: I agree to not make an abrupt switch from extensions to version, but roll in versioning as experimental so that it can be evaluated first as an alternative
21:54:01 <salv-orlando> only once is proven to be a working solution, a freeze on extensions will be declared
21:54:02 <ZZelle_> salv-orlando, ah, great
21:54:27 <dougwig> salv-orlando: this is openstack. don't we freeze the old thing before the new one is working?
21:54:36 <armax> the license is not the only criteria to evaluate a library
21:54:37 <armax> IMO
21:55:01 <sc68cal> before I forget, here was the artifact from the fwaas work at the SEA midcycle - http://lists.openstack.org/pipermail/openstack-dev/2015-July/069784.html
21:55:02 <kevinbenton> Right, we also have to check if it uses tabs instead of spaces
21:55:12 <otherwiseguy> Since we're talking about moving everything to python libs...does that mean we get to drop the ovs-vsctl implementation of ovs interface?
21:55:14 * ajo_ thinks of mock library... and how nice they are with updates..
21:55:14 <mestery> armax: I agree, but since this is openstack, it's one of the most critical
21:55:24 <mestery> #link http://lists.openstack.org/pipermail/openstack-dev/2015-July/069784.html
21:55:31 <mestery> sc68cal: Just because we needed another shed to paint today?
21:55:46 <amuller> otherwiseguy: I think that's blocked by the ovs python lib not being py3 compat
21:55:49 <sc68cal> mestery: I have a lot of stock in a shed manufacturing company
21:56:02 <otherwiseguy> amuller: lets say we fix that... :D
21:56:10 <mestery> sc68cal: lol
21:56:17 <amuller> otherwiseguy: first let's switch the default
21:56:18 <regXboi> otherwiseguy: I'd like to see if we could as part of the ryu patch
21:56:20 <salv-orlando> dougwig: actually in openstack the tradition is to do one thing and its exact opposite at the same time
21:56:57 <otherwiseguy> There are some atomicity issues with our vif stuff that I could easily fix with the native interface, but not so much vsctl (without writing c code).
21:57:06 <salv-orlando> ajo_: to be fair with mock devs they've been fixing bugs that openstack projects have been abusing (more or less deliberately)
21:57:24 <ajo_> salv-orlando, then we just deserved it ;)
21:57:30 <otherwiseguy> I tried to work around it, but it ended up requiring a change to nova (which I have a patch for too, but if we can just drop vsctl implementation soon...)
21:57:58 <kevinbenton> When did we decide that we are using ryu?
21:58:14 <kevinbenton> Is there some discussion about  why?
21:58:17 <mestery> kevinbenton: We haven't
21:58:18 <salv-orlando> kevinbenton: I think we're talking about ofagent?
21:58:23 <mestery> salv-orlando: +1.5
21:58:32 <mestery> OK
21:58:34 <regXboi> kevinbenton: we haven't, but there is a patch to use it out there
21:58:42 <mestery> lets wrap this thing up, put a steak in it, and call it rare
21:58:44 <mestery> Thanks folks!
21:58:46 <mestery> Remember
21:58:51 <salv-orlando> adieuuuu
21:58:55 <mestery> Liberty-2 is next week :)
21:58:56 <regXboi> oom
21:58:57 <mestery> #endmeeting