Add more information in design

kubeflow · Mar 19, 2018 · 21cad4e · 21cad4e
1 parent 3e6a020
commit 21cad4e
Show file tree

Hide file tree

Showing 2 changed files with 4 additions and 2 deletions.
diff --git a/proposals/diagrams/all-reduce-pytorch-operator.jpeg b/proposals/diagrams/all-reduce-pytorch-operator.jpeg
diff --git a/proposals/pytorch-operator-proposal.md b/proposals/pytorch-operator-proposal.md
@@ -120,9 +120,11 @@ spec:
 The worker spec generates a pod. They will communicate to the master through the master's service name.
 
 ## Design
-This is an implementaion of the PyTorch distributed design patterns, found [here](http://pytorch.org/tutorials/intermediate/dist_tuto.html), via the lense of TFJob found [here](https://github.com/kubeflow/tf-operator).
+This is an implementaion of the PyTorch distributed design patterns, found [here](http://pytorch.org/tutorials/intermediate/dist_tuto.html), via the lense of TFJob found [here](https://github.com/kubeflow/tf-operator). In the case of Kubernetes, because the operator is able to easily apply configurations to each process, we will use the environment variable initialization method found [here](http://pytorch.org/tutorials/intermediate/dist_tuto.html#initialization-methods).
+
+In most training examples, the pods will communicate via the all-reduce function in order to average the gradients.
+![All-Reduce Pytorch](diagrams/all-reduce-pytorch-operator.jpeg)
 
-Diagram pending
 
 ## Alternatives Considered
 One alternative considered for the CRD spec is shown below: