-
Notifications
You must be signed in to change notification settings - Fork 0
Design
- Metric
- generates Measurements
- Control
- Makes Changes to a system
- Constraint
- Expresses/defines a business requirement
TIC automatically adjusts Controls to drive Metrics to satisfy Constraints.
-
inventory/configuration
- authz: User, Group, Role
- resources: Host, Link, Service
-
ticketing
- incident: observed violation of a constraint
- service call: human request
- must have
- a UUID (to allow names to change without breaking references)
- an origin (default/base install, user input, etc)
- a name (may be partly an auto-incrementing number)
- a version
- one or more ISO OSI "7 layer burrito" model layers they touch. Some will vary by class (all Users are Application layer) some will vary by instance (Metrics may measure any layer or even several). May be 'inherited' from a previous version or from the object's class.
- a 'deleted' flag
- should have
- a previous version reference, if not first version
- may have
- a parent namespace
- has
- context(s) (host, switch, user, group, ...)
- an implementation
- parameters
- expected side-effects, if any
- should have
- rollback ActionImplementation
- validation Constraint(s)
- may have
- pre-condition Constraint(s)
An Action encapsulates a real or simulated interaction with a system. It includes the motivation for the interation, the target resource, the parameters of the interaction and it tracks the results and optional attempt at rollback.
When an ActionImplementation is used, it generates an Action which tracks the execution of the implementation.
- has
- ActionImplementation
- parameters used
- does
- rollback
- if possible, creates an action which reverses this action
- rollback
- has
- parameters
- ActionImplementation
- units
- an expected range of values
Side-effects should be minimized
Example metric: "one minute load average"
- layers: application?
- parameters: none
- context: a host
- implementation:
uptime | sed 's/.*average: //;s/,.*//' - side effect: will increase load slightly
- units: runnable processes
- range: zero to infinity
- has
- "bump" implementation
- may have
- expected metric effects
- converse Control (un-bump)
- will gather
- observed metric effects
A constraint requires that one value be greater than another. Either of the two values may be a constant, but one must be a formula which is composed of at least one Metric. TIC adjusts Controls to keep Constraints "true".
- has
- two formulae: upper and lower
For example: "Finish serving human-facing web objects within 100 milliseconds of when the load balancer receives the packet completing the corresponding HTTP request from the client." The upper formula is the constant expression "100 milliseconds". The lower formula would be a Metric reporting on how long it's taking to serve pages.
Through experimentation the system would discover that scaling up load balancers, caching servers, app servers and database shards can (eventually) lower latency.
NOTE: I considered "greater or equal" above but decided ops is never precise
so equality is rare enough to be considered likely to be an error. If there is
ever a use case where lower() == upper() isn't a breach, subtract a very
small number from the lower bound and get on with your life.
- is a kind of Metric
- because Resources are discovered via measurement
- is a kind of Measurement
- has
- a ResourceType
A ContextType is a mode of interaction with a system. ResourceTypes use ContextTypes to explain how to manipulate them. All ActionImplementations which match a given ContextType can manipulate the ResourceTypes which have that ContextType.
Examples:
- Router via CLI
- Host via shell
- Cloud Account via API
A Context is a specific interaction channel. It connects an Action to a Resource.
- has
- ContextType
- ActionType
- Resource
- Action
An ActionType is a template for an Action. A ContextType is a template for a Context. A ContextType creates a Context from a Resource and parameters. An ActionType creates an Action from a Context.