Use new deployment scale endpoint to request a scale event

[0xmichalis]

Use the new deploymentconfigs/{name}/scale endpooint instead of trying to resolve the latest deployment for a config in the client.

Btw I would love if I could poll the scale subresource (GET dc/%s/scale instead of polling the latest rc) in case of a specified --timeout (which means wait until all pods are up) but getting the scale of a dc isn't returning the current replicas of the latest.

@ironcladlou @DirectXMan12

[0xmichalis]

@jwforres @spadgett PUT /deploymentconfigs/{name}/scale is what you want in order to scale the latest deployment (replication controller) for a dc. You would need to construct a scale resource like I am doing here and plug the desired replicas before querying.

[0xmichalis]

[test]

[0xmichalis]

@ironcladlou note that by making this switch, we allow deployments (rcs) to be scaled only when they are complete due to

origin/pkg/deploy/registry/deployconfig/etcd/etcd.go

Line 222 in d81eca7

if deploymentStatus := util.DeploymentStatusFor(controller); deploymentStatus != api.DeploymentStatusComplete {

. I think this is good. Thoughts?

[liggitt]

@Kargakis @ironcladlou I would expect to be able to adjust the target scale regardless of whether a deployment was in progress

[0xmichalis]

@Kargakis @ironcladlou I would expect to be able to adjust the target scale regardless of whether a deployment was in progress

Say you have dc/config with config.spec.version = 3, config-3.spec.replicas = 5, and a symmetric strategy (so new desired is 5 too), and you are kicking off a 4th deployment.

config-3 -> config-4

And in the middle of the deployment process you try to oc scale dc/config --replicas=10 (which essentially is PUT /replicationcontrollers/config-4). The fourth deployment will be scaled to 10 and by the time the deployer process finishes you can get two outcomes:

1. Deployer succeeds: the deployment will be scaled to the desired replicas based on your strategy (so in our case config-4 will be scaled down from 10 to 5).
2. Deployer fails: the deployment will be scaled down to zero. (10->0)

Note that this happens now.

I don't see why would oc scale have to work against a running deployment since the user has already defined a strategy about it. This PR essentially will skip the meaningless scaling that happens above (meaningless based on the current system behavior).

[openshift-bot]

Evaluated for origin test up to 55f7b3b

[openshift-bot]

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_origin/7070/)

[ironcladlou]

You can't safely adjust the scale of an in progress deployment due without a fix for #5597.

[liggitt]

You can't safely adjust the scale of an in progress deployment due without a fix for #5597.

Agree, but it sounded like @Kargakis was arguing that you shouldn't be allowed to adjust dc scale while a deployment was in progress, even once we resolve race and controller contention issues. I think you should.

[jwforres]

I agree with @liggitt You should be able to adjust the scale even if the
deployment is still in progress.

On Thu, Nov 12, 2015 at 9:38 AM, Jordan Liggitt notifications@github.com
wrote:

You can't safely adjust the scale of an in progress deployment due without
a fix for #5597 #5597.

Agree, but it sounded like @Kargakis https://github.com/kargakis was
arguing that you shouldn't be allowed to adjust dc scale while a
deployment was in progress, even once we resolve race and controller
contention issues. I think you should.

—
Reply to this email directly or view it on GitHub
#5852 (comment).

[ironcladlou]

@liggitt @jwforres

You can't safely adjust the scale of an in progress deployment due without a fix for #5597.

Agree, but it sounded like @Kargakis was arguing that you shouldn't be allowed to adjust dc scale while a deployment was in progress, even once we resolve race and controller contention issues. I think you should.

I agree with @liggitt You should be able to adjust the scale even if the deployment is still in progress.

To clarify: yes, you should be able to scale regardless of whether a deployment is in-progress. The only reason there is any code to restrict that is to work around #5597.

[0xmichalis]

As long as there is a single point that actually scales the deployment (what #5597 is going to do), I'm fine with scaling whenever you want.

[ironcladlou]

This PR has been rolled into #5875

[0xmichalis]

:katamari'd: