17:00:10 #startmeeting tws 17:00:11 Meeting started Mon Aug 17 17:00:10 2015 UTC. The chair is colindixon. Information about MeetBot at http://ci.openstack.org/meetbot.html. 17:00:11 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:11 The meeting name has been set to 'tws' 17:00:59 #topic agenda bashing 17:01:19 #into today’s main topic is covering some of the user story work that’s been done 17:01:29 #link https://wiki.opendaylight.org/view/Tech_Work_Stream:Main#Upcoming_Meeting_Agendas 17:01:57 #info if people have ideas for future meetings, feel free to post them there or bring them up during the beginning/end of TWS calls 17:02:18 #chair phrobb tbachman 17:02:18 Current chairs: colindixon phrobb tbachman 17:05:37 #info the other topic for today is maros and jmedved on the performance of NETCONF 17:05:43 julim: are you having audio issues? 17:05:56 colindixon - having trouble connecting to webex 17:06:04 colindixon: not able to dial 17:06:04 meeting number code / access code invalid 17:06:05 julim: anything we can do to help? 17:06:12 Meeting number: 196 592 514 17:06:16 huh 17:06:28 I tried that mtg # with both toll-free and toll # but it does not work 17:06:28 I’m in using VoIP 17:06:36 webex still setting up (for 10 min now...) 17:06:52 same for me. Can't use WebEx for audio on Linux... 17:08:30 julim: can you have it call you? 17:08:31 colindixon - is there an international (israel) #? 17:08:38 I can't get webex even on. 17:08:53 I have to reboot I think as something got hung. brb in 3 min 17:09:07 you’re using these numbers: +1-855-797-9485 (US Toll free) 17:09:11 +1-415-655-0002 (US Toll) 17:09:29 will try # 17:09:45 ^^ nyechiel -- see new #'s from colindixon (different from website) 17:09:58 #topic netconf performance 17:10:38 colindixon - I managed to dial-in 17:10:41 just no webex 17:10:45 julim: thanks! 17:10:47 it’s all good 17:10:52 colindixon, julim: I am in as well, thanks! 17:10:53 if you’re just going to present the wiki, that works fine 17:10:59 awesome nyechiel! 17:11:06 we'll use wiki. 17:11:10 ack 17:11:12 nyechiel and julim: I’ll give you the ball back around half past 17:11:21 sounds good. thx colindixon 17:11:23 #info netconf scale testing 17:12:13 #info connecting to 10,000 devices, it took about 15 minutes to connect to every device, then 5-6 inutes to make an RPC call to each device 17:12:23 #info all tests using 4 core CPU with 6G of RAM for ODL 17:12:36 #info the above was with the clustered data store 17:12:55 #info with the in-memory data store, it took ~13 minutes (vs. 15 to do the same thing) 17:13:31 #info can mount 12-12.5k devices total with 4G of RAM 17:13:57 #info colindixon asks where these scripts are running, maros says so far private, but working on getting them into integration 17:14:09 #info netconf peformance testing 17:14:26 #info netconf-test-client => netconf server in ODL => MD-SAL’s data store (in-memory) 17:14:34 #info running on 16 core, 32G RAM machine 17:14:58 #info data writes are simple L2-FIB-style data 17:15:31 #info without baching, we get to 2400 writes/sec sync and 5600 writes/sec async 17:16:04 #info could get more than 40,000 writes/sec with async and batching 1000 writes/sec 17:17:02 #info jmedved points out that this is vs. ~1000-1500 writes/sec in OpenFlow 17:17:19 #info colindixon asks why that’s the case since they should both be just writing to the data sore 17:18:15 #info jmedved says part of that was that with openflow it’s a write, read, and then write, with batching the number goes 10-12k writes per second even with openflow, which begins to look not too dissimilar 17:18:36 #info with multiple clients and batching, it goes as high as 130,000+ writes/second 17:19:34 #info how many L2-FIB-link entries could be stored in limited memory something like 1.4 million decreasing to 300k as you go from 2G RAM to 500M RAM 17:19:46 #info netconf notification performance 17:20:11 #info notifications are basically a summary of a few routes 17:21:17 #info notifications/second range from 3k notifications/second to 22k notifications/second (increase due to smaller size and reduced complexity) 17:21:28 #info end-to-end netconf performance 17:21:59 #info restconf-test-client => restconf => MD-SAL binding aware app => netconf connector => netconf device 17:22:26 #info simulated netconf device was parsing data and throwing it way 17:22:33 #info data was also a list of routes 17:23:19 #info ranging from 600 routes/second without batching, multiple clients, or asynchrony to 6000 routes/second with things tuned up 17:24:00 #info this went up to 180,000 routes/second when moving to something avoiding restconf, restconf seems to be what’s slowling things down 17:24:24 #info jmedved asks when memory constrained, what was the peformance, maros says it was pretty fast until it got to ~90% of capacity 17:24:37 #info jmedved points out that this would be useful for the honeycomb ideas 17:27:26 #info colindixon asks about memory efficiency, it looks like we use ~1.5G RAM to store ~1,000,000 extra L2 FIB entries, which is ~1.5KB/entry, which isn’t great, but probably OK of Java 17:28:15 #info jmedved asks rovarga what could be done to further optimize memory usage, rovarga said we could use custom data structures or wait for Java 9 and some of it’s features 17:31:07 #Info points out we should look into this more deeply for honeycomb and what the trade-offs 17:32:06 #info there are some discussions about the relative reasons for openflow vs. netfconf performance differences 17:32:25 #info LuisGomez asks if it will get into ODL CI, Maros says yes that’s the plan 17:34:17 #info Art says he’d like to put out tutorials of how NETCONF would work so he can help out, would like somebody to reach out to him 17:34:30 #info jmedved and Art will connect 17:34:39 #topic user stories 17:35:16 https://wiki.opendaylight.org/view/UserStories:Main 17:35:29 #link https://wiki.opendaylight.org/view/UserStories:Main the user stories we’re going to go through 17:36:15 julim and nyechiel: I’m presenting the page so people can see it over webex too 17:36:58 #info julim says that this is a list of user stories around OpenDaylight and OpenStack primarily, there are a variety of roles defined 17:37:41 #Info each user story is a list of scenarios that are either not yet covered by opendaylight or only partially covered 17:37:42 the fuller list of user stories (backlog) can be seen at https://wiki.opendaylight.org/view/File:ODL_User_Stories.pdf 17:37:58 #info nyechiel says these are the basic table stakes for working with OpenStack 17:38:14 #link https://wiki.opendaylight.org/view/File:ODL_User_Stories.pdf this is the full backlog of user stories that they have put together 17:39:32 #info edwarnicke asks about the first one, he was under the impression that security groups were working 17:39:49 #info edwarnicke asks they to check with group-based policy working 17:40:10 #info nyechiel points out that so far this is mostly looking at OVSDB, no GBP, but he’ll look at that 17:40:42 #info edwarnicke notes that he’s pretty sure that GBP supports security groups and IPv6 security groups fully working 17:43:15 #info edwarnicke believes everything here is working insofar as he knows except for DHCP/IPAM and conntracking features that require new OVS 17:43:55 #info nyechiel and julim say that this isn’t so much about these items, although they might be useful, but more that this is likely a better model for how to set priorities and focus in OpenDaylight 17:43:57 edwarnicke - pls. feel free to update the status column about things you believe are completed or are outstanding 17:44:08 julim: Link? 17:44:24 edwarnicke - https://wiki.opendaylight.org/view/UserStories:Main 17:44:32 julim: Many thanks :) 17:44:37 Thank you edwarnicke 17:44:40 #info nyechiel and julim also point out that if we want tration with the openstack community (and their users) this is likely a good approach 17:45:14 #link https://wiki.opendaylight.org/view/UserStories:Explanation put some really basic information about how to appraoch things with user stories 17:45:18 #undo 17:45:18 Removing item from minutes: 17:45:24 #link https://wiki.opendaylight.org/view/UserStories:Explanation put some really basic information about how to appraoch things with user stories (courtesy of julim) 17:45:45 #info Prem_ asks how this changes with the big tent approach in OpenStack 17:46:24 #info nyechiel says that’s a longer discussion, but he doesn’t thing we’re far enough along in our user story planning for that to dramatically affect us 17:50:05 #info art says he really likes this, but he’d love to see this drift even further up the stack from feature-level things to even more use cases 17:50:16 #info julim says that soudns great, and ask for any next steps 17:50:35 #info art says he is trying to come up with a first stab at well-define use caes and is hoping for feedback soon 17:51:05 #info dneary asks if there are any high-priority use cases missing from here? 17:52:22 #info edwarnicke asks about NFV use cases, he sees NFV as the end-game and OpenStack is just stepping stone 17:55:42 #info edwarnicke says one idea about how to be more story/user-oriented would be to make sure we at least acknowledge when we do meet them 17:56:28 #info vishnoianil__ says that we have a broad set of good ideas and ways forward for things, but we often don’t end up with effective places to discuss the ideas and requirements in a single place 17:56:55 #info colindixon assuems that added onto vishnoianil__’s comments is the idea that we could attach user stories to it 17:57:18 #info edwarnicke says that odlforge would help a lot as having a way to place code somewhere that could be played with 17:58:37 I think the recent OF-CONFIG review was very instructive on the review process... I think breaking down use-cases to architecture is the first step ... and I think it always worked when someone took charge and produced a first cut ... 18:00:30 #info phrobb says that these other comments point to a broader thing about how to break down what we’re doing from a user-oriented, requirements-driven, approach for features 18:02:00 #info art asks how we do feature requests today, colindixon says maybe that would be a good topic for a future call 18:02:22 #endmeeting