No description
Find a file
joeduffy 7f98387820 Distinguish between computed and output properties
This change introduces the notion of a computed versus an output
property on resources.  Technically, output is a subset of computed,
however it is a special kind that we want to treat differently during
the evaluation of a deployment plan.  Specifically:

* An output property is any property that is populated by the resource
  provider, not code running in the Lumi type system.  Because these
  values aren't available during planning -- since we have not yet
  performed the deployment operations -- they will be latent values in
  our runtime and generally missing at the time of a plan.  This is no
  problem and we just want to avoid marshaling them in inopportune places.

* A computed property, on the other hand, is a different beast altogehter.
  Although true one of these is missing a value -- by virtue of the fact
  that they too are latent values, bottoming out in some manner on an
  output property -- they will appear in serializable input positions.
  Not only must we treat them differently during the RPC handshake and
  in the resource providers, but we also want to guarantee they are gone
  by the time we perform any CRUD operations on a resource.  They are
  purely a planning-time-only construct.
2017-06-01 08:36:43 -07:00
cmd Distinguish between computed and output properties 2017-06-01 08:36:43 -07:00
docs Reclassify Lumi under the Apache 2.0 license 2017-05-18 14:51:52 -07:00
examples Support for AWS DynamoDB Table GlobalSecondaryIndexes 2017-05-26 14:54:35 -07:00
Godeps Switch from Glide to Godep for dependency management 2017-05-24 12:50:28 -07:00
lib Add a @lumi.out decorator 2017-06-01 08:32:12 -07:00
pkg Distinguish between computed and output properties 2017-06-01 08:36:43 -07:00
sdk Initial support for output properties (1 of 3) 2017-06-01 08:32:12 -07:00
.gitignore Check in a missing test file 2017-02-01 19:41:13 -08:00
.gitmodules Remove stale submodules 2017-05-15 10:33:22 -07:00
.travis.yml Enable Slack notifications for Travis CI 2017-05-25 07:36:17 -07:00
CONTRIBUTING.md Fence some CONTRIBUTING.md code correctly 2017-05-24 18:10:30 -07:00
LICENSE Reclassify Lumi under the Apache 2.0 license 2017-05-18 14:51:52 -07:00
Makefile Skip -printf checks in Govet 2017-05-24 12:50:29 -07:00
NOTICE Reclassify Lumi under the Apache 2.0 license 2017-05-18 14:51:52 -07:00
README.md Update instructions for Govet 2017-05-24 13:25:28 -07:00

Build Status

Lumi

Lumi is a framework and toolset for creating reusable cloud services.

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

Installing

To install Lumi from source, simply run:

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

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

This installs the lumi binary to $GOPATH/bin.

At this moment, libraries must be manually installed. See below. Eventually we will have an installer.

Compilers

The Lumi compilers are independent from the core Lumi tools.

Please see the respective pages for details on how to install, build, and test each compiler:

Development

This section is for Lumi developers.

Prerequisites

Lumi is written in Go, uses Godep for dependency management, and Golint for linting:

Building and Testing

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

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

Before building, you will need to ensure dependencies have been restored to your enlistment:

$ godep restore

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

$ make

This installs the lumi 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.

Installing the Runtime Libraries

By default, Lumi looks for its runtime libraries underneath /usr/local/lumi. $LUMIPATH overrides this. Please refer to the libraries README for details on additional installation requirements.

Debugging

The Lumi 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 Lumi 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

$ lumi eval --logtostderr -v=5

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