openstack
/
magnum
Code Issues Proposed changes

Merge "Fix typos for Magnum"

This commit is contained in:
Jenkins 2016-07-04 03:03:57 +00:00 committed by Gerrit Code Review
parent c79ff286e7 15841b2faa
commit 2f30cc2952
4 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
doc/source/userguide.rst
View File

@ -838,7 +838,7 @@ Scaling
=======
*To be filled in*
Include Autoscaling
Include auto scaling
=======
Storage
@ -901,7 +901,7 @@ Cinder to request the volume to be mounted on this node, then
Kubernetes will launch the Docker container with the proper options to
make the filesystem on the Cinder volume accessible to the container
in the pod. When the pod exits, Kubernetes will again send a request
to Cinder to unmount the volume's filesystem, making it avaiable to be
to Cinder to unmount the volume's filesystem, making it available to be
mounted on other nodes.
Magnum supports these features to use Cinder as persistent storage

4
specs/async-container-operation.rst
View File

@ -143,7 +143,7 @@ Magnum-conductor will maintain a job-queue. Job-queue is indexed by bay-id and
container-id. A job-queue entry would contain the sequence of operations
requested for a given bay-id and container-id, in temporal order. A
greenthread will execute the tasks/operations in order for a given job-queue
entry, till the queue empties. Using a greethread in this fashion saves us
entry, till the queue empties. Using a greenthread in this fashion saves us
from the cost and complexity of locking, along with functional correctness.
When request for new operation comes in, it gets appended to the corresponding
queue entry.
@ -291,7 +291,7 @@ None
Performance impact
------------------
Asynchrnous mode of operation helps in scalability. Hence, it improves
Asynchronous mode of operation helps in scalability. Hence, it improves
responsiveness and reduces the turn around time in a significant
proportion. A small test on devstack, comparing both the modes,
demonstrate this with numbers.[1]

2
specs/container-volume-integration-model.rst
View File

@ -405,7 +405,7 @@ Kubernetes does support pod high-availability through the replication
controller, however, this doesn't work when a pod with volume attached
fails. Refer the link [11]_ for details.
Docker swarm doesn't support the containers reschduling when a node fails, so
Docker swarm doesn't support the containers rescheduling when a node fails, so
volume can not be automatically detached by volume driver. Refer the
link [12]_ for details.

4
specs/open-dcos.rst
View File

@ -61,7 +61,7 @@ the current Mesos Bay lack the following features:
4. Better network management. The Open DC/OS is planning to introduce CNI
network isolator in next release, the CNI network isolator is leveraging CNI
technolgies to manage network for containers.
technologies to manage network for containers.
5. Loosely coupled with docker daemon. The Open DC/OS can work well for docker
container even if docker daemon is not running. The docker daemon now have
@ -142,7 +142,7 @@ Work Items
1. Build VM image for Open DC/OS Bay.
2. Add Open DC/OS Bay driver.
3. Add Heat template for Open DC/OS Bay.
4. Add Open DC/OS Bay montior.
4. Add Open DC/OS Bay monitor.
5. Document how to use the Open DC/OS Bay.
Dependencies