21:00:46 #startmeeting networking 21:00:47 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:50 The meeting name has been set to 'networking' 21:00:54 o/ 21:00:57 #link https://wiki.openstack.org/wiki/Network/Meetings Agenda 21:01:03 #topic Announcement 21:01:14 #info Liberty-2 is next week 21:01:15 #link https://wiki.openstack.org/wiki/Liberty_Release_Schedule 21:01:25 Hi 21:01:39 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 Lets keep the review momentum going 21:02:15 Lets move on to bugs now 21:02:16 #topic Bugs 21:02:24 #link https://bugs.launchpad.net/neutron/+bug/1468433 21:02:25 Launchpad bug 1468433 in neutron "Pre reference plugin code movement" [Critical,In progress] - Assigned to Henry Gessau (gessau) 21:02:27 Launchpad bug 1468433 in neutron "Pre reference plugin code movement" [Critical,In progress] 21:02:33 HenryG has a DB patch left for this one and we can mark it as implemented 21:02:35 now i'm here... 21:03:02 sc68cal: I see 2 bugs marked as "linuxbridge-gate-parity", want to cover those here? 21:03:12 sure 21:03:14 For reference 21:03:15 #link https://bugs.launchpad.net/neutron/+bug/1312016 21:03:16 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 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 sc68cal: Lets start with that one 21:03:48 fix is here - https://review.openstack.org/193485 21:04:09 so I think we're making very good progress 21:04:12 #link https://review.openstack.org/193485 21:04:16 sc68cal: Excellent! 21:04:22 Next up is 21:04:23 #link https://bugs.launchpad.net/neutron/+bug/1465837 21:04:24 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 Launchpad bug 1465837 in neutron "Linux bridge: Dnsmasq is being passed None as an interface" [Medium,New] 21:04:28 This one looks stalled a bit 21:04:39 Is it still a blocker in any way? 21:04:57 No, at this point it doesn't seem to trigger test failures 21:05:03 Nice! 21:05:11 Thanks sc68cal! Any other LB bugs we should be aware of? 21:05:15 it does still emit errors in the logs, but the priority can probably be changed 21:05:31 I just saw someone -2 a backport to kilo 21:05:40 https://review.openstack.org/202845 21:06:09 I think that's just because Kilo is about to release 21:06:11 sc68cal: Looks like you'll want to propose that one perhaps 21:06:13 right 21:06:48 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 and look into making the LB ci job voting 21:06:55 sc68cal: Awesome! 21:07:00 * mestery nods in agreement 21:07:03 me likey all the lb stuff :) 21:07:05 Any other bugs anyone wants to discuss here? 21:07:12 #link https://bugs.launchpad.net/neutron/+bug/1471316 21:07:13 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 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 consensus seems to be coming round to a fix being needed 21:07:41 Lots of fun discussion there john-davidge 21:07:56 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 #link https://review.openstack.org/#/c/198437/ 21:08:24 mestery: there sure is! 21:08:28 john-davidge: I see 5 -1s, looks like before further review a re-spin might be needed 21:08:56 john-davidge: We'll drive consensus in the review though, thanks for bringing this one up! 21:09:01 Anything else from anyone? 21:09:09 Bug related specifically 21:09:20 mestery: The -1s are all about disagreeing with the premise rather than the implementation it seems 21:09:30 john-davidge: Yes, agreed 21:09:44 OK, lets move on in the agenda 21:09:45 #topic Docs 21:09:48 Sam-I-Am: Hi there! 21:09:53 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 might be typing wall of text :) 21:10:55 lol 21:11:25 hi there 21:11:35 too much going on at once 21:11:41 so here's whats up 21:12:05 seems like a lot of neutron docs are in the dev docs, but they should probably go in the networking guide 21:12:31 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 so, do we want to audit the dev docs and see what should move to the networking guide? 21:13:12 similarly, should new docs consider the networking guide instead of devdocs if its more of an operational thing? 21:13:17 Sam-I-Am: you mean the devref .rsts? like neutron/doc/source/devref/*? 21:13:31 Sam-I-Am: the question is who is the audience 21:13:33 developers or operators 21:13:37 that should be the distinction 21:13:49 amuller: +1 21:13:52 +1 21:13:57 +1 for amuller 21:13:58 there's certainly overlap at times 21:14:03 the stuff that ends up on docs.openstack.org/developer 21:14:04 Also, what are we documenting? The reference implementation or the design and how to develop for neutron? 21:14:17 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 ^ this 21:14:34 The issue with conflating "Neutron, the platform" and "Neutron, the reference implementation" strikes again 21:14:38 sorta kinda related ... are docs on using plugins other than ref impl fair game for the networking guide? 21:14:55 russellb: Open Source ones, I'd say yes. 21:15:04 russellb: Vendor ones, I lean no, and say docs should be in the vendor repos 21:15:09 define open :) 21:15:12 lol 21:15:17 in most cases developers write devref along with corresponding codes to help others (reviewers/developers) understand a feature. 21:15:20 Open Source network virtualization solutions 21:15:33 i say for now the networking guide covers the reference stuff... we have lots of work to do there still. 21:15:40 Sam-I-Am: +1000 21:15:47 russellb: I think at the very least, networking guide should link to plugin docs (if they exist) 21:15:50 And that leaves the things amuller is concerned about alone and safely in neutron devref 21:16:00 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 amuller: +1000 on that too 21:16:11 sc68cal: yeah that's pretty low cost 21:16:21 the issue with third-party stuff is the docs have a tendency to go stale 21:16:33 we're not actually far enough along in OVN for this to matter, but that's why i'm asking 21:16:34 we dont have as much control over it, nor do we know if its accurate 21:16:39 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 Who would validate the documentation works? 21:16:43 +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 Seems like a mess 21:17:16 sc68cal: So you want to chase those people down? 21:17:23 if you don't put that stuff there, you end up in first-class second-class citizen situation 21:17:25 We already split out the code, we pull the docs back in? Makes no sense to me 21:17:29 sc68cal: how do we know if they're updated? 21:17:32 mestery: hmm - good point 21:17:38 So we shouldn't document anything then 21:17:39 fwiw the same reason about commercial solution apply also to open source 21:17:43 kevinbenton: +1000 21:17:47 depending on how loose that community is with neutron 21:17:53 Because we are pulling out the reference 21:18:09 IF the doc team wants to take on documenting vendor plugins, I say let them have it 21:18:11 And a third party open source thing can be just as flaky as a vendor 21:18:14 But who will they look to for reviews? 21:18:32 I'd say this is a documentation team discussion at this point frankly 21:18:38 mestery: i think we're trying to un-vendor as much as possible, except in the config reference 21:18:39 The same thing applies to OVN, odl and contrail 21:18:40 wait - are we saying that we are deprecating the networking guide? 21:18:41 With participation by whoever wants to join in 21:18:46 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 kevinbenton: and HDN. Please do not forget HDN 21:19:11 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 regXboi: umm i hope not :) 21:19:26 dougwig: That's a very slipper slope 21:19:26 Sam-I-Am: I hope not too... 21:19:34 regXboi, nope, just that doc should live in the right place 21:19:37 mestery: then bring a sled, and have fun! 21:19:39 regXboi: nah, just making a point that our division of what's in and out doesn't make much sense 21:19:40 lol 21:19:53 kevinbenton: I'm only saying the docs folks can make that decision 21:19:56 we shouldn't be making it 21:20:00 I've stated my opinion 21:20:02 But it's not up to me 21:20:04 Is perhaps just linking to other plugin docs from the NWG a good compromise? 21:20:10 It's up to the core reveiwers on the networkign guide 21:20:11 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 Sam-I-Am: That's another problem 21:20:37 docs team has this wiki page https://wiki.openstack.org/wiki/Documentation/VendorDrivers 21:20:38 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 we'd need vendors to commit bodies 21:20:48 thought I am not sure it works now. 21:20:55 mestery: I think you 21:21:09 salv-orlando: I think me too 21:21:11 are correct. It does not mapper how open source or integrated you are. If you are contributing to the doc stuff 21:21:17 salv-orlando: +1000 21:21:36 I absolutely abhor this saying now, but in this case it's true: 21:21:45 "Code (and docs) are the coin of the realm." 21:22:01 so... 21:22:02 when we initially started the decomp this list was put goether 21:22:02 https://github.com/openstack/neutron/blob/master/doc/source/devref/sub_projects.rst 21:22:14 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 mestery: rotfl, because I *know* how much that hurt 21:22:22 regXboi: :) 21:22:27 can we add a link to the respective docs for each affiliated project? 21:22:42 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 and cross reference this page with the networking docs? 21:22:57 armax: +1 21:23:09 armax: +0.5 21:23:28 armax: +0.1 21:23:31 isn't this the place for that? https://www.openstack.org/marketplace/drivers/ 21:23:34 in big(O) notation, mestery just gave armax a big fat zero. 21:23:37 for a list of drivers 21:24:07 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 so.... we are now thinking of pointing to devrefs from the networking guide? 21:24:16 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 I like the progression form +1 to +0.1 :-) 21:24:25 Dougwig: In big O these are all zero :) 21:24:29 regXboi: no 21:24:29 Sam-I-Am: Stop bringing reason into this 21:24:29 mestery: eh, i was pulling legs. 21:24:30 :) 21:24:39 mestery: you're welcome? 21:24:41 Sukhdev: :P 21:24:41 Sam-I-Am: that's the answer I wanted to hear :) 21:24:44 Sam-I-Am: lol :) 21:25:02 kevinbenton: i think most are '1', actually, with a few zeroes, and a hint of an 'n' way earlier. 21:25:17 #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 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 mestery: ouch. that might melt the docs team down 21:26:09 devref has been path of least resistance for a lot of projects because it doesnt involve docbook or the docs team 21:26:12 Sam-I-Am: I'm fully on board with that - it makes me wonder if DocImpact needs some teasing apart :( 21:26:18 Sam-I-Am: "review" could be, "keep your stuff isolated to its own section and bit rot is your problem" 21:26:51 Sam-I-Am: though i wouldn't worry much until someone actually shows up with patches ... 21:27:01 russellb: +1. It keeps a consistent experience for users on where to find documentation 21:27:24 russellb: Heh :) 21:27:56 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 pretty sure if we audited devref we'd find stuff we could move (or keep from getting stale in devref) 21:28:54 for example... http://docs.openstack.org/developer/neutron/devref/layer3.html 21:28:58 we have lots better diagrams in the networking guide 21:29:04 and users will stumble upon this stuff 21:29:30 Sam-I-Am: Would you be willing to audit devref and provide an update next week? 21:30:04 mestery: sure, although it might take 2 meeting cycles 21:30:21 Sam-I-Am: No worries, we're a volunteer organization which runs on unicorn tears, so 2 cycles is just fine 21:30:27 haha 21:30:42 :) 21:30:48 so, i think we're clear on the original topic? 21:30:50 unicorn tears? 21:30:56 Sam-I-Am: Yes, I hope 21:31:17 is it indigo, then? 21:31:20 a) audit devref b) if something needs docs, anything not dev-specific should go into networking guide 21:31:26 the docs team doesnt bite 21:31:34 Sam-I-Am: Ack 21:31:41 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 (I'm looking at https://review.openstack.org/#/c/150918/2/doc/source/devref/router_high_availability.rst as an example) 21:31:59 amuller: +1 21:32:03 amuller: we could do that 21:32:54 amuller: it'll be a process, but at least we can start in that direction 21:33:09 OK, I think we've got a direction 21:33:12 * mestery hopes no one asks which direction 21:33:16 up 21:33:17 Shall we move on in the agenda? 21:33:19 lol 21:33:21 yes 21:33:26 mestery: dead horse browning motion :) 21:33:29 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 woot 21:33:42 OK, lets move, I need to poke kevinbenton a bit next 21:33:42 maybe there will be more :) 21:33:43 er *brownianing* 21:33:49 #topic pecan wsgi work 21:33:50 Lol 21:33:55 kevinbenton: :) 21:33:58 #link https://review.openstack.org/#/q/project:openstack/neutron+branch:feature/pecan+status:open,n,z 21:34:02 That's the reveiw link for the pecan patches 21:34:09 Thanks to blogan and salv-orlando (among others) for their reviews there 21:34:13 kevinbenton: How is it coming along? 21:34:33 mestery: i need to check the latest, but we were sort of starved for reviews 21:34:50 kevinbenton: I think salv-orlando dropped in and laid down the heavy fire for you recently 21:34:51 mestery: blogan got us 1 +2 21:35:23 mestery: ok. If I can enslave him then we should be able to pick up the pace 21:35:28 lol 21:35:35 thanks for your work here kevinbenton and blogan 21:35:39 looks like it needs another rev? after an update i'd be happy to review that series 21:35:48 russellb: Sweet! Tahnks for the help! 21:36:07 mestery, russellb: frankly I believe we should merge back as soon as we have functional parity 21:36:14 salv-orlando: +1000 21:36:21 +1 21:36:22 salv-orlando: +max_int 21:36:25 sounds like a nightmare to maintain 21:36:31 kevinbenton has done a good job. It's not perfect, but it's better then what we have now 21:36:54 salv-orlando: let's not get out of control here :) 21:36:54 OK, so lets see if we can things merged back ASAP 21:36:55 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 mestery, kevinbenton: i'll be able to do more work/reviews on it the end of this week 21:37:00 there's not even devref for it 21:37:07 What I have do e is duck taped together 21:37:22 kevinbenton: The previous version was stuck together with Scotch tape 21:37:23 :) 21:37:34 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 and baby tears 21:37:36 * regXboi tries to resist obvious duck puns 21:37:47 so you know what you're talking about at least 21:37:50 lol 21:37:57 I'll work on a devref to help explain how the current patches work 21:38:04 kevinbenton: Excellent! 21:38:08 And I'm on pto right now 21:38:16 So it won't happen until Monday next week 21:38:18 kevinbenton: That's why you're only working 40 hours lately! :) 21:38:19 kevinbenton: you're too young for PTO 21:38:35 kevinbenton: you're bad at PTO 21:38:39 Anything else on pecan? 21:38:42 says the european, who likely gets 40 weeks off per year. 21:38:43 Neutron has aged me 20 years 21:38:49 rofl 21:38:57 kevinbenton: goes for all of openstack i think 21:39:06 kevinbenton: drinking returns your youth 21:39:12 That's our new team motto! "Join Neutron and add 20 years to your looks!" 21:39:14 I think it'll work 21:39:14 i got gray hair from openstack 21:39:15 also, welcome to open sores 21:39:45 russellb: a gray beard just means you can be grumpy about everything and get away with it 21:39:49 russellb: I have no hair left 21:39:52 russellb: luck you 21:39:55 :) 21:39:56 * 21:39:57 lucky 21:39:57 lol 21:40:02 yeah now i'm just a grumpy old unix beard 21:40:08 dougwig: 40 weeks off + national public holidays of course 21:40:13 * mestery thinks about a kickstart for Rogain for armax 21:40:21 *kickstarter 21:40:26 mestery: I tried, it doens’t work 21:40:26 i think the neutron meetings at vancouver caused my appendix to want out 21:40:27 Sam-I-Am sacrificed an internal organ on the altar of openstack 21:40:29 lol 21:40:33 Once we reach pecan parity, we will have some decisions to make about extension backwards compatibility 21:40:39 sc68cal: yeah, that 21:40:51 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 :) 21:41:20 https://twitter.com/ktbenton/status/623245923678695424 21:41:23 * salv-orlando goes and grabs shears 21:41:25 sounds like a good old fashioned dictionary burning is neded 21:41:39 kevinbenton: I think you just broke the fourth wall 21:41:50 #link https://en.wikipedia.org/wiki/Fourth_wall 21:41:54 OK 21:41:55 lets move on 21:42:00 before we cross dimensions 21:42:12 #topic Remove the Use of Shell From Neutron 21:42:17 regXboi: you're at bat 21:42:18 * regXboi wakes up 21:42:22 Also: Is anyone AGAINST this? 21:42:28 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 salv-orlando: rofl 21:42:37 haha 21:42:39 I hope nobody is against this 21:42:39 long live csh! 21:42:41 oh wait. 21:42:49 mestery: that's what we've always aimed for isn't it 21:42:50 the question is how to break it up 21:42:51 dougwig: who has the gray beard? 21:43:02 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 and otherwis_ has done that already for calls to ovsdb 21:43:09 salv-orlando: We have grand aspirations and perspirations indeed 21:43:14 regXboi: Please explain 21:43:22 amuller: I don’t think this is what regXboi is after 21:43:23 mestery: from the summits I know a lot about both 21:43:27 amuller: It's about adding pyroute2 support to ip_lib 21:43:31 armax: I gathered :( 21:43:32 folks - we've got experience with python with shell scaling poorly 21:43:34 salv-orlando: lol 21:43:51 so the idea was to identify the uses of shell and see if we could replace them with direct python 21:43:51 i just ran "rm /bin/sh", and now my computer is broken. so, i am against removing it. 21:43:55 regXboi: I thought that rootwrap daemon helped with that quite a bit 21:43:58 dougwig: haha 21:44:01 armax: not really 21:44:04 * mestery takes dougwig's laptop away 21:44:12 regXboi: no news to us I think, we had a few mailing list threads in the past, especially on rootwrap limitations 21:44:23 so - we've already got a patch for Ryu 21:44:31 and I'm proposing a set of patches for pyroute2 21:44:40 regXboi: +1000.5 21:44:41 but as armax said we were hoping the rootwrap daemon would remove a lot of the overhead 21:44:48 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 regXboi: are you seeing performance issues with using 'ip', in the L3 agent? 21:44:49 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 sc68cal: aaaaaaaaaaa 21:45:13 regXboi, how to run_as_root without shell? 21:45:14 amuller: the issues we saw were with ip, bridge and brctl - all three 21:45:25 Is gus around?? 21:45:28 that daemon is really just a different implementation of removing the forks. so i'm not hearing any objections in principle. 21:45:30 regXboi: in LB or L3 agent? 21:45:49 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 regXboi: Do you have a PoC working with some benchmarking showing the diff? 21:46:19 Angus Lees already had a patch for root wrap daemon using ip lib 21:46:32 amuller: I think regXboi is talking at scale here too (regXboi, correct me if I'm wrong) 21:46:35 pybrctl just wraps CLI anyway. 21:46:36 bah, it uses shell under the covers. 21:46:36 Privsep daemon 21:46:38 mestery: yes 21:46:40 scale meaning size of deployment 21:46:46 yay to yet another library in the reqs list! 21:46:47 sc68cal: Of course it does! :) 21:46:53 armax: We're doing our part 21:47:12 sc68cal: yeah I looked at it until I found that 21:47:23 amuller: not yet 21:47:24 kevinbenton: yeah. I thought I heard him say something about making it an oslo project at some point? 21:47:36 https://review.openstack.org/#/c/155631/ 21:47:39 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 salv-orlando: I'm asking because I'm trying to figure out if I care about this or not :) 21:48:09 so folks - has anybody done a security audit on this beast? 21:48:16 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 otherwis_: yes, he already benchmarked it and showed huge improvements 21:48:19 running shell is going to raise flags 21:48:32 kevinbenton: good to hear. 21:48:46 regXboi: but that would happen all acraoss the gigantic openstack circus 21:48:50 regXboi: please sync up with gus when he is online 21:48:54 openstack *is* a wrapper around bash 21:49:07 if I really want to be extreme in my definition 21:49:13 regXboi: he is working with the oslo team 21:49:14 Yeah, I think rootwrap support for api calls would be a good way. Or just a thread with separate privilege level.. 21:49:21 armax: EVen on a vSphere Hypervisor? 21:49:23 armax: and libvirt. bash and libvirt, libvirt and bash 21:49:26 parts of network integration at least :) 21:49:32 kevinbenton: what TZ is gus in so I can plan to be around/awake? 21:49:37 lol armax ;) 21:49:42 regXboi: australia 21:49:45 hi, btw ;) 21:49:47 ouch 21:49:49 ajo_: Please stop taking vacation advice from kevinbenton and return to PTO :) 21:49:50 please do not quote me on it 21:49:51 regXboi: sydney 21:49:52 I don’t want to get sued 21:50:11 Most of the l2 agent can be handled with pyroute 21:50:26 Note: 10 minutes left 21:50:29 kevinbenton: that was the thought 21:50:32 kevinbenton: ++ 21:50:32 kevinbenton: l2? pyroute wraps also iptables? 21:50:38 mestery, lol :) I wanted to sync a bit while the sea breeze blows on me :) 21:50:52 salv-orlando: iptables is the exception - afaik, there is no api 21:50:55 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 regXboi: It's an oppurtunity is what it is 21:51:19 salv-orlando: don't poke holes in my words 21:51:28 OK 21:51:30 Lets move on 21:51:33 #topic Open Discussion 21:51:34 :) 21:51:37 regXboi: there are othe system interactions that have no API avaialble 21:51:40