86bfe5961d
This change is a first whack at implementing updates. Creation and deletion plans are pretty straightforward; we just take a single graph, topologically sort it, and perform the operations in the right order. For creation, this is in dependency order (things that are depended upon must be created before dependents); for deletion, this is in reverse-dependency order (things that depend on others must be deleted before dependencies). These are just special cases of the more general idea of performing DAG operations in dependency order. Updates must work in terms of this more general notion. For example: * It is an error to delete a resource while another refers to it; thus, resources are deleted after deleting dependents, or after updating dependent properties that reference the resource to new values. * It is an error to depend on a create a resource before it is created; thus, resources must be created before dependents are created, and/or before updates to existing resource properties that would cause them to refer to the new resource. Of course, all of this is tangled up in a graph of dependencies. As a result, we must create a DAG of the dependencies between creates, updates, and deletes, and then topologically sort this DAG, in order to determine the proper order of update operations. To do this, we slightly generalize the existing graph infrastructure, while also specializing two kinds of graphs; the existing one becomes a heapstate.ObjectGraph, while this new one is resource.planGraph (internal).
35 lines
1.9 KiB
Go
35 lines
1.9 KiB
Go
// Copyright 2016 Marapongo, Inc. All rights reserved.
|
|
|
|
// Package graph defines MuGL graphs. Each graph is directed and acyclic, and the nodes have been topologically
|
|
// sorted based on dependencies (edges) between them. Each node in the graph has a type and a set of properties.
|
|
//
|
|
// There are two forms of graph: complete and incomplete. A complete graph is one in which all nodes and their property
|
|
// values are known. An incomplete graph is one where two uncertainties may arise: (1) an edge might be "conditional",
|
|
// indicating that its presence or absence is dependent on a piece of information not yet available (like an output
|
|
// property from a resource), and/or (2) a property may either be similarly conditional or computed as an output value.
|
|
//
|
|
// In general, Mu blueprints may be compiled into graphs. These graphs may then be compared to other graphs to produce
|
|
// and/or carry out deployment plans. This package therefore also exposes operations necessary for diffing graphs.
|
|
package graph
|
|
|
|
// Graph is an instance of a MuGL graph. Each is associated with a single blueprint MuPackage as its input, along with
|
|
// a set of optional arguments used to evaluate it, along with the output DAG with node types and properties.
|
|
type Graph interface {
|
|
Roots() []Edge // the root edges.
|
|
}
|
|
|
|
// Vertex is a single vertex within an overall MuGL graph.
|
|
type Vertex interface {
|
|
Data() interface{} // arbitrary data associated with this vertex.
|
|
Label() string // the vertex's label.
|
|
Ins() []Edge // incoming edges from other vertices within the graph to this vertex.
|
|
Outs() []Edge // outgoing edges from this vertex to other vertices within the graph.
|
|
}
|
|
|
|
// Edge is a directed edge from one vertex to another.
|
|
type Edge interface {
|
|
Data() interface{} // arbitrary data associated with this edge.
|
|
Label() string // this edge's label.
|
|
To() Vertex // the vertex this edge connects to.
|
|
From() Vertex // the vertex this edge connects from.
|
|
}
|