Merge lp:~roadmr/juju-core/docs-typo-fixes into lp:juju-core/docs

[Daniel Manrique]

Some typo/grammar fixes in 'user guide' sections

Some typo/grammar fixes in 'user guide' sections.

=== modified file 'htmldocs/charms-destroy.html'
--- htmldocs/charms-destroy.html	2013-12-16 14:54:13 +0000
+++ htmldocs/charms-destroy.html	2014-01-23 18:58:50 +0000
@@ -79,7 +79,7 @@
               <pre class="prettyprint">juju destroy-service &LT;service-name&GT;</pre>
               <p class="warning note"><strong>Warning!:</strong> Destroying a service which has active relations with another running service will break that relation. This can cause errors in both services, as such review and potentially remove any relationships first.</p>
               <p>A service can take a while to "die", but if running a juju status reveals that the service is listed as dying, but also reports an error state, then the zombied service will still be hanging around. See <a href="#caveat-dying">caveats</a> for how to manage services in a dying state.</p>
-              <p class="note"><strong>Note:</strong> Destroying a service removes that service, but not any nodes which may have been created for it to run on. This is juju's way of preserving data to the best it's ability. See <a href="#destroy-machines">Destroying Machines</a> for additional details.</p>
+              <p class="note"><strong>Note:</strong> Destroying a service removes that service, but not any nodes which may have been created for it to run on. This is juju's way of preserving data to the best  of its ability. See <a href="#destroy-machines">Destroying Machines</a> for additional details.</p>
             </section>
             <section id="destroy-units">
               <h2 id="destroy-units">Destroying Units</h2>
@@ -96,7 +96,7 @@
               <h2 id="destroy-machines">Destroying machines</h2>
               <p>Instances or machines which have no currently assigned workload can be removed from your cloud using the following command:
               <pre class="prettyprint">juju destroy-machine &LT;number&GT;</pre>
-              <p>A machine which currently idle will be removed almost instantaneously from the cloud, along with anything else which may have been on the instance which juju was not aware of. To prevent accidents and awkward moments with running services, it is not possible to remove an instance which is currently allocated to a service. If you try to do so, you will get a polite error message in the form:</p>
+              <p>A machine which is currently idle will be removed almost instantaneously from the cloud, along with anything else which may have been on the instance which juju was not aware of. To prevent accidents and awkward moments with running services, it is not possible to remove an instance which is currently allocated to a service. If you try to do so, you will get a polite error message in the form:</p>
               <pre class="prettyprint lang-yaml">error: no machines were destroyed: machine 3 has unit "mysql/0" assigned</pre>
             </section>
             <section>
@@ -115,7 +115,7 @@
               <h2 id="caveats">Caveats</h2>
               <p>These are caveats which you may encounter while trying to remove items within Juju<p>
               <h3 id="caveat-dying">life: dying</h3>
-              <p>If you have a unit or serving in a dying state that has not gone away check to see if that unit, or any units within the service, are in an error state. Since Juju is an event driven orchestration client, the "removal" of a unit and service is also modeled as an event within Juju. As such, when a unit enters an error state all other events within that unit's lifecycle are queued. To clear this run <pre class="prettyprint lang-yaml">juju resolved &lt;unit&gt;</pre> to have the next even processed. You may need to run the <code>resolved</code> command run several times against a unit.</p>
+              <p>If you have a unit or serving in a dying state that has not gone away check to see if that unit, or any units within the service, are in an error state. Since Juju is an event driven orchestration client, the "removal" of a unit and service is also modeled as an event within Juju. As such, when a unit enters an error state all other events within that unit's lifecycle are queued. To clear this run <pre class="prettyprint lang-yaml">juju resolved &lt;unit&gt;</pre> to have the next event processed. You may need to run the <code>resolved</code> command run several times against a unit.</p>
               <p>If the unit isn't in an error state, there may be an error elsewhere in the environment. Since removing a unit or destroying a service also breaks the relation, if there's an error in the relation-removal event on one or more of the connected services that may also halt the event loop for that unit. Check to make sure no other units are in an error state and clear those using the <code>juju resolved</code> command.</p>
           </article>
 <!--Postamble-->

=== modified file 'htmldocs/charms-environments.html'
--- htmldocs/charms-environments.html	2013-12-16 14:54:13 +0000
+++ htmldocs/charms-environments.html	2014-01-23 18:58:50 +0000
@@ -112,7 +112,7 @@
 juju bootstrap  
 </pre>
           <p>... will bootstrap the environment defined by the 'hpcloud' label</p>
-          <p>This command will return with an error message if <code>JUJU_ENV</code>is set (as this takes precedence)</p>
+          <p>This command will return with an error message if <code>JUJU_ENV</code>is set (as this takes precedence).</p>
 <p class="note"><strong>Note: </strong>The environment selected with <code>switch</code> is persistent. Even if you log out, switch your computer off, travel into space or sail around the world, when you start using Juju again, it will still point at the last environment you specified with <code>switch</code>.</p>
 
 

=== modified file 'htmldocs/charms-service-groups.html'
--- htmldocs/charms-service-groups.html	2013-12-16 14:54:13 +0000
+++ htmldocs/charms-service-groups.html	2014-01-23 18:58:50 +0000
@@ -101,7 +101,7 @@
               </p>
 
               <p>
-              Why specify names for services?  The simplest reason is organizational... it let's you stay organized as your infrastructure gets more complex:
+              Why specify names for services?  The simplest reason is organizational... it lets you stay organized as your infrastructure gets more complex:
               </p>
 
 <pre class="prettyprint">
@@ -292,4 +292,4 @@
 
 
 
-</body></html>
\ No newline at end of file
+</body></html>

=== modified file 'htmldocs/howto-rails.html'
--- htmldocs/howto-rails.html	2013-12-16 14:54:13 +0000
+++ htmldocs/howto-rails.html	2014-01-23 18:58:50 +0000
@@ -91,7 +91,7 @@
             Basic Usage of the Ruby on Rails Charm
         </h2>
         <p>
-            Create a YAML config file with your application's name and it's git location
+            Create a YAML config file with your application's name and its git location
         </p>
         <p>
             <strong>sample-app.yml</strong>
@@ -109,7 +109,7 @@
 juju add-relation haproxy myapp
 </pre>
         <p>
-            Deploy and relate database
+            Deploy and relate database:
         </p>
 <pre class="prettyprint lang-bash">
 juju deploy postgresql
@@ -177,7 +177,7 @@
 juju bootstrap
 </pre>
         <p>
-            Create a YAML config file with your application's name and it's git location
+            Create a YAML config file with your application's name and its git location
         </p>
         <p>
             <strong>sample-app.yml</strong>
@@ -191,7 +191,7 @@
 <pre class="prettyprint lang-bash">juju deploy rails myapp --config sample-app.yml
 juju deploy postgresql</pre>
         <p>
-            and relate them
+            and relate them:
         </p>
 <pre class="prettyprint lang-bash">juju add-relation myapp postgresql
 </pre>
@@ -216,7 +216,7 @@
             Push to your Public/Private Cloud
         </h3>
         <p>
-            After you've repeatedly upgraded your application locally it's time to push it out to a place where your coworkers can see your app in all it's glory, let's push this to AWS. Same exact commands as before, just to a different environment:
+            After you've repeatedly upgraded your application locally it's time to push it out to a place where your coworkers can see your app in all its glory, let's push this to AWS. Same exact commands as before, just to a different environment:
         </p>
 <pre class="prettyprint lang-bash">juju switch amazon
 juju bootstrap

=== modified file 'htmldocs/troubleshooting-local.html'
--- htmldocs/troubleshooting-local.html	2013-12-16 14:54:13 +0000
+++ htmldocs/troubleshooting-local.html	2014-01-23 18:58:50 +0000
@@ -79,7 +79,7 @@
     	<section id="bootstrap_fails">
     	<h2>Bootstrap fails</h2>
 
-		<p>Everytime bootstrap fails, you'll need to run <code>sudo juju destroy-environment</code> prior to continuing. First let's rerun a bootstrap in debug mode:</p>
+		<p>Every time bootstrap fails, you'll need to run <code>sudo juju destroy-environment</code> prior to continuing. First let's rerun a bootstrap in debug mode:</p>
 
 <pre class="prettyprint lang-bash">
 sudo juju boostrap --show-log --debug
@@ -115,7 +115,7 @@
 	    <section id="no_machines_start">
         <h2>No machines start</h2>
 
-		<p>If you get a successful bootstrap, but services you deploy never come up, there's a chance that you have an older version of the Ubuntu Cloud Image cached on you machine. To verify this, check the timestamp of the contents in <code>/var/cache/lxc/cloud-precise/</code>
+		<p>If you get a successful bootstrap, but services you deploy never come up, there's a chance that you have an older version of the Ubuntu Cloud Image cached on your machine. To verify this, check the timestamp of the contents in <code>/var/cache/lxc/cloud-precise/</code>
 
 <pre class="prettyprint lang-bash">
 ls -lh /var/cache/lxc/cloud-precise/