21:00:23 #startmeeting networking 21:00:24 hello 21:00:27 Meeting started Mon Jun 22 21:00:23 2015 UTC and is due to finish in 60 minutes. The chair is armax. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:28 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:30 Hi! 21:00:30 The meeting name has been set to 'networking' 21:00:32 Hi all 21:00:38 salv-orlando: mahalo 21:00:55 mestery is coming up 21:01:24 o/ 21:01:31 o/ 21:01:36 I heard mestery is initiating the docker community to the fine arts of yak shaving and bike shedding 21:01:44 o/ 21:01:49 #agenda https://wiki.openstack.org/wiki/Network/Meetings 21:02:03 #link https://wiki.openstack.org/wiki/Network/Meetings agenda 21:02:18 salv-orlando: he is 21:02:28 but his laptop can’t boot2docker well 21:02:42 lol 21:02:53 o/ 21:03:15 #chair mestery 21:03:15 Current chairs: armax mestery 21:03:26 * armax goes to snoring 21:03:30 armax: that because your employer makes the laptop you use 21:03:41 salv-orlando: you know that I don’t work for Apple 21:03:44 o/ 21:03:51 * mestery wanders in 21:03:53 that was some excellent kool aid! 21:03:53 Almost too good .... 21:03:55 OK 21:04:03 #topic Announcements 21:04:07 I bow to my my master 21:04:07 #link https://wiki.openstack.org/wiki/Liberty_Release_Schedule 21:04:12 Liberty-1 is this week 21:04:16 That happened fast 21:04:32 mestery: next time keep in mind cool-aid for you - not others :-) 21:04:39 Given we're doing "lazy consensus" release management now, we'l see what landed in Liberty-1 ... once we tag Liberty-1! 21:04:53 Sukhdev__: That's a valid point. :) 21:05:09 Does anyone know if the IPAM work landed all the way in-tree yet? 21:05:28 mestery: not yet, it is moving along though 21:05:33 salv-orlando carl_Baldwin: ^^^^ 21:05:37 johnbelamaric: yay! 21:05:44 #link http://docs.openstack.org/developer/neutron/policies/blueprints.html#neutron-request-for-feature-enhancements RFE Process 21:05:59 The drivers team is shooting to reivew all (old-style) specs by this week 21:06:11 And we'll be completely in the land of RFEs moving forward (with no deadlines) 21:06:12 mestery: yeah, breaking it into lots of small patches - hope to get as much merged as possible before Wed. then I will be at mid-cycle to see if we can land the rest 21:06:23 johnbelamaric: Excellent, thank you! 21:06:53 #info The mid-cycle is this week (Wed-Fri) 21:06:55 #link https://etherpad.openstack.org/p/neutron-liberty-mid-cycle 21:07:06 I look forward to seeing many of you there! 21:07:18 +1 21:07:25 #info The QoS mid-cyclce is fast approaching 21:07:27 #link https://etherpad.openstack.org/p/neutron-liberty-qos-code-sprint 21:07:30 * mestery waves to carl_baldwin 21:07:53 carl_baldwin: I hope you're ready for a bunch of rowdy Neutron developers to descend on HP in Fort Collins 21:07:53 :) 21:07:55 * carl_baldwin sorry to be late, didn’t notice IRC was not connected. 21:08:26 We’ve got pads up on the walls and plenty of gloves. 21:08:44 and i connected some hoses this morning... all set 21:09:05 rofl 21:09:17 it's colorado. i'm expecting a keg of red bull and a punchbowl of weed. 21:09:23 * mestery mumbles something about a bike and some yaks 21:09:31 red bull... hmmm.. 21:09:34 * salv-orlando should have gone 21:09:36 Fat Tire 21:09:39 lol 21:09:41 FAT TIRE! 21:09:42 OMG! 21:09:44 yes! 21:09:51 OK 21:09:55 any other announcements not related to Fat Tire or Neutron for the team? 21:10:07 best ... meeting ... ever 21:10:08 you guys signed up for the brewery tour(s) 21:10:10 dougwig: so perhaps it should be fat tire and a punchbowl of weed 21:10:11 ? 21:10:11 lol 21:10:24 I think we've jumped the shark at this poont 21:10:26 *point 21:10:37 * sc68cal has never been so excited for a neutron midcycle 21:10:39 Lets move on before dougwig and salv-orlando move us further into debauchery 21:10:42 * dougwig suppresses any more off-topic comments. 21:10:53 #topic Bugs 21:10:57 mestery: you were about to write "we've jumpet the shark at this pot" - weren't you? 21:11:05 salv-orlando: Guilty! 21:11:11 armax has some info on the unstable job and pymsql 21:11:15 armax: Link? 21:11:28 Also: kevinbenton can't be here today but he's been working hard on this as well 21:11:32 mestery: http://lists.openstack.org/pipermail/openstack-dev/2015-June/066735.html 21:11:34 I know, I sat next to the two of them at breakfast 21:11:42 #link http://lists.openstack.org/pipermail/openstack-dev/2015-June/066735.html 21:11:52 mestery: I’ve just sent an update to the ML 21:12:06 mestery: might take a minute or two to populate everyone’s inbox 21:12:17 armax: Thanks! Do you have a tl;dr summary for the team? 21:12:21 sure 21:12:44 in a nutshell the unstable job is up and running 21:12:58 I have identified the most recurring failure modes 21:13:20 nice work. 21:13:22 kevinbenton: has an initial fix, we’ll have to experiment a bit more once more data points are available 21:13:50 no actual fix has merged yet 21:14:04 I suspect we’ll have to play with this a tad bit longer 21:14:06 dougwig: I already bought them breakfast, lets not let it go to their heads :) 21:14:29 mestery: it was a very fancy breakfast 21:14:35 lol 21:14:37 I feel privileged 21:14:39 anyhoo 21:14:46 Thansk for the update armax 21:14:46 anyone willing to wade into the quagmire of neutron bugs deserves all the kudos we can muster. 21:14:52 one more thing 21:15:27 once we manage to go back to sanity, we’ll have both pymysql and multiple api workers available in tree 21:15:47 knowing that we reverted teh latter right before kilo was cut, I suppose that’s a good thing 21:15:53 mestery: done 21:16:00 * armax back to snorin 21:16:06 thanks armax! 21:16:23 Any other bugs the team should be aware of as we enter the "Liberty-1 tag zone" this week? 21:17:23 #topic Docs 21:17:25 emagana: hi there! Anything for the team this week? 21:17:37 Hi There! 21:17:43 I am back.. still sleepy but back! 21:17:53 :) 21:18:14 Just to inform that the neutron-docs meeting has moved from weekly to bi-weekly 21:18:25 still same day and time 21:18:40 #info Neutron-docs meeting is now bi-weekly 21:18:50 no much to report since we have not had a meeting the last two weeks :-( 21:19:01 emagana: when is the next meeting? this week? 21:19:11 yes, this week. This Friday. 21:19:53 Excellent! Any documentation questions from the team? 21:19:56 I noticed the "Agents" API extension (admin only) is not documented in the API guide. 21:20:29 HenryG: Egads! 21:20:47 HenryG: is that the only one? 21:21:14 Not sure. I shoudl go through them all and check. 21:21:20 HenryG: Is there a bug for that one? 21:21:21 I think the last time I checked I counted more than one. 21:21:43 mestery: give me an AI to file bugs for missing API guides 21:21:45 HenryG: Can you file bugs for all the missing ones? 21:21:58 #action HenryG to file bugs for all missing API extensions in the documentation 21:22:05 ty 21:22:08 HenryG and salv-orlando: Help us by sending me bugs for this and I can help fixing it or getting some extra hands from the rest of the docs team 21:22:36 emagana: sure thing 21:22:46 emagana: thanks 21:22:48 HenryG: ;-) 21:22:55 teamwork: It's what's for dinner ;) 21:23:00 Thanks emagana HenryG salv-orlando! 21:23:37 OK 21:23:38 lets move on 21:23:46 #topic Release models for networking-foo projects 21:23:53 I put this on teh agenda 21:24:08 The tl;dr is that networking-foo projects should follow semantic versioning 21:24:14 Like the servers and the rest of OpenStack do 21:24:23 I've created patches for the various repos to do this 21:24:23 #link https://review.openstack.org/#/q/topic:semver-releases+owner:%22Kyle+Mestery%22,n,z 21:24:32 Note that some are WIP if they've already released to PyPi 21:24:54 #info Before releasing your networking-foo project, please contact mestery or dhellmann so we can put in a pre-version tag to make pbr happy 21:25:12 Any questions from anyone? 21:25:17 Especially a networking-foo maintainer? 21:25:37 mestery: can you quickly tell me why you put in wip the patches for projects already on pypi? 21:25:48 I'm too lazy to check it out myself and have to fix vmware-nsx 21:26:29 salv-orlando: Absoluitely 21:27:03 For those ones, we wanted to wait to merge them until the projects did a release. I'm surprised some of them passed Jenkins to be honest. 21:27:10 They had been failing (or some of them). 21:27:42 salv-orlando: make sense? It almost does to me ;) 21:27:49 mestery: cool. so the point is that you have to release first before switching to semver? 21:28:14 salv-orlando: No, we'll switch to semver before we release 21:28:29 For those who have already released, we need to add a cap into requirements (dhellmann has more info) 21:29:17 Any other questions? 21:29:56 mestery: all clear thanks 21:30:12 awesome! 21:30:13 Moving along 21:30:23 #topic Pecan Reviews 21:30:27 * mestery waits for salv-orlando to share a link of actual pecan nut reviews 21:30:31 #link https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:feature/pecan+topic:bp/wsgi-pecan-switch,n,z 21:30:39 kevinbenton (who is not here) has been hard at working splitting these patches out 21:30:46 He's looking for reviews 21:30:51 to start merging these 21:30:54 so we can collapse the branch back during Liberty-2 21:31:34 I know blogan has been reviewing these (thanks!) 21:31:49 yes i have! 21:31:50 * armax wakes up 21:31:51 mestery: I am testing those, at some point I will pst a review as well. 21:31:51 mestery: I promised him I was going to go over those 21:32:02 salv-orlando: awesome, armax, also awesome 21:32:07 I’ve been slow as usual 21:32:12 armax: Just stop sleeping this week and you'll have plenty of time 21:32:25 armax: I know…it’s the change of the season 21:32:42 its been raining here a lot, easy to sleep 21:32:57 OK, lets see what kind of damage we can do there. 21:33:05 OK 21:33:07 next up: 21:33:14 #topic Should We Translate All The Strings 21:33:17 #link https://review.openstack.org/#/c/185300/ 21:33:23 I have no idea who put this on the agenda 21:33:24 Does anyone? 21:33:54 Was this form last week? 21:34:13 mestery: idk I have no opinion. No maybe I have one: MEH 21:34:18 kevinbenton added it 21:34:23 based on his comment in the review 21:34:34 mestery: but this is a great topic for bikeshedding you know? 21:34:41 sc68cal: thanks! And kevinbenton isn't even here! 21:35:16 So, can someone give me the tl;dr on this issue so I select my color in the argument? 21:35:37 my hunch would be it’s an I18N topic 21:36:15 I guess we can leave it on the agenda for next week so kevinbenton can have his air time here :) 21:36:17 +1 21:36:22 +1 21:36:38 isn't this an openstack-wide quesiton anyway? 21:36:40 and tell us which color he likes better 21:36:51 russellb: It seems to be, yeah. 21:36:55 yeah.. 21:37:00 russellb: Do you know if there is any stance on this at that level? 21:37:22 if there's not a written convention yet, someone should drive one :) 21:37:37 I think we should discuss the implication of a neutron-only decision on the rest of openstack projects and what would be the cross interference with i18n. 21:37:54 sounds like a good topic for cross project meeting though 21:37:58 perhaps we need a working group. a translation working group where we can discuss all the issue pertaning which strings should be translate 21:38:14 and volunteers actually translating 21:38:23 russellb: +1 21:38:25 xgerman: +100 21:38:38 but in all seriousness, why do we need to worry about having a policy to define which strings get translated? 21:38:39 #action kevinbenton to propose a cross-project meeting agenda item around translations 21:38:41 That should cover it 21:38:50 there's already a i18n team 21:38:51 when we have so many pressing problems, I love it that we take every item so seriously 21:38:58 * armax is so proud 21:39:02 there may even be some standards around this, i just don't know off hand 21:39:41 Me either 21:39:46 We'll ahve kevinbenton take the lead on this 21:40:09 mestery: and if he does not deliver, I want his head on a silver plate! 21:40:14 that'll show him for being AFK 21:40:23 :) 21:40:28 Well, to be fair, I did buy him breakfast, so he owes me one 21:40:29 :) 21:40:35 apparently kevinbenton is going to china soon 21:40:47 I think the core team should be bit like game of thrones. That would be interesting. 21:40:55 the bikeshedding timer has been running for too many minutes on this one... 21:41:02 my last name is *NOT* stark 21:41:05 salv-orlando: that could be taken a couple ways 21:41:08 #topic Open Discussion 21:41:23 The floor is open, we have 19 minutes or so left. 21:41:34 * russellb dances 21:41:45 so my top worry is the flavor framework 21:41:48 May i ask to help to get further discussion about "Security Group Logging" and other objects logging #link https://review.openstack.org/#/c/132134/ 21:41:59 xgerman: As it should be 21:42:06 xgerman: What is the current implementation status? 21:42:09 Does it need reviews? 21:42:16 We are going to implement logging API as kevinbenton sugguest 21:42:20 xgerman: he's been blocked on me, and it also needs other reviews. 21:42:27 I glimpsed it 21:42:28 dougwig +1 21:42:31 we should be able to make some progress at the meetup. 21:42:32 sc68cal: you ok with that from hoangcx ? 21:42:44 dougwig: awesome 21:42:47 it seems in need of a bit of TLC 21:43:02 I love it all right ;-) 21:43:13 we need more discussion on this to get approve :) 21:43:15 As long as it's a separate API endpoint, LGTM 21:43:38 * sc68cal finds himself defending Amazon APIs .... for some reason 21:43:39 Yes. Thanks sc68cal. I will contact you 21:43:44 * armax wonders if sc68cal is serious 21:43:49 actually serious 21:43:53 :) 21:44:04 armax: like I said at the summit, anything for you :) 21:44:10 sc68cal is like the AWS warrior inside of OpenStack! 21:44:19 * sc68cal shudders in horror 21:44:22 sc68cal: yeah why? I think we've already diverged so much from EC2 that this defence is a bit pointless now 21:44:47 salv-orlando: Have we? I know we still have Boto tests that use the EC2 API modules 21:44:48 don’t they all connect at the docker API 21:44:53 \me hides 21:44:53 sc68cal: I know armax as some peculiar tastes. you should really shidder. 21:45:24 sc68cal: well, that's for the compute part. look at security groups. is there a thing like INGRESS or EGRESS rules in EC2? 21:45:37 salv-orlando: I like you don’t i? 21:45:41 salv-orlando: I think for the VPC flavored version of SG 21:45:46 salv-orlando: there is 21:45:51 xgerman: it's pluggable! 21:46:10 mestery: put an action item for me for that, since i opened my big mouth - research variances in our SG api compared to AWS 21:46:23 sc68cal: so we're amazon compatible if one runs VPC but only to the point that you get APIs that semantically work like Amazon's... 21:46:28 #action sc68cal to research and present on variances in our SG API compared to AWS 21:46:33 sc68cal: done and done sir! 21:46:37 but it's not like you can really do anything in neutron with your amazon EC2 client APP 21:47:16 sc68cal: I understand your point. And I would totally agree with you if we were declaring some sort of VPC compatibility 21:47:24 salv-orlando: Depends - there may still be some scaffolding that "get-me-a-network" will help paper over what admins are probably doing today ( creating all the networks, subnets, routers, etc) 21:47:37 but the SG API hopefully isn't different 21:48:12 there may be some items that need to be provisioned before the app devs who are using the EC2 libs can start working 21:48:17 you had to mention "get me a network" didn't you :) 21:48:34 * sc68cal gets $1 USD when he mentions his boss' spec or rally 21:48:39 lol 21:48:52 lol 21:49:02 haleyb: Speaking of that, did my comments in the review convince you to be the new official owner? 21:49:15 ok so you do have a goal of making an openstack deployment running neutron work with boto or any other EC2 client for the benefit of all the folks that don't care about neutron? 21:49:34 mestery: did you get my beer demand? 21:49:46 comeon sc68cal, shave this yak with me! 21:49:53 haleyb: I'm happy to buy you as much Fat Tire is required, yes. 21:49:54 salv-orlando: :) 21:50:12 * mestery hands salv-orlando a blue paint brush and sc68cal a red paint brush 21:50:19 Continuing the Nova/Neutron VIF type saga, Neutron folk may want to look at https://review.openstack.org/#/c/193668/, which is Dan Berrange's new (and good, IMO) attempt to sort this out... 21:50:23 mestery: so we want a purple shed eh? 21:50:40 * haleyb can do it, will need help filling-in some of the details in the spec 21:50:57 Even though this is currently only a Nova spec, it will have non-trivial Neutron impact. 21:50:58 haleyb: thanks :) 21:51:13 salv-orlando: I think my goal is just anything that is an API that came from AWS, should stay like the AWS API, and OpenStack should create new compelling APIs to supercede the AWS apis 21:51:14 neiljerram: thanks! 21:51:23 #link https://review.openstack.org/#/c/193668/ 21:51:31 sc68cal: if you want to achieve this goal, we also need a strategy to ensure EC2 compatibility is perpetual, and that strategy in my opinion depends on how nova moves forward. Because the boto user does not even care about neutron APIs. that kind of users expects EC2-compatible APIs on the nova API endpoint, I think 21:51:44 #link https://github.com/jaypipes/os_vif 21:51:52 neiljerram: in regards to VIF plugging, see the above from jaypipes as well 21:52:07 mestery: Indeed, I have; thanks. 21:52:15 neiljerram: great! :) 21:52:41 salv-orlando: very true - I know that they have the EC2 compat project now so they could extract it from Nova's codebase 21:52:53 7 minutes left 21:53:11 sc68cal: Also I struggle with the thought that I should consider parts of the neutron API as "imported" from AWS. Mostly because that would put a constraint on API evolution that I'm not sure we will be able to honour long time 21:53:20 sorry I meant in the long time 21:53:50 salv-orlando: very true. I'd have to look further, but I think SG is the only real API where we'd have to worry 21:54:01 salv-orlando: I don't think our API is anything like VPC's - and it isn't labeled as such 21:54:20 Yes. So that is the reason we need more discussion on there 21:54:21 s/our/the rest of neutron's api/g 21:54:34 to salv-orlando’s point this means that basically we can innovate on our own api so long as we have a backward compatible way to expose SG capabilieis via the nova api? 21:54:34 would that be enought to unlock us from this debate? 21:55:27 OK 21:55:28 sc68cal: we may implement new logging API if it not compatibility for SG API 21:55:32 armax: I'd probably want to explore more of what you mean by backward compatible way to expose SG capabilities, but overall that sounds reasonable 21:56:20 hoangcx: Right - I think my only comment was the new logging API just can reference a security group ID (or a rule ID) and that would keep us out of the tar pit of ec2 compatability 21:56:29 sc68cal: my point is that that if we can expect AWS centric users to use the API from something like Nova 21:56:38 sc68cal: then we can assume that access can be controlled 21:56:53 3 minutes left 21:56:55 and hence we can ‘hide’ the non-compatible bits 21:56:58 armax: ah - very true. that sounds reasonable 21:57:23 although we'd have to check, since the EC2 API is now outside of Nova 21:57:28 sc68cal: but I wouldn’t trust what I say if I were you 21:57:35 thanks for trying though 21:57:45 think it's https://github.com/stackforge/ec2-api ? 21:58:11 sc68cal: oh neat 21:58:34 sc68cal: but once the bits gets deployed it looks just as it did, did it not? 21:58:47 old ec2 code still there 21:58:50 but that's the future direction 21:59:08 afaik 21:59:16 armax: I think so - so maybe my concerns are overrated and I've wasted some time about these concerns - and we can just make it their problem 21:59:24 30 seconds left 21:59:25 sc68cal: Yes. so it have more further discussion on this new logging API if we get decision on this 21:59:28 russellb: thanks, I’ll look into it 21:59:29 I suggest continuing in #openstac-neutron 21:59:34 Thansk for attending this week folks! 21:59:40 bye all 21:59:40 We'll see you all in the internet 21:59:41 bye! 21:59:42 #endmeeting