Merge pull request #1938 from ceh/spellcheck
website: address spelling mistakes
This commit is contained in:
Seth Vargo
commit
4170eb7d2c
|
|
@ -69,7 +69,7 @@ list as contributors come and go.
|
|||
<h3>Ross Smith II (<a href="https://github.com/rasa" target="_blank">@rasa</a>)</h3>
|
||||
<p>
|
||||
<a href="http://smithii.com/" target="_blank">Ross Smith</a> maintains our VMware builder on Windows, and provides other valuable assistance.
|
||||
Ross is an open source enthusist, published author, and freelance consultant.</p>
|
||||
Ross is an open source enthusiast, published author, and freelance consultant.</p>
|
||||
</div>
|
||||
</div>
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
layout: "docs"
|
||||
page_title: "Amazon AMI Builder (EBS backed)"
|
||||
description: |-
|
||||
The `amazon-ebs` Packer builder is able to create Amazon AMIs backed by EBS volumes for use in EC2. For more information on the difference betwen EBS-backed instances and instance-store backed instances, see the storage for the root device section in the EC2 documentation.
|
||||
The `amazon-ebs` Packer builder is able to create Amazon AMIs backed by EBS volumes for use in EC2. For more information on the difference between EBS-backed instances and instance-store backed instances, see the storage for the root device section in the EC2 documentation.
|
||||
---
|
||||
|
||||
# AMI Builder (EBS backed)
|
||||
|
|
@ -11,7 +11,7 @@ Type: `amazon-ebs`
|
|||
|
||||
The `amazon-ebs` Packer builder is able to create Amazon AMIs backed by EBS
|
||||
volumes for use in [EC2](http://aws.amazon.com/ec2/). For more information
|
||||
on the difference betwen EBS-backed instances and instance-store backed
|
||||
on the difference between EBS-backed instances and instance-store backed
|
||||
instances, see the
|
||||
["storage for the root device" section in the EC2 documentation](http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ComponentsAMIs.html#storage-for-the-root-device).
|
||||
|
||||
|
|
|
|||
|
|
@ -26,7 +26,7 @@ instance to use a [Compute Engine Service Account](https://cloud.google.com/comp
|
|||
to Google Cloud without having to bake in a separate credential/authentication file.
|
||||
|
||||
To create a GCE instance that uses a service account, provide the required scopes when
|
||||
launching the intance.
|
||||
launching the instance.
|
||||
|
||||
For `gcloud`, do this via the `--scopes` parameter:
|
||||
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ each category, the available options are alphabetized and described.
|
|||
|
||||
* `parallels_tools_flavor` (string) - The flavor of the Parallels Tools ISO to
|
||||
install into the VM. Valid values are "win", "lin", "mac", "os2" and "other".
|
||||
This can be ommited only if `parallels_tools_mode` is "disable".
|
||||
This can be omitted only if `parallels_tools_mode` is "disable".
|
||||
|
||||
### Optional:
|
||||
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ each category, the available options are alphabetized and described.
|
|||
|
||||
* `parallels_tools_flavor` (string) - The flavor of the Parallels Tools ISO to
|
||||
install into the VM. Valid values are "win", "lin", "mac", "os2" and "other".
|
||||
This can be ommited only if `parallels_tools_mode` is "disable".
|
||||
This can be omitted only if `parallels_tools_mode` is "disable".
|
||||
|
||||
### Optional:
|
||||
|
||||
|
|
|
|||
|
|
@ -185,7 +185,7 @@ each category, the available options are alphabetized and described.
|
|||
the qemu command line (though not, at this time, qemu-img). Each array
|
||||
of strings makes up a command line switch that overrides matching default
|
||||
switch/value pairs. Any value specified as an empty string is ignored.
|
||||
All values after the switch are concatenated with no separater.
|
||||
All values after the switch are concatenated with no separator.
|
||||
|
||||
~> **Warning:** The qemu command line allows extreme flexibility, so beware of
|
||||
conflicting arguments causing failures of your run. For instance, using
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ each category, the available options are alphabetized and described.
|
|||
### Optional:
|
||||
|
||||
* `boot_command` (array of strings) - This is an array of commands to type
|
||||
when the virtual machine is firsted booted. The goal of these commands should
|
||||
when the virtual machine is first booted. The goal of these commands should
|
||||
be to type just enough to initialize the operating system installer. Special
|
||||
keys can be typed as well, and are covered in the section below on the boot
|
||||
command. If this is not specified, it is assumed the installer will start
|
||||
|
|
|
|||
|
|
@ -54,7 +54,7 @@ each category, the available options are alphabetized and described.
|
|||
### Optional:
|
||||
|
||||
* `boot_command` (array of strings) - This is an array of commands to type
|
||||
when the virtual machine is firsted booted. The goal of these commands should
|
||||
when the virtual machine is first booted. The goal of these commands should
|
||||
be to type just enough to initialize the operating system installer. Special
|
||||
keys can be typed as well, and are covered in the section below on the boot
|
||||
command. If this is not specified, it is assumed the installer will start
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ passed directly into something like the standard Go `flag` package for
|
|||
command-line flag parsing.
|
||||
|
||||
The return value of `Run` is the exit status for the command. If everything
|
||||
ran successfully, this should be 0. If any errors occured, it should be any
|
||||
ran successfully, this should be 0. If any errors occurred, it should be any
|
||||
positive integer.
|
||||
|
||||
### The "Synopsis" Method
|
||||
|
|
|
|||
|
|
@ -34,7 +34,7 @@ uses, because they're completely isolated into the process space of the
|
|||
plugin itself.
|
||||
|
||||
And, thanks to Go's [interfaces](http://golang.org/doc/effective_go.html#interfaces_and_types),
|
||||
it doesn't even look like inter-process communication is occuring. You just
|
||||
it doesn't even look like inter-process communication is occurring. You just
|
||||
use the interfaces like normal, but in fact they're being executed in
|
||||
a remote process. Pretty cool.
|
||||
|
||||
|
|
@ -93,7 +93,7 @@ in the relevant subsections available in the navigation to the left.
|
|||
|
||||
~> **Lock your dependencies!** Unfortunately, Go's dependency
|
||||
management story is fairly sad. There are various unofficial methods out
|
||||
there for locking dependencies, and using one of them is highly recomended
|
||||
there for locking dependencies, and using one of them is highly recommended
|
||||
since the Packer codebase will continue to improve, potentially breaking
|
||||
APIs along the way until there is a stable release. By locking your dependencies,
|
||||
your plugins will continue to work with the version of Packer you lock to.
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@ of `packer build`.
|
|||
<dt>artifact (>= 2)</dt>
|
||||
<dd>
|
||||
<p>
|
||||
Information about an artifact of the targetted item. This is a
|
||||
Information about an artifact of the targeted item. This is a
|
||||
fairly complex (but uniform!) machine-readable type that contains
|
||||
subtypes. The subtypes are documented within this page in the
|
||||
syntax of "artifact subtype: SUBTYPE". The number of arguments within
|
||||
|
|
@ -119,7 +119,7 @@ of `packer build`.
|
|||
<dt>artifact subtype: nil (0)</dt>
|
||||
<dd>
|
||||
<p>
|
||||
If present, this means that the artifact was nil, or that the targetted
|
||||
If present, this means that the artifact was nil, or that the targeted
|
||||
build completed successfully but no artifact was created.
|
||||
</p>
|
||||
</dd>
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ It's important to understand the workflow that using this post-processor
|
|||
enforces in order to take full advantage of Vagrant and Vagrant Cloud.
|
||||
|
||||
The use of this processor assume that you currently distribute, or plan
|
||||
to distrubute, boxes via Vagrant Cloud. It also assumes you create Vagrant
|
||||
to distribute, boxes via Vagrant Cloud. It also assumes you create Vagrant
|
||||
Boxes and deliver them to your team in some fashion.
|
||||
|
||||
Here is an example workflow:
|
||||
|
|
|
|||
|
|
@ -51,7 +51,7 @@ However, if you want to configure things a bit more, the post-processor
|
|||
does expose some configuration options. The available options are listed
|
||||
below, with more details about certain options in following sections.
|
||||
|
||||
* `compression_level` (integer) - An integer repesenting the
|
||||
* `compression_level` (integer) - An integer representing the
|
||||
compression level to use when creating the Vagrant box. Valid
|
||||
values range from 0 to 9, with 0 being no compression and 9 being
|
||||
the best compression. By default, compression is enabled at level 6.
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ Optional parameters:
|
|||
various [configuration template variables](/docs/templates/configuration-templates.html)
|
||||
available. See below for more information.
|
||||
|
||||
* `facter` (object, string keys and values) - Additonal
|
||||
* `facter` (object, string keys and values) - Additional
|
||||
[facts](http://puppetlabs.com/puppet/related-projects/facter) to make
|
||||
available when Puppet is running.
|
||||
|
||||
|
|
|
|||
|
|
@ -136,7 +136,7 @@ sleep 60
|
|||
```
|
||||
|
||||
Some OS configurations don't properly kill all network connections on
|
||||
reboot, causing the provisioner to hang despite a reboot occuring.
|
||||
reboot, causing the provisioner to hang despite a reboot occurring.
|
||||
In this case, make sure you shut down the network interfaces
|
||||
on reboot or in your shell script. For example, on Gentoo:
|
||||
|
||||
|
|
@ -172,7 +172,7 @@ will echo the script statements as it is executing.
|
|||
*My builds don't always work the same*
|
||||
|
||||
* Some distributions start the SSH daemon before other core services which
|
||||
can create race conditions. Your first provisoner can tell the machine to
|
||||
can create race conditions. Your first provisioner can tell the machine to
|
||||
wait until it completely boots.
|
||||
|
||||
```javascript
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
layout: "docs"
|
||||
page_title: "User Variables in Templates"
|
||||
description: |-
|
||||
User variables allow your templates to be further configured with variables from the command-line, environmental variables, or files. This lets you parameterize your templates so that you can keep secret tokens, environment-specific data, and other types of information out of your templates. This maximizes the portablility and shareability of the template.
|
||||
User variables allow your templates to be further configured with variables from the command-line, environmental variables, or files. This lets you parameterize your templates so that you can keep secret tokens, environment-specific data, and other types of information out of your templates. This maximizes the portability and shareability of the template.
|
||||
---
|
||||
|
||||
# User Variables
|
||||
|
|
|
|||
Loading…
Reference in New Issue