Adds an initial cut at a demo script along with
a raw version of the serverless example that
is a better stepping stone between the low-level
AWS infrastructure providers and the high-level
`aws.serverless` APIs.
LumiJS lambdas can now be serialized when they include calls to other LumiJS lambdas. The chain of lambda dependencies is jointly serialized into the target Lambda.
Also, LumiJS lambdas now include `node_modules` automatically in the AWS Lambda, ensuring the the runtime execution environment more closely matches the deployment time environment.
An early version of the gh-cicd example supporting #134 is added which uses these capabilities, currently including a mocked GitHub resource provider.
For lambdas which will execute at runtime,
we want to allow them to reference Node.js
global variables, like `console`.
This change makes Lumijs generated IL
incrementally more dynamic by preferring to
generate `TryLoadDynamic` over `LoadLocation`
for references to global variables (except for
references to imports).
Also introduces `console.log` in LumiJS, though
it is not yet attached to a Lumi global environment.
Fixes#174.
The scope chain currently does not include module-scope
vairables, which are instead stored on a module object. For
now, we are capturing this module object along with the
scope chain as part of a Lambda object so that we can use
it when evaluating variable references within a lambda
expression.
Fixes#175.
In the places we run `go build`, we should use
`go build -i` to save the `.a` files generated
during the build. This ensures the artifacts
are availble for other Go tools (linters, IDEs), and
should also improve build speeds.
The AssumeRolePolicyDocument property returned by the AWS IAM GetRole API returns
a URL-encoded JSON string, so we need to decode this before JSON unmarshalling.
The Code property returned by AWS Lambda GetFunction provides a pre-signed S3 URL,
which changes on each call, and is of a different format to what is provided by the user.
For now, we'll not store this back into the Function object.
Add additional output properties to AWS Lambda Function that are stable values returned
from GetFunction.
Also corrects a gap where some property delete operations were not being correctly reported.
This new package is similar to the AWS Serverless Application Model, offering
higher-level interfaces to manage serverless resources. This will be a candidate
for moving into its own package in the future.
The FunctionX class has been moved into this module, and a new API class has
been added
The API class manages a collection of an API Gateway RestAPI, Stage and Deployment,
based on a collection of routes linked to Functions. On changes to the API specification,
it updates the RestAPI, replaces the Deployment and updates the Stage to point to
the updated Deployment.
This change also reorganizes some of the intrinsics.
Adds support for global secondary indexes on DynamoDB Tables.
Also adds a HashSet API to the AWS provider library. This handles part of #178,
providing a standard way for AWS provider implementations to compute set-based
diffs. This new API is used in both aws.dynamodb.Table and aws.elasticbeanstalk.Environment
currently.
Resolves#137.
This is an initial pass for supporting JavaScript lambda syntax for defining an AWS Lambda Function.
A higher level API for defining AWS Lambda Function objects `aws.lambda.FunctionX` is added which accepts a Lumi lambda as an argument, and uses that lambda to generate the AWS Lambda Function code package.
LumiJS lambdas are serialized as the JavaScript text of the lambda body, along with a serialized version of the environment that is deserialized at runtime and used as the context for the body of the lambda.
Remaining work to further improve support for lambdas is being tracked in #173, #174, #175, and #177.
Unifies the notion of BuiltinFunctions with the existing Intrinsic.
Intrinsic is now only a wrapper type, used to indicate the need to lookup the symbol in the
eval pacakges table of registered intrinsics. It does not carry the invoker function used
to eval the intrinsic.
This change keeps the lumi prefix on our CLI tools.
As @lukehoban pointed out in person, as soon as we do pulumi/coconut#98,
most people (other than compiler authors themselves) won't actually be
typing the commands. And, furthermore, the commands aren't all that bad.
Eventually I assume we'll want something like `lumi-js`, or
`lumi-js-compiler`, so that binaries are discovered dynamically in a way
that is extensible for future languages. We can tackle this during #98.
This is a sample serverless function, written in Node.js, and exposed
over an HTTP API gateway endpoint.
It even works! (For Kubernetes Fission; the AWS support is dependent
upon projecting the various API gateway resource providers...)
This changes the example security analyzer from acmecorp/security
to just infosec, to reinforce that we will have certain analyzers
"out of the box" (infosec, cost, etc.)
* Rename the sample from ec2instance to webserver.
* Factor out the AMI map stuff into the AWS library, rather than the sample.
* Strongly type the instance type parameter using the aws.ec2.InstanceType union.
* Add a new webserver-comp example that demonstrates a bit of the ability to do
encapsulation, componentization, and multi-instantiation.
This change includes a simple cpuwatch package, as a demonstration of
how easy it can be to add CPU-level monitoring to an existing stack.
It contains a single API, enableAlarm, that takes an instance and
CPU % threshold; if the CPU ever exceeds that threshold for a sustained
period of time (3 consecutive minutes), an email will be generated.
To use this, first simply install the package as usual, e.g.
$ coco pack get cpuwatch
From there, you will need to configure the email address to send to:
$ coco env config <env> cpuwatch:config:emailAddress joe@pulumi.com
And finally, add an import plus call to enableAlarm for all instances:
import * as cpuwatch from "cpuwatch";
..
let instance = new aws.ec2.Instance(...);
cpuwatch.enableAlarm(instance, 90); // email if >90% CPU utilization.
As part of this, I've added the typing projections for the AWS SNS topic
and CloudWatch alarm resource types (but no providers just yet).
This adds a simple ACMECorp security analyzer example. It doesn't
actually do anything other than reject any AWS EC2 instance, claiming
it is vulnerable. Eventually we should do something smart.
This changes a few naming things:
* Rename "husk" to "environment" (`coco env` for short).
* Rename NutPack/NutIL to CocoPack/CocoIL.
* Rename the primary Nut.yaml/json project file to Coconut.yaml/json.
* Rename the compiled Nutpack.yaml/json file to Cocopack.yaml/json.
* Rename the package asset directory from nutpack/ to .coconut/.
This change eliminates the hard-coded region from the ec2instance
example, and instead uses the new `aws.config.region` configuration
variable. This makes the code more amenable to multi-instancing.
This change partially implements pulumi/coconut#94, by adding the
ability to name targets during creation and reuse those names during
deletion and update. This simplifies the management of deployment
records, checkpoints, and snapshots.
I've opted to call these things "husks" (perhaps going overboard with
joy after our recent renaming). The basic idea is that for any
executable Nut that will be deployed, you have a nutpack/ directory
whose layout looks roughly as follows:
nutpack/
bin/
Nutpack.json
... any other compiled artifacts ...
husks/
... one snapshot per husk ...
For example, if we had a stage and prod husk, we would have:
nutpack/
bin/...
husks/
prod.json
stage.json
In the prod.json and stage.json files, we'd have the most recent
deployment record for that environment. These would presumably get
checked in and versioned along with the overall Nut, so that we
can use Git history for rollbacks, etc.
The create, update, and delete commands look in the right place for
these files automatically, so you don't need to manually supply them.
This restructures the examples directory a bit, into three buckets:
* basic/: simplistic examples, like hello world and whatnot.
* conversions/: actual conversions from existing samples (with the source cited).
* scenarios/: more complex examples that demonstrate various features of the system.
I just introduced the examples/aws/ directory yesterday to hold some
of our basic AWS examples, as I expect us to start accumulating more
of them. So this just moves ec2instance underneath that directory.
We should probably think about further reorganizing these (e.g., into
demos/, scenarios/, etc.), ass we accumulate more examples.
This splits the overall example rack service into many sub-services.
This leads to a much cleaner factoring of the code. Note that there are
some missing properties -- it's hard to eyeball this without a real compiler.
But the essence of the example is pretty spot on.
I personally prefer this syntax. It is more "declarative" and, particularly
because we support true assignments, I feel like it's more representative of
what's going on. It's easier to scan for real imperative assignments. This
approach also eliminates a single horizontal character per assignment.
In this change, ":= new" declares a new resource.
In addition, we change arrays to be Go-like, in that zero-initialized
ones can be appended to safely, such that declaring a new instance is
done merely by stating "var arr: T[]".
This adds two hypothetical variants to the Mu demo, "building" new capabilities
up from the basic Express and MongoDB app we start with:
1) The first variant is to leverage the Mu SDK for service discovery and
configuration, eliminating the "loosely typed" approach that is common with
Docker (e.g., having to fetch connection URLs from arguments, environment
variables, etc). This extends the Mu type system "into" the Docker container,
whereas previously it stopped at the boundary.
2) The second variant really takes this to the next level, embellishing the nice
DSL-like approach. In this model, infrastructure is expressed in code.
Instead of manually creating a volume, we will arrange for the mongodb/mongodb
to auto-mount a mu/x/fs/volume, as per [the cloud-neutral design doc](/docs/xcloud.md).
This just adds a simple voting app for the demo script. It leverages
a Node.js Express app for the frontend and a MongoDB database for the backend.
It conditionally provisions and attaches to an AWS Elastic Block Store volume
in the event that it's targeting an AWS cluster, and ephemeral storage otherwise.
This was really just a brainstorming exercise that helped get to the final
model we landed on. I'm archiving it for posterity. I'll decide whether to
carry it forward or delete it and leave it as an artifact for future reference
as I make more progress on the overall architecture and file format specification.
This was an interesting example I found in the Mulesoft GitHub repos. It seemed like
a perfect candidate for Riff/Mu/Lambda, so I sketched out what it might look like.