[YUNIKORN-2097] fix type in gang_scheduling (#361)
Closes: #361
Signed-off-by: PoAn Yang <payang@apache.org>
diff --git a/docs/design/gang_scheduling.md b/docs/design/gang_scheduling.md
index f475395..1a09f72 100644
--- a/docs/design/gang_scheduling.md
+++ b/docs/design/gang_scheduling.md
@@ -246,7 +246,7 @@
* one or more _AllocationRelease_ messages, one for each placeholder, with the _TerminationType_ set to TIMEOUT
* one or more AllocationAskRelease messages with the _TerminationType_ set to TIMEOUT
-The shim processes the AllocationAskRelease messages first, followed by the _AllocationResponse_ messages, and finally the _UpdatedApplication_ message. The application state change to the _killed_ state on the core side is only dependent on the removal of all placeholders pods, not on a response to the _UpdatedApplication _message.
+The shim processes the AllocationAskRelease messages first, followed by the _AllocationResponse_ messages, and finally the _UpdatedApplication_ message. The application state change to the _killed_ state on the core side is only dependent on the removal of all placeholders pods, not on a response to the _UpdatedApplication_ message.
@@ -271,7 +271,7 @@
* zero or more _AllocationRelease_ messages, one for each placeholder, with the _TerminationType_ set to TIMEOUT
The shim processes the _AllocationResponse_ messages first followed by the _UpdatedApplication_ message.
-The application state change to the _completed_ state on the core side is only dependent on the removal of all placeholders pods, not on a response to the _UpdatedApplication _message.
+The application state change to the _completed_ state on the core side is only dependent on the removal of all placeholders pods, not on a response to the _UpdatedApplication_ message.
Entering into the _completed_ state will move the application out of the queue automatically.
This should also handle the case we discussed earlier around a possible delayed processing of requests from the shim as we can move back from _waiting_ to _running_ if needed.
@@ -456,7 +456,7 @@
The core will confirm the release to the shim of all types that originate in the shim and vice versa.
A confirmation or response uses the same _TerminationType_ as was set in the original message.
-An example of this is a pod that is removed from K8s will trigger an _AllocationRelease _message to be sent from the shim to the core with the TerminationType STOPPED_BY_RM. The core processes the request removing the allocation from the internal structures, and when all processing is done it responds to the shim with a message using the same _TerminationType_.
+An example of this is a pod that is removed from K8s will trigger an _AllocationRelease_ message to be sent from the shim to the core with the TerminationType STOPPED_BY_RM. The core processes the request removing the allocation from the internal structures, and when all processing is done it responds to the shim with a message using the same _TerminationType_.
The shim can ignore that or make follow up changes if needed.
A similar process happens for a release that originates in the core.
