Merge "Modify grammatical errors"
This commit is contained in:
commit
6a8587a87b
@ -190,7 +190,7 @@ to be triggered during initial deployment with TripleO follows:
|
||||
with Heat accordingly.
|
||||
#. A point in the deployment is reached where the Overcloud nodes are
|
||||
imaged, booted, and networked. At that point the undercloud has
|
||||
access to the the provisioning or management IPs of the Overcloud
|
||||
access to the provisioning or management IPs of the Overcloud
|
||||
nodes.
|
||||
#. A new Heat Resource is created which starts a Mistral workflow to
|
||||
Deploy Ceph on the systems with the any of the five Ceph server
|
||||
@ -282,7 +282,7 @@ to be triggered during initial deployment with TripleO follows:
|
||||
created. For example, because the workflow is idempotent, if the
|
||||
resource creation fails because the wrong parameter was passed or
|
||||
becasue of a temporary network issue, the deployer could simply run
|
||||
a stack-update the the Mistral worklow would run again and if the
|
||||
a stack-update the Mistral worklow would run again and if the
|
||||
issues which caused the first run to fail were resolved, the
|
||||
deployment should succeed. Similarly if a user updates a parameter,
|
||||
e.g. a new disk is added to `ceph::profile::params::osds`, then the
|
||||
@ -313,7 +313,7 @@ process to deploy the OSDs along with the Overcloud:
|
||||
with Heat accordingly.
|
||||
#. A point in the deployment is reached where the new Overcloud nodes
|
||||
are imaged, booted, and networked. At that point the undercloud has
|
||||
access to the the provisioning or management IPs of the Overcloud
|
||||
access to the provisioning or management IPs of the Overcloud
|
||||
nodes.
|
||||
#. A new Heat Resource is created which starts a Mistral workflow to
|
||||
add new Ceph OSDs.
|
||||
|
@ -17,7 +17,7 @@ During the Pike cycle the minor update and some parts of the major upgrade
|
||||
are significantly different to any previous cycle, in that they are *not* being
|
||||
delivered onto nodes via Heat stack update. Rather, Heat stack update is used
|
||||
to only collect, but not execute, the relevant ansible tasks defined in each
|
||||
of the the service manifests_ as upgrade_tasks_ or update_tasks_ accordingly.
|
||||
of the service manifests_ as upgrade_tasks_ or update_tasks_ accordingly.
|
||||
These tasks are then written as stand-alone ansible playbooks in the stack
|
||||
outputs_.
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user