=========================================================== #opendaylight-group-policy: FriApr25 MODEL - Mickey's notes =========================================================== Meeting started by alagalah at 15:11:24 UTC. The full logs are available at http://meetings.opendaylight.org/opendaylight-group-policy/2014/friapr25_model___mickey_s_notes/opendaylight-group-policy-friapr25_model___mickey_s_notes.2014-04-26-15.11.log.html . Meeting summary --------------- * Consumers, Providers, formula (alagalah, 15:11:37) * Mike notes once you xxx contract, set of clauses (alagalah, 15:11:37) * These consumer rules, under the conditions, can talk to these provider capabilities, under these conditions (alagalah, 15:11:41) * That maps you into a set of subjects that are within scope (alagalah, 15:11:41) * This way we can say consumers have roles (alagalah, 15:11:42) * Providers have capabilities (alagalah, 15:11:44) * We can change the names, think about them as properties that indicate something (alagalah, 15:11:46) * You have providers, capabilities, and conditions (alagalah, 15:11:50) * Consumers have roles and conditions (alagalah, 15:11:51) * Whenever consumers have certain roles, certain conditions, providers have certain capabilities, conditions, they can talk to each other, results in certain subjects being in scope (alagalah, 15:11:52) * Mickey notes only one endpoint group per endpoint (alagalah, 15:11:54) * But that endpoint group can have many capabilities and roles (alagalah, 15:11:57) * Mike clarifies there can be many, not restricted to one (alagalah, 15:11:58) * Ryan asks to explain symbology (alagalah, 15:12:02) * Understand F is some sort of match or formula, might be different for consumers and providers (alagalah, 15:12:03) * Mike explains we have consumer roles that can be fed into a formula (alagalah, 15:12:05) * Ryan’s first stupid question (alagalah, 15:12:06) * Mathematically speaking, if you use the same capital F, you mean they are the same formula (alagalah, 15:12:08) * Mike does not mean that (alagalah, 15:12:10) * Some sort of formula at each point, not the same (alagalah, 15:12:12) * Daljeet asks if roles are published by providers? (alagalah, 15:12:14) * Mike notes provider has capabilities, consumer has roles (alagalah, 15:12:17) * They meet together in the contract (alagalah, 15:12:18) * Have different formulas, match on roles, can specify ANDs, ORs, XORs (alagalah, 15:12:21) * Have access to provider capabilities under these conditions (alagalah, 15:12:22) * When met, these subjects are in scope (alagalah, 15:12:24) * This set of roles under these conditions, logical multiplier, modulate (alagalah, 15:12:27) * Change “F” to “F1”, “F2”, “F3”, not the same function (alagalah, 15:12:28) * Mike notes meant to communicate an idea, not meant to be mathematically sound (alagalah, 15:12:31) * What it means, for these roles under these conditions, however you combine those things, you can talk to providers under those conditions (alagalah, 15:12:32) * You map to a set of subjects on which you can communicate (alagalah, 15:12:34) * Ryan would love to have a concrete example (alagalah, 15:12:36) * Not today, but thinking there will be a whole lot of folks who look at this, go WTF (alagalah, 15:12:38) * Concrete example would help (alagalah, 15:12:40) * Rob suggests adding onto the end, a network (alagalah, 15:12:43) * That is what it looks like in UML, trying to express (alagalah, 15:12:45) * Role matchers can match themselves, allows for nested formulas (alagalah, 15:12:46) * Keith shows nested inheritance (alagalah, 15:12:48) * Rob notes it is a matcher, implemented the way matchers are implemented (alagalah, 15:12:50) * Basically have a group (alagalah, 15:12:52) * Through relator, normal selector or names (alagalah, 15:12:55) * Select contract (alagalah, 15:12:57) * Then you have clauses, based on roles and conditions, this is how you can talk to capabilities under certain conditions (alagalah, 15:12:58) * Roles, conditions, capabilities, if want to rename them, propose names (alagalah, 15:13:00) * Does not matter what they are (alagalah, 15:13:02) * Just felt like these names made sense (alagalah, 15:13:09) * Mickey is not thrilled about capability, have to think of something to change to (alagalah, 15:13:09) * Rob usually associates a role with a user (alagalah, 15:13:09) * Mike cannot find words that are vague enough, not used today (alagalah, 15:13:11) * Tried to use requirement before, people did not like it (alagalah, 15:13:13) * Rob prefers requirement to role (alagalah, 15:13:15) * ACTION: Keith to create plain English definitions of each “noun” (alagalah, 15:13:17) * Definition of concepts, then show how concepts worked together (alagalah, 15:13:18) * Rob asks if this is something that can be understood by normal human users? (alagalah, 15:13:20) * Or something you have to be a programmer to understand? (alagalah, 15:13:22) * Mike ran it by people who do firewalls, enterprise applications (alagalah, 15:13:26) * They can understand it (alagalah, 15:13:27) * We can reduce it to English grammar (alagalah, 15:13:29) * Just a formal UML diagram (alagalah, 15:13:31) * Translating to word grammar (alagalah, 15:13:32) * For example group name has selector that points to this thing (alagalah, 15:13:34) * Then within this thing there is a contract, rule, for these roles under these conditions talk to the capabilities under those conditions (alagalah, 15:13:38) * Jan asks why not take to Yang directly? (alagalah, 15:13:38) * Mike wants to agree on concepts first (alagalah, 15:13:41) * At a given time, object only contained by one, either relator or the group (alagalah, 15:13:42) * Some requirements can be defined at group level, some at relator level (alagalah, 15:13:44) * If define at relator level, specified in context of relationship with a given contract (alagalah, 15:13:48) * Jan asks, configure role and condition directly? (alagalah, 15:13:48) * Mike notes scope to which it applies (alagalah, 15:13:51) * If role under selector, only evaluated in contracts that this selector refers to (alagalah, 15:13:53) * If put in group, applies to all contracts (alagalah, 15:13:54) * Certain roles you have in life regardless of your current function (alagalah, 15:13:57) * Special roles when poor, at home, when you visit your grandmother (alagalah, 15:13:59) * Work is your contract, expressed through relator (alagalah, 15:14:01) * Certain roles defined within context of that relationship (alagalah, 15:14:03) * Those roles do not apply to you when you are at home (alagalah, 15:14:04) * Jan notes one kind of uber selector, where roles and conditions apply by default (alagalah, 15:14:07) * Mike notes you do, under the group (alagalah, 15:14:08) * Mike notes certain roles are universal regardless of where you are (alagalah, 15:14:10) * Jan asks why clause and subject both? (alagalah, 15:14:12) * Mike notes only clause under contract (alagalah, 15:14:14) * Mickey notes clause is choosing a subject (alagalah, 15:14:17) * Consumers under these conditions can talk to the provider capabilities under these conditions, on these subjects (alagalah, 15:14:19) * Can you have subject without clause? (alagalah, 15:14:20) * Mike notes subject is contained, within contract (alagalah, 15:14:22) * Clause is who can talk to whom on what subject (alagalah, 15:14:24) * Jan asks why clause not contained in a subject? (alagalah, 15:14:26) * Mike notes clause can map to 20 subjects, a tree (alagalah, 15:14:28) * Keith notes sigma symbol (alagalah, 15:14:31) * Mickey asks about condition again? (alagalah, 15:14:32) * Mike notes can mark endpoint group, or endpoint, saying this one is insecure (alagalah, 15:14:34) * Things meant to be more or less transient, think about them as modulators (alagalah, 15:14:37) * For example, posture (alagalah, 15:14:38) * Discussion of Affinity (not the project, the VM concept) (alagalah, 15:14:41) * Mike notes not how we are reasoning about this (alagalah, 15:14:42) * Put secure as a condition (alagalah, 15:14:44) * Secure is allowed to talk to anybody on all of the subjects (alagalah, 15:14:46) * Conditions can be on consumer or provider side, do not have to be the same conditions on either side (alagalah, 15:14:48) * Don’t have to think about identifiers (alagalah, 15:14:50) * Mike’s example (alagalah, 15:14:52) * You can assign a score to an endpoint (alagalah, 15:14:55) * Go to scorer table, that maps you into a condition, gets inherited (alagalah, 15:14:56) * Relates how you enforce the policy (alagalah, 15:14:58) * Circumstances, how connected, where you came from, whatever (alagalah, 15:15:01) * Allows inheritance of conditions based on circumstances (alagalah, 15:15:03) * Group can be put into a circumstance, or an endpoint can be put into a circumstance (alagalah, 15:15:04) * When you come to Cisco building 7, connect through wireless, subjected to different set of rules, versus connected directly to Ethernet port (alagalah, 15:15:06) * Under circumstance of being connected in Cisco building, through Ethernet port rather than wireless (alagalah, 15:15:08) * Also circumstance, connected on your laptop versus iPad (alagalah, 15:15:12) * Condition inheritance mechanism (alagalah, 15:15:12) * Jan notes applying label to whole bunch of conditions (alagalah, 15:15:16) * Asks if it is inheritance or grouping? (alagalah, 15:15:17) * Mike claims both, can inherit a bunch of conditions (alagalah, 15:15:19) * Circumstance can be a tree, at each level define conditions, when terminate at one of the leafs or nodes, inherit everything (alagalah, 15:15:20) * Jan asks if conditions point to endpoints? (alagalah, 15:15:22) * Mike notes endpoint ends up containing the condition, a string (alagalah, 15:15:24) * In xxx, this computer is deemed evil (alagalah, 15:15:31) * Say congress application from OpenStack makes call to Endpoint Registry, says mark this endpoint as insecure (alagalah, 15:15:31) * You are under this circumstance, know which labels to inherit (alagalah, 15:15:31) * Keith notes can force into contract where do IPS or IDS (alagalah, 15:15:32) * Jan notes endpoints in registry independent of our policies, then reference them in our policies? (alagalah, 15:15:34) * Mike counters, in our endpoint registry, you always know which group you belong to (alagalah, 15:15:37) * How you get there, will not discuss here (alagalah, 15:15:38) * Also know which xxx you are subjected to (alagalah, 15:15:41) * Those conditions are used in determining what rules apply to you, who can talk to you, and how (alagalah, 15:15:42) * Keith notes previously in formula, consumer modulated by conditions, determined which providers it can talk to, modulated by its conditions, … (alagalah, 15:15:45) * Can circumstances modulate the conditions? (alagalah, 15:15:46) * Mike notes if endpoint assigned to a circumstance, you inherit a bunch of conditions (alagalah, 15:15:49) * Keith realizes it is additive, augments condition string (alagalah, 15:15:51) * Mike notes group can have a circumstance (alagalah, 15:15:52) * Tenant (alagalah, 15:15:59) * Mike notes need to distinguish between tenant and VRF-like xxx concepts (alagalah, 15:15:59) * One way to think about tenant, the object that contains everything we talked about (alagalah, 15:16:00) * Can have 3 categories of tenant (alagalah, 15:16:00) * One is regular tenant, organization (alagalah, 15:16:03) * Common tenant where all shared stuff is sitting (alagalah, 15:16:05) * Infrastructure tenant (alagalah, 15:16:06) * Common tenant, when tenants need to consume services from each other, publish into common tenant, that is how you know who you can access (alagalah, 15:16:08) * Someone asks about infra tenant? (alagalah, 15:16:10) * Mickey asks more like provider or group within a provider? (alagalah, 15:16:12) * Yes (alagalah, 15:16:14) * Keith notes questions whether inventory part would go into that (alagalah, 15:16:16) * Mike notes can provide DNS, DHCP as part of infrastructure, and others can use it (alagalah, 15:16:18) * Regular tenant cannot provide services to anybody else (alagalah, 15:16:21) * Mickey asks, if looking under specific tenant, cannot resolve to shared? (alagalah, 15:16:22) * Mike notes from context of where you are towards root of the tree (alagalah, 15:16:24) * If cannot find it, go to common (alagalah, 15:16:27) * Mickey notes have to jump (alagalah, 15:16:29) * Mickey notes trying to do in one dimension rather than multiple dimensions as was done in UCSM and other older products (alagalah, 15:16:31) * Jan asks one level of tenants? (alagalah, 15:16:32) * Mike notes we can have more (alagalah, 15:16:35) * Downside of having nested tenants is how do you shard in a consistent way (alagalah, 15:16:37) * This is where implementation drives the model, icky, but that is the reality (alagalah, 15:16:38) * Not opposed to solving the problem, as long as solve the sharding part (alagalah, 15:16:41) * Mickey notes if shard based on tenant, we need to think about common tenant, whether that becomes a sharding problem (alagalah, 15:16:42) * Jan notes other apps may not shard based on tenant (alagalah, 15:16:44) * Mickey hopes all who talk to group-based policy will use asynchronous, then MD-SAL will determine how to get to the appropriate shard (alagalah, 15:16:47) * ACTION: Keith to rename Consumer "ROLE" references to "REQUIREMENTS" (alagalah, 15:16:48) Meeting ended at 15:16:51 UTC. People present (lines said) --------------------------- * alagalah (160) * odl_meetbot (3) Generated by `MeetBot`_ 0.1.4