Heat/PolicyExtension
Contents
Policy Extension to Heat Templates
This page describes a proposed extension to Heat templates allowing expression of various sorts of policies relevant to infrastructure. First is a description of the information model, which focuses on what is being said without getting into details of concrete syntax. Next are some use cases. Next is a proposal for concrete syntax. Lastly there are some examples using the concrete syntax.
Information Model
This extension introduces three concepts in templates: groups, policies, and relationships.
This extension also introduces a meta-model for the datacenters in which templates will be instantiated. A datacenter is modeled as a tree whose leaves are the physical resources that can host the virtual resources prescribed by templates. The tree need not be of uniform depth. Each vertex in the tree is labeled with a level, drawn from a vocabulary established by the datacenter or some more central authority. Open question: who defines these vocabularies? The levels stand in a partial order; we say some levels are more fine grained or more coarse grained than other levels. The usage of levels in the tree must be consistent with this partial order. Thus, the root might be labeled with level=room while a leaf might be labeled with level=PM. The ordering is only partial because some levels might be incommensurate. For example, level=PM can host VMs while level=StorageBox can host storage volumes.
Groups are used to group the resources of a template together for concise application of policies and relationships. The resources of the template are partitioned among some groups, and those groups are members of other groups, and so on. In a given template, the groups are arranged into a tree and the leaf groups contain the resources. The tree need not be of uniform depth.
A policy is something that, in its essence, is about one or two resources. There are different types of policies, each type with a specific meaning and possibly taking type-specific parameters. A policy type is either monadic, meaning its essential statement is about a single resource, or dyadic, meaning its essential statement is a relationship between two resources. For a monadic example, consider a type of policy that takes an identifier of a licensed product as a parameter and declares the presence of that product in the resource. For a dyadic example, an anti-collocation policy might take a physical hierarchy level parameter and be applied to two VMs to mean that their locations should differ at the given level. Each policy is either hard or soft --- that is, a requirement or a preference. Some dyadic types of policies are symmetric, others are not. For example, an anti-collocation policy is symmetric; an endpoint accessibility policy (i.e., firewall rule) is asymmetric.
While a policy's essence is about a resource or two, the actual applications of policies can be at higher levels of organization. Each higher level application of a policy is a shorthand for many lower level application of the policy. There are two high level ways to apply a policy. One is to apply a policy to a group; this makes sense only for monadic and symmetric dyadic policies. The other is to apply a policy to a pair of groups.
While it makes perfect sense to apply policies directly to resources, we avoid doing so directly in concrete template syntax for a couple of reasons. One is that this restriction makes this documentation easier to write. Another is that it gives this extension a smaller footprint in the code. In the grand and glorious future, when more developer time is available, those considerations may be overruled by others.
Applying a monadic policy to a group is shorthand for applying the policy to every member of the group. Thus, after recursion, this amounts to applying the policy's essential statement to every resource covered by the group.
Applying a symmetric binary policy to a group is a shorthand for applying the policy's essential relationship to every distinct unordered pair of members of the group. For example, applying a binary policy to a group of the resources {A, B, C} is shorthand for applying that policy's essential relationship to {A, B}, to {B, C}, and to {C, A}. For a more complicated example, consider a tree of three groups: GP has members GL and GR, while GL has members {R1, R2} and GR has members {R3, R4}. Applying a binary policy to group GP is shorthand for applying that policy to the unordered pair {GL, GR}.
Applying a symmetric dyadic policy to an unordered pair of groups {A, B} is equivalent to applying that policy to the ordered pair (A, B) and also equivalent to applying it to (B, A).
Applying a binary policy to an ordered pair (A, B), where A and B are either groups or resources, is shorthand for applying that policy to every ordered pair of (X, Y) where (1) X is either A (if A is a resource) or a member of A (if A is a group) and (2) Y is either B (if B is a resource) or a member of B (if B is a group). For example, if group GL's members are resources R1 and R2 while group GR's members are resources R3 and R4, applying a policy to (GL, GR) amounts to applying the policy to (R1, R3), to (R1, R4), to (R2, R3), and to (R2, R4).
