What do you mean by "made public"?

Why isn't the authoritative source of the desired number of replicas always in Openshift's deployment config?

Because of autoscaling - we want to let the autoscaler manage a replication controller group, which means the deployment config can't be authoritative in the presence. Therefore the deployment config has to let the state of the cluster be authoritative, unless there are no other RCs present, in which it falls back to its initial value.

1. Initial creation of a deployment, value in deployment.replicas chosen
2. Deployment exists, 1 RC size 0 and 1 RC size 10, no autoscaler. Next deployment should have size 10
3. Deployment exists, 1 RC size 2 and 1 RC size 8, no autoscaler. Next deployment (if you allow one to start) should have 10.
4. Deployment exists, autoscaler present, 1 RC size 3. Autoscaler scales up RC to 4 while deployment is happening. Final RC state should be 4
5. Deployment exists, all DCs deleted, value in deployment.replicas chosen.

----- Original Message -----

What do you mean by "made public"?

Why isn't the authoritative source of the desired number of replicas always
in Openshift's deployment config?

---

Reply to this email directly or view it on GitHub:
#7851 (comment)

Revisiting all rolling-update issues/PRs.

I would like to make the rolling-update code reusable outside kubectl, such as in Deployment (#1743), and am in favor of making kubectl logic reusable, in general (#7311).

That said, I'm not sure the current annotations are the right ones. I previously commented on this here: #2863 (comment)

One simplification we could make would be to rectify the difference between the current number of replicas and new desired number of replicas at the beginning instead of at the end. That might enable us to drop the desired-replicas annotation.

When a Deployment is present, there's the question of whether the auto-scaler should scale the RCs directly (e.g., by scaling the largest one), or whether it should scale the Deployment using a polymorphic virtual scale resource (#1629), leaving up to Deployment to propagate the change to the underlying RCs. If we took the former approach, we should consider not keeping a replica count in Deployment, or performing a bidirectional sync with the replica counts of the RCs. While the former would be really cool (like syncing contacts between a smartphone and browser), I'm leaning towards the latter, which I believe we need, anyway, for Jobs (#1624) and nominal services (#260).

cc @nikhiljindal

This can be closed.