Repository: kubernetes/autoscaler (Go)

Issue:
Rename atomic-scale-up.kubernetes.io to best-effort-atomic-scale-up.kubernetes.io
**Which component are you using?**:
cluster-autoscaler

Current implementation for `atomic-scale-up.kubernetes.io` in https://github.com/kubernetes/autoscaler/pull/6824 does not guarantee atomicity, so I suggest to rename the ProvisioningClass to `best-effort-atomic-scale-up.kubernetes.io.`

We can add an additional to the class parameter later if the atomicity is required and modify implementation to support it. 


Discussion: /assign @aleksandra-malinowska 
Can we define "atomicity" for the purpose of this discussion?

For me, 'atomic' here means "either request all resources or none". In this specific case, it seems more important what cluster autoscaler **won't** do - it won't request resources if they wouldn't accommodate the entire ProvisioningRequest. And this is what current implementation does (or will do, when merged). It never requests partial resources.

But autoscaler can inadvertently create redundant resources - by requesting a full scale-up that is only partially realized. This risk is unavoidable. We can't promise a random VM failure won't happen and result only in some resources becoming ready. If this were part of our definition, then we're never going to achieve it - making it also unnecessary to differentiate between "best effort" and "truly atomic", since the latter won't happen.

Now, what the current implementation doesn't do is wait for the nodes to come up before marking the ProvisioningRequest as provisioned. So the workload can be admitted before the resources are ready, and before we know for sure that they will become ready. The latter IMHO is not about the atomicity of scale up, but rather about "admit the workload only if all pods can be accommodated" - which is already done be `check-capacity` provisioning class, without the use of the term 'atomic'.

In other words - I believe this discussion isn't really about scale-up (there's nothing we can change in scale-up itself to make it any more atomic), but about when will the workload be admitted. 

As for that, we can either modify how `(best-effort-)atomic` class works (if we consider current early admission a bug), or add a new class which will behave as `(best-effort-)atomic` when requesting capacity, and then as `check-capacity` when waiting for resources to be provisioned. This would require a change to the ProvisioningRequest API (allowing us to mark it as "resource requested" rather than as provisioned) and only minimal changes to the existing implementations of provisioning classes.
Seems reasonable, the original proposal was a rough sketch of this idea. The `atomic-scale-up` was not used anywhere and it was just a place-holder.
Given the fact that we are not making less guarantees for the atomicity  so prefixing the `best-effort-` should be a way to go.



Fix (patch):
diff --git a/cluster-autoscaler/apis/provisioningrequest/autoscaling.x-k8s.io/v1beta1/types.go b/cluster-autoscaler/apis/provisioningrequest/autoscaling.x-k8s.io/v1beta1/types.go
index 31cb27e901bc..05f9fcbe5a49 100644
--- a/cluster-autoscaler/apis/provisioningrequest/autoscaling.x-k8s.io/v1beta1/types.go
+++ b/cluster-autoscaler/apis/provisioningrequest/autoscaling.x-k8s.io/v1beta1/types.go
@@ -197,7 +197,7 @@ const (
 	// ProvisioningClassCheckCapacity denotes that CA will check if current cluster state can fulfill this request,
 	// and reserve the capacity for a specified time.
 	ProvisioningClassCheckCapacity string = "check-capacity.autoscaling.x-k8s.io"
-	// ProvisioningClassAtomicScaleUp denotes that CA try to provision the capacity
+	// ProvisioningClassBestEffortAtomicScaleUp denotes that CA try to provision the capacity
 	// in an atomic manner.
-	ProvisioningClassAtomicScaleUp string = "atomic-scale-up.autoscaling.x-k8s.io"
+	ProvisioningClassBestEffortAtomicScaleUp string = "best-effort-atomic-scale-up.autoscaling.x-k8s.io"
 )