No description
Find a file
Pat Gavlin d22a42858f Add two-phase snapshotting.
The existing `SnapshotProvider` interface does not sufficiently lend
itself to reliable persistence of snapshot data. For example, consider
the following:
- The deployment engine creates a resource
- The snapshot provider fails to save the updated snapshot
In this scenario, we have no mechanism by which we can discover that the
existing snapshot (if any) does not reflect the actual state of the
resources managed by the stack, and future updates may operate
incorrectly. To address this, these changes split snapshotting into two
phases: the `Begin` phase and the `End` phase. A provider that needs to
be robust against the scenario described above (or any other scenario
that allows for a mutation to the state of the stack that is not
persisted) can use the `Begin` phase to persist the fact that there are
outstanding mutations to the stack. It would then use the `End` phase to
persist the updated snapshot and indicate that the mutation is no longer
outstanding. These steps are somewhat analogous to the prepare and
commit phases of two-phase commit.
2017-10-21 09:31:01 -07:00
cmd Add two-phase snapshotting. 2017-10-21 09:31:01 -07:00
dist/sdk/nodejs
docs
examples Merge pull request #434 from pulumi/PendingDeletes 2017-10-19 10:57:00 -07:00
pkg Add two-phase snapshotting. 2017-10-21 09:31:01 -07:00
scripts Use install.sh 2017-10-14 07:24:20 -07:00
sdk Fix bugs in free variable analysis (#444) 2017-10-19 23:20:57 -07:00
.appveyor.yml
.gitignore
.gitmodules
.travis.yml Stop using yarn scripts for building 2017-10-16 10:47:37 -07:00
.yarnrc Restore TESTPARALLELISM to 10 2017-10-16 10:47:37 -07:00
build.proj Construct version based on git information 2017-10-16 18:35:41 -07:00
CONTRIBUTING.md
Gometalinter.json
Gopkg.lock Use go-yaml directly 2017-10-20 14:01:37 -07:00
Gopkg.toml Use go-yaml directly 2017-10-20 14:01:37 -07:00
LICENSE
main.go Construct version based on git information 2017-10-16 18:35:41 -07:00
Makefile Track resources that are pending deletion in checkpoints. 2017-10-18 17:09:00 -07:00
README.md
tslint.json Enable 'use const' linter rule. (#405) 2017-10-10 14:50:55 -07:00

Pulumi Fabric

The Pulumi Fabric ("Pulumi") is a framework and toolset for creating reusable cloud services.

If you are learning about Pulumi for the first time, please see the overview document.

Build Status

Architecture Build Status
Linux x64 Linux x64 Build Status
Windows x64 Windows x64 Build Status

Installing

To install Pulumi from source, simply run:

$ go get -u github.com/pulumi/pulumi

A GOPATH must be set. A good default value is ~/go. In fact, this is the default in Go 1.8.

This installs the pulumi binary to $GOPATH/bin.

To do anything interesting with Pulumi, you will need an SDK for your language of choice. Please see sdk/README.md for information about how to obtain, install, and use such an SDK.

Development

This section is for Pulumi developers.

Prerequisites

Pulumi is written in Go, uses Dep for dependency management, and GoMetaLinter for linting:

Building and Testing

To build Pulumi, ensure $GOPATH is set, and clone into a standard Go workspace:

$ git clone git@github.com:pulumi/pulumi $GOPATH/src/github.com/pulumi/pulumi
$ cd $GOPATH/src/github.com/pulumi/pulumi

The first time you build, you must make configure to install dependencies and perform other machine setup:

$ make configure

In the future, you can synch dependencies simply by running dep ensure explicitly:

$ dep ensure

At this point you can run make to build and run tests:

$ make

This installs the pulumi binary into $GOPATH/bin, which may now be run provided make exited successfully.

The Makefile also supports just running tests (make test), just running the linter (make lint), just running Govet (make vet), and so on. Please just refer to the Makefile for the full list of targets.

Debugging

The Pulumi tools have extensive logging built in. In fact, we encourage liberal logging in new code, and adding new logging when debugging problems. This helps to ensure future debugging endeavors benefit from your sleuthing.

All logging is done using Google's Glog library. It is relatively bare-bones, and adds basic leveled logging, stack dumping, and other capabilities beyond what Go's built-in logging routines offer.

The pulumi command line has two flags that control this logging and that can come in handy when debugging problems. The --logtostderr flag spews directly to stderr, rather than the default of logging to files in your temp directory. And the --verbose=n flag (-v=n for short) sets the logging level to n. Anything greater than 3 is reserved for debug-level logging, greater than 5 is going to be quite verbose, and anything beyond 7 is extremely noisy.

For example, the command

$ pulumi eval --logtostderr -v=5

is a pretty standard starting point during debugging that will show a fairly comprehensive trace log of a compilation.