pulumi/pkg/graph/graph.go

49 lines
2.6 KiB
Go
Raw Normal View History

2018-05-22 21:43:36 +02:00
// Copyright 2016-2018, Pulumi Corporation.
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
// Package graph defines resource 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, programs may be evaluated to produce graphs. These 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 resource digraph. Each is associated with a single program input, along
2017-02-25 16:25:33 +01:00
// 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 resource graph.
type Vertex interface {
Implement updates 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).
2017-02-23 23:56:23 +01:00
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 {
Implement updates 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).
2017-02-23 23:56:23 +01:00
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.
Color() string // an optional color for this edge, for when this graph is displayed.
}