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.
This change adds a .mu/ directory to the vote50 app. Inside are the "expected"
contents that the Mu compiler should output. Eventually we will validate against
this that the (currently non-existent) compiler generates the correct thing.
This isn't complete, although I can manually create bits and pieces of the stacks
using CloudFormation. More files will come; for example, the code packages.
In a nutshell:
.mu/ # Shared files agnostic to the cloud target
aws-native-cf/ # Files specific to the AWS CloudFormation target
app.template.yaml # The CloudFormation stack for the overall app
services/ # A directory containing service-specific stacks
voting.template.yaml # The CloudFormation stack for the VotingService
services/ # Service files agnostic to the cloud target
voting.proto # The gRPC definition for VotingService's API
mu.yaml # The Mu package manifest (minimal for now)
