#opendaylight-group-policy Meeting

Meeting started by regXboi at 14:03:17 UTC (full logs).

Meeting summary

    1. AGREED: IRC main channel - hangout is only for vois (regXboi, 14:05:00)

  2. agenda bashing (regXboi, 14:05:14)
    1. my main topics are to the numbers we want to hit (regXboi, 14:05:29)
    2. and whether we can lift MD-SAL/APIC in as a model (regXboi, 14:05:42)
    3. another agenda item: meeting time (regXboi, 14:08:09)
    4. alagalah scribing (alagalah, 14:08:39)

  3. perf numbers (regXboi, 14:09:26)
    1. https://wiki.opendaylight.org/view/Group_Policy:Scaling (regXboi, 14:09:31)
    2. regxboi recalls conversation with alagalah re: "production numbers" (alagalah, 14:10:03)
    3. dvorkinista deems numbers reasonable and we should consider targeting higher numbers (alagalah, 14:10:22)
    4. jmedved Question about what 250K resolvers actually means (alagalah, 14:10:46)
    5. 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 (alagalah, 14:11:56)
    6. dvorkinista say we want to serve 100 racks ~ 4k hypervisors, perhaps 5K switches. (alagalah, 14:12:19)
    7. regXboi brings up NFV, dvorkinista says won't need more nfv devices than groups, but can see a case to the contrary (alagalah, 14:12:49)
    8. 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 (alagalah, 14:13:20)
    9. jmedved consider this a tough target to hit on day one (alagalah, 14:13:35)
    10. regXboi is looking at this all encompassing (DC + NFV) but is happy to target DC scaling first (alagalah, 14:14:00)
    11. AGREED: start with DC scaling (alagalah, 14:14:25)
    12. regXboi asks dvorkinista to tweek the sizing for DC specific use case for initial scale (alagalah, 14:14:45)
    13. 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) (alagalah, 14:16:10)
    14. 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 (alagalah, 14:16:58)
    15. 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 (alagalah, 14:17:31)
    16. dvorkinista believes sub-second recovery time is a good target but may not be achievable but it would be an worthy goal (alagalah, 14:18:08)
    17. https://wiki.opendaylight.org/view/Group_Policy:Scaling (alagalah, 14:18:25)
    18. regXboi agrees to dvorkinista's point that these should be tweeked on use case basis (alagalah, 14:19:17)
    19. 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 (alagalah, 14:19:58)
    20. jmedved believes moving to a more APIC-style data store is a natural evolution (alagalah, 14:20:35)

  4. use of MD-SAL and APIC and querying (regXboi, 14:20:59)
    1. 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 (alagalah, 14:22:03)
    2. 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 (alagalah, 14:23:06)
    3. 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... (alagalah, 14:23:52)
    4. dvorkinista says lets separate orgs and tenants... instead lets talk about domains or namespaces (alagalah, 14:24:44)
    5. regXboi In spirit of walk before run, lets keep them separate, but lets design for containability ... so architecturally should support it, but day0 KISS (alagalah, 14:25:41)
    6. 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 (alagalah, 14:27:00)
    7. dvorkinista Either we fix it, and propose it for adoption or just deal with how things are today (alagalah, 14:27:20)
    8. regXboi jmedved discuss ODL's tenant model... its *there* but currently broken (so not there) oooohhhhhmmmmmm (alagalah, 14:28:03)
    9. regXboi asks about "layer" tenants (ordinary, common, infrastructure) -> groups -> contracts (alagalah, 14:28:55)
    10. dvorkinista says if you want to share across multi tenants you do it via the common space (alagalah, 14:29:11)
    11. dvorkinista concept of a shared contract interface, and if you want to share it you put it in common and anyone can consume.... (alagalah, 14:29:41)
    12. dvorkinista this is how you handle extranet et al, and how you can conume infrastructure services (alagalah, 14:30:01)
    13. dvorkinista this is how you handle extranet et al, and how you can consume infrastructure services (alagalah, 14:30:08)
    14. 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 (alagalah, 14:30:56)
    15. regXboi Asks if the natural sharding is per tenant. dvorkinista says thats one way, regXboi asks if thats best ? (alagalah, 14:31:14)
    16. 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. (alagalah, 14:32:05)
    17. 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. (alagalah, 14:32:35)
    18. jmedved asks about what we do about EP/EPG? Where are they in the tree? (alagalah, 14:34:14)
    19. dvorkinista EP are sharded by identifiers (MAC/IP) (alagalah, 14:34:33)
    20. http://docs.docker.io/reference/run/#container-identification (alagalah, 14:37:42)
    21. 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 (alagalah, 14:38:42)
    22. dvorkinista Groups are in Tenant sub-tree.. EP are in own flat-space for now (alagalah, 14:39:02)
    23. 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 (alagalah, 14:40:10)
    24. "event" may choke tenant (alagalah, 14:40:19)
    25. regXboi feels we have enough to start spinning some YANG models around what was discussed above (alagalah, 14:41:08)

  5. meeting time (alagalah, 14:41:12)
    1. Current meeting time 7am Monday (alagalah, 14:41:34)
    2. IDEA: regXboi proposes noon Monday (alagalah, 14:42:16)
    3. proposal to go to 8am, but that conflicts with OF meeting (regXboi, 14:43:33)


Meeting ended at 14:43:57 UTC (full logs).

Action items

  1. (none)


People present (lines said)

  1. alagalah (66)
  2. regXboi (24)
  3. s3wong (3)
  4. odl_meetbot (3)
  5. banix (3)
  6. dvorkinista (2)
  7. jmedved (2)
  8. readams (1)
  9. hemanth (1)


Generated by MeetBot 0.1.4.