maxmustermann/pulumi
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Do a bit of random wordsmithing as I proofread

Browse source
This commit is contained in:
joeduffy 2016-11-04 11:34:30 -07:00
parent 97d251772d
commit 9836600e73
2 changed files with 11 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
docs/architecture.md
View file

@ -34,9 +34,9 @@ In this section, we will look at the toolchain that powers the overall Mu archit
### Translation
Now let us look at how a Mufile turns into a ready-to-run package. This will not describe the precise translation and
set of targets (that is available in the [metadata specification document](metadata.md)), instead focusing on the
various bits of data and code involved, the plugin architecture, and overall translation process flow.
Now let us look at how a Mufile turns into a ready-to-run package. This will not describe the metadata and precise
translation targets (those are available as separate docs [here](metadata.md) and [here](targets.md), respectively);
instead, we will look at the tools, plugin architecture, and overall translation process.
TODO(joe): write this section; just cover the overall structure and plugin model, not the details of each target.

14
docs/targets.md
View file

@ -186,8 +186,9 @@ TODO(joe): perhaps we should have an `aws/cf/customresource` extension type for
As we saw above, AWS services are available as Stacks. Let us now look at how they are expressed in Mu metadata and,
more interestingly, how they are transformed to underlying resource concepts. It's important to remember that these
aren't "higher level" abstractions in any sense of the word; instead, they map directly onto AWS resources. (Of course,
other higher level abstractions may compose these platform primitives into more interesting services. The key primitive
to making this direct mapping work is `mu/extension`. A simplified S3 bucket Stack, for example, looks like this:
other higher level abstractions may compose these platform primitives into more interesting services.)
A simplified S3 bucket Stack, for example, looks like this:
name: bucket
parameters:
@ -221,10 +222,11 @@ to making this direct mapping work is `mu/extension`. A simplified S3 bucket St
}
}
This simply leverages the abiliity to pass lifecycle events off to a provider, in this case `aws/cf/template`, along
with some metadata, in this case a simple wrapper around the [AWS CloudFormation S3 Bucket specification format](
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-s3-bucket.html). The provider manages
generating metadata and interacting with the AWS services required for provisioning, updating, and destroying resources.
The key primitive at play here is `mu/extension`. This passes off lifecycle events to a provider, in this case
`aws/cf/template`, along with some metadata, in this case a simple wrapper around the [AWS CloudFormation S3 Bucket
specification format](
http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-s3-bucket.html). The provider generates
metadata and knows how to interact with AWS services required for provisioning, updating, and destroying resources.
TODO(joe): we need to specify how extensions work somewhere.