Add risks and mitigations and phases

Author: gnufied

keps/sig-storage/5030-attach-limit-autoscaler/README.md

@@ -148,6 +148,9 @@ Scheduler changes can only be merged after cluster-autoscaler changes has been G
 
 ### Risks and Mitigations
 
+As mentioned above, there is a risk associated with scheduler changes being merged before cluster-autoscaler changes can be merged, but we want to mitigate
+this by making sure cluster-autoscaler changes are merged first and has N+2 window before scheduler changes can be made GA. 
+
 <!--
 What are the risks of this proposal, and how do we mitigate? Think broadly.
 For example, consider both security and how this will impact the larger
@@ -288,8 +291,16 @@ We will add tests that validate both scaling from 0 and scaling from 1 use cases
 
 #### Alpha
 
-- All of the planned code changes for alpha will be done in cluster-autoscaler and not in k/k repository.
-- Initial e2e tests completed and enabled
+##### Phase-1
+
+- This is MVP of cnhanges in cluster-autoscaler.
+- All of the planned code changes for Phase1- alpha will be done in cluster-autoscaler and not in k/k repository.
+  We plan to impelemnt changes in cluster-autoscaler so as it can consider volume limits when scaling cluster.
+
+##### Phase-2
+- Make changes in `kube-scheduler` so as it can stop scheduling of pods that require CSI volume if underlying CSI volume is not installed on the node.
+- Initial e2e tests completed and enabled.
+
 
 <!---
 #### Beta
@@ -324,6 +335,12 @@ in back-to-back releases.
 
 ### Upgrade / Downgrade Strategy
 
+For the case of newer scheduler running with older autoscaler, we propose that `VolumeLimitScaling` feature
+should be disabled in the scheduler. 
+
+Upgrade and downgrade of `cluster-autoscaler` should be straightforward since there are no API changes 
+involved and it just means the feature will stop working once downgraded.
+
 <!--
 If applicable, how will the component be upgraded and downgraded? Make sure
 this is in the test plan.