Fix typos for Magnum
1. greethread --> greenthread 2. reschduling --> rescheduling 3. technolgies --> technologies 4. montior --> monitor 5. avaiable --> available 6. autoscaling --> auto scaling 7. Asynchrnous --> Asynchronous 8. Availablity--> Availability Change-Id: I94e2e4eeacb72f029754382142696150ffee72ef
This commit is contained in:
parent
3e9302cf4d
commit
15841b2faa
@ -421,7 +421,7 @@ Kubernetes (as of v1.2) is more sophisticated than Swarm (as of v1.2.2). It
|
||||
offers an attractive YAML file description of a pod, which is a grouping of
|
||||
containers that run together as part of a distributed application. This file
|
||||
format allows you to model your application deployment using a declarative
|
||||
style. It has support for autoscaling and fault recovery, as well as features
|
||||
style. It has support for auto scaling and fault recovery, as well as features
|
||||
that allow for sophisticated software deployments, including canary deploys
|
||||
and blue/green deploys. Kubernetes is very popular, especially for web
|
||||
applications.
|
||||
@ -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
|
||||
|
@ -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]
|
||||
|
@ -383,7 +383,7 @@ drivers. Besides this, different container volume driver can also cause
|
||||
performance variance.
|
||||
|
||||
|
||||
High-Availablity Impact
|
||||
High-Availability Impact
|
||||
------------------------------
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
|
@ -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
|
||||
|
Loading…
Reference in New Issue
Block a user