Deployments page should not allow users to scale up when quota is reached

[andrewazores]

Parent: #3344

Task

Disable the "Scale Up" button within deployment cards when the resource quota for the environment has been reached.

[joshuawilson]

@andrewazores, @qodfathr said this is not a P0.

[andrewazores]

OK. Do we want to close the PR or continue to merge this? FWIW I can see the argument against including the Launcher changes, but the change here to disable the Scale Up button in Deployments still seems to make sense IMO.

[qodfathr]

How does the OpenShift Console handle this? We probably should at least be consistent.

[andrewazores]

It allows the user to attempt to scale up, but then fails the action and links to the Events tab where it provides more detail on the cause of the failure. We don't have the ability to listen for these events from the Deployments page yet so we can't follow that pattern yet - this is discussed briefly in #2629 and the issue for it is #2380 .

[qodfathr]

Will the disabling of the scale up be reactive? i.e. if I'm on the deployments page and I do something, say in another browser tab, to free up resources, will the button enable automatically?

Also, what's the determination for disabling? If I'm out of RAM quota, sure -- that's a valid reason. But I could also have a little bit of RAM left yet it's not enough to scale up. In that case, doesn't the problem remain? I'm happy with fixing a common use case, but I want to ensure that it is, in fact, common.

[andrewazores]

Yes, it will enable/disable automatically, but only following the next polling cycle within whichever tab or client you're interested in. These cycles occur once per minute. Once a polling cycle occurs the data model will reflect that the environment quota has been reached (or not), and the button state will be updated to reflect this. This is completely independent of whether or not the tab or client instance you're using is the one that initiated the scale request.

The disable criteria in the PR is when either CPU or Memory quotas have been reached or exceeded for the environment. If you had your configs set up so that with 1024MB of quota you had allocated 1023MB to one pod, the button would still be enabled since you could technically allocate one more pod with 1MB of memory, even if this is not doable in practice. Similarly you could manually create a config that attempts to assign 2GB of memory to each pod when you only have 1GB total available, so you would not be able to scale even 1 pod. In this case the button will still remain enabled, because your resource usage at the moment is 0 of 1GB. I don't think we have a way to query for the quota request size, otherwise this logic could be smarter and block you not only when you are already at quota but also when the action will clearly overshoot quota.

[qodfathr]

I'm okay with the proposal, but I'll defer to @catrobson for a final determination.

[joshuawilson]

@catrobson we need confirmation from you as @andrewazores has a PR for this.

[catrobson]

+1 on this proposal as well. I'd like to see us file an issue for the future around seeing if we can capture 'requested quota" from OS as an improvement as I expect that won't be a rare situation to run into.

[andrewazores]

@catrobson tracking it here: https://openshift.io/openshiftio/openshiftio/plan/detail/2240 . I will file issues for individual fabric8-ui and fabric8-wit tasks for this feature and add them to the comments there.