14:03:17 <regXboi> #startmeeting
14:03:17 <odl_meetbot> Meeting started Mon Apr 21 14:03:17 2014 UTC.  The chair is regXboi. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:17 <odl_meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
14:03:20 <regXboi> it is
14:03:32 <regXboi> #chair alagalah
14:03:32 <odl_meetbot> Current chairs: alagalah regXboi
14:03:55 <s3wong> alagalah: regXboi: my understanding is this is a IRC only meeting?
14:04:09 <regXboi> yes I wanted it to be
14:04:14 <regXboi> but folks are on the hangout
14:04:19 <regXboi> so I can't be rude
14:04:39 <s3wong> regXboi: cool :-) I am on a train, so no hangout, sorry
14:05:00 <regXboi> #agreed IRC main channel - hangout is only for vois
14:05:02 <regXboi> er voice
14:05:14 <regXboi> #topic agenda bashing
14:05:29 <regXboi> #info my main topics are to the numbers we want to hit
14:05:42 <regXboi> #info and whether we can lift MD-SAL/APIC in as a model
14:05:45 <alagalah> regXboi: your audio is clipping
14:05:54 <jmedved> for me too
14:06:00 <jmedved> yes
14:06:00 <alagalah> regXboi: Typing and ghang doesn't work...
14:06:03 <banix> alagalah: i do not have this meeting on my calendar...
14:06:07 <alagalah> regXboi: :(
14:06:15 <alagalah> banix: email addr?
14:06:25 <banix> mbanikazemi@gmail.com
14:06:34 <banix> alagalah: ^^^
14:07:03 <alagalah> banix: sent
14:08:09 <regXboi> #info another agenda item: meeting time
14:08:14 <regXboi> (we'll hold that one for the end)
14:08:39 <alagalah> #info alagalah scribing
14:09:26 <regXboi> #topic perf numbers
14:09:31 <regXboi> #link https://wiki.opendaylight.org/view/Group_Policy:Scaling
14:10:03 <alagalah> #info regxboi recalls conversation with alagalah re: "production numbers"
14:10:22 <alagalah> #info dvorkinista deems numbers reasonable and we should consider targeting higher numbers
14:10:46 <alagalah> #info jmedved Question about what 250K resolvers actually means
14:11:56 <alagalah> #info regXboi contracts must be resolved within somewhere in the network, it maybe a switch etc. dvorkinista considers the number high, since there will be more devices than groups. If we say 25k groups, then 1k-5k resolvers should be sufficient
14:12:19 <alagalah> #info dvorkinista say we want to serve 100 racks ~ 4k hypervisors, perhaps 5K switches.
14:12:49 <alagalah> #info regXboi brings up NFV, dvorkinista says won't need more nfv devices than groups, but can see a case to the contrary
14:13:20 <alagalah> #info regXboi Agrees that in the datacentre the numbers are inverse, but NFV changes the dynamics. dvorkinista says therefore with NFV the number of groups are bigger
14:13:35 <alagalah> #info jmedved consider this a tough target to hit on day one
14:14:00 <alagalah> #info regXboi is looking at this all encompassing (DC + NFV) but is happy to target DC scaling first
14:14:25 <alagalah> #agreed start with DC scaling
14:14:45 <alagalah> #info regXboi asks dvorkinista to tweek the sizing for DC specific use case for initial scale
14:16:10 <alagalah> #info regXboi to create scaling numbers for DC from the above #link, we need to apply these numbers to specific use cases (as documented in the model wiki)
14:16:58 <alagalah> #info jmedved believes the rate numbers such as adding members to groups: 300K/Sec (driven by numbers) .. not designed for normal CRUD operations, purely for recovery post-fault
14:17:31 <alagalah> #info  jmedved believes the rate numbers such as adding members to groups: 300K/Sec (driven by numbers)  is high but regXboi pointed out not designed for normal CRUD operations, purely for recovery post-fault
14:18:03 <readams> Where is this document, by the way?
14:18:08 <alagalah> #info dvorkinista believes sub-second recovery time is a good target but may not be achievable but it would be an worthy goal
14:18:14 <alagalah> readams: read up to the link
14:18:21 <regXboi> readams: https://wiki.opendaylight.org/view/Group_Policy:Scaling
14:18:25 <alagalah> https://wiki.opendaylight.org/view/Group_Policy:Scaling
14:18:29 <alagalah> readams: snap
14:19:17 <alagalah> #info regXboi agrees to dvorkinista's point that these should be tweeked on use case basis
14:19:58 <alagalah> #info regXboi wants to look hard at using MD-SAL as the plumbing but not sure on using MD-SAL datastore. Either tweak it to use some the APIC model concepts
14:20:35 <alagalah> #info jmedved believes moving to a more APIC-style data store is a natural evolution
14:20:46 <alagalah> regXboi: Is this a new topic ?
14:20:59 <regXboi> #topic use of MD-SAL and APIC and querying
14:21:01 <alagalah> regXboi: Querying ??? New topic ?
14:21:03 <regXboi> it is :)
14:21:06 <alagalah> regXboi: cool
14:22:03 <alagalah> #info dvorkinista says that we need to start with modeling, to drive the data store, but the reality is that if we have to modify model to fit what is capable in the querying capabilities is just a fact of life
14:23:06 <alagalah> #info regXboi Agrees to shard we need a tree structure, but what does the tree look like? How do we do tenants, how do we do groups? Beyond that he sees it as "interesting" dvorkinista points out that contracts in APIC are contained within tenants
14:23:52 <alagalah> #info regXboi asks if a tenant is a hard and fast division or can they contain sub-tenants (ie reseller)... dvorkinista says its possible but it gets a little tricky... says hypothetically lets say they are not contained...
14:24:44 <alagalah> #info dvorkinista says lets separate orgs and tenants... instead lets talk about domains or namespaces
14:25:41 <alagalah> #info regXboi In spirit of walk before run, lets keep them separate, but lets design for containability ... so architecturally should support it, but day0 KISS
14:25:50 <regXboi> amen
14:25:57 <regXboi> KISS is my #1 mantra
14:26:11 <alagalah> regXboi: Mine is "As simple as possible; but no simpler"
14:27:00 <alagalah> #info jmedved Will this be the generic OpenDaylight model or the model for this particular application? dvorkinista Believes it would be nice (ie makes sense) if ODL had one domain naming type model, but regXboi points out that the model has issues
14:27:20 <alagalah> #info dvorkinista Either we fix it, and propose it for adoption or just deal with how things are today
14:28:03 <alagalah> #info regXboi jmedved discuss ODL's tenant model... its *there* but currently broken (so not there) oooohhhhhmmmmmm
14:28:55 <alagalah> #info regXboi asks about "layer" tenants (ordinary, common, infrastructure) -> groups -> contracts
14:29:11 <alagalah> #info dvorkinista says if you want to share across multi tenants you do it via the common space
14:29:41 <alagalah> #info dvorkinista concept of a shared contract interface, and if you want to share it you put it in common and anyone can consume....
14:30:01 <alagalah> #info dvorkinista this is how you handle extranet et al, and how you can conume infrastructure services
14:30:08 <alagalah> #info dvorkinista this is how you handle extranet et al, and how you can consume infrastructure services
14:30:56 <alagalah> #info dvorkinista Makes it easier to consume services. You go to your own shard (local) or the common shard. Issue is the common shard gets worked hard. Some optimisation possible there
14:31:14 <alagalah> #info regXboi Asks if the natural sharding is per tenant. dvorkinista says thats one way, regXboi asks if thats best ?
14:32:05 <alagalah> #info dvorkinista says per tenant shard is a good thing, due to how selectors work and how they consume contracts. If you shard on contracts and groups, what you risk, is if you use labels for resolution and shard on these, it can be costly to resolve.
14:32:35 <alagalah> #info dvorkinista says there is a way of having another containment boundary such as service to shard on, likely you will shard on tenant, call it a day and move on.
14:33:00 <alagalah> regXboi: I'm typing, can I ask in IRC ?
14:33:12 <regXboi> please
14:33:45 <alagalah> regXboi: If you naturally shard on tenant, there's nothing wrong with the sub-trees being other tenants correct? Hence I think this boundary on the tenant level lends itself really nice for reseller
14:33:54 <regXboi> I hope :)
14:34:14 <alagalah> #info jmedved asks about what we do about EP/EPG? Where are they in the tree?
14:34:33 <alagalah> #info dvorkinista EP are sharded by identifiers (MAC/IP)
14:34:46 <alagalah> dvorkinista: regXboi Is UUID a useful identifier?
14:34:55 <regXboi> oh please no
14:34:59 <alagalah> regXboi: LOL
14:35:05 <dvorkinista> alagalah: it's an identifier
14:35:25 <alagalah> regXboi: I'm thinking of how we get sub-machine level
14:35:36 <alagalah> regXboi: Even sub VM
14:36:05 <hemanth> if we are sharding by tenant, won't ep/epg be part of the tenant sub-tree
14:36:48 <dvorkinista> hemanth: you could, but the pattern here is different.
14:37:42 <alagalah> http://docs.docker.io/reference/run/#container-identification
14:38:42 <alagalah> #info regXboi Agrees with jmedved that this is a working hypothesis for tree structure, take to the YANG model team to see how this could be done in YANG to form the trees
14:39:02 <alagalah> #info dvorkinista Groups are in Tenant sub-tree.. EP are in own flat-space for now
14:40:10 <alagalah> #info regXboi Would like EP be same as structure as exists in ODL... wants EPs separate to "play nice with others" and dvorkinista says it makes sense anyway to share the load... if EP has an
14:40:19 <alagalah> #info "event" may choke tenant
14:41:08 <alagalah> #info regXboi feels we have enough to start spinning some YANG models around what was discussed above
14:41:12 <alagalah> #topic meeting time
14:41:34 <alagalah> #info Current meeting time 7am Monday
14:42:16 <alagalah> #idea regXboi proposes noon Monday
14:42:55 <s3wong> 7am is OK - especially if majority of meetings will be less than an hour
14:43:33 <regXboi> #info proposal to go to 8am, but that conflicts with OF meeting
14:43:57 <alagalah> #endmeeting