Add readyReplicas to replica sets

[0xmichalis]

@bgrant0607 for the api changes

@bprashanth for the controllers changes

@deads2k fyi

---

This change is

[0xmichalis]

@gabemontero @bparees @livelace you may be interested in this PR

[krmayankk]

its amazing to see so much changes for adding a single field. Curious get rs, still shows DESIRED/CURRENT columns, where does that come from ?

[0xmichalis]

CURRENT is the replicas the rs created - the new field shows how many of
them are available.

On Sun, Jul 24, 2016 at 10:02 AM, krmayankk notifications@github.com
wrote:

its amazing to see so much changes for adding a single field. Curious get
rs, still shows DESIRED/CURRENT columns, where does that come from ?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#29481 (comment),
or mute the thread
/~https://github.com/notifications/unsubscribe-auth/ADuFf7ICGyKP7L3-d_XVCT8feH_q3CPFks5qYxwFgaJpZM4JTOYw
.

[krmayankk]

@Kargakis thanks for clarifying

[lavalamp]

We have two concepts for pods-- live, and ready, I would use one of those terms. What does "Available" mean?

What do you intend to use this field for?

[0xmichalis]

We use AvailableReplicas in Deployments. A pod is considered available once N seconds pass since it was transitioned to Ready (for d.spec.minReadySeconds=N). So, for Deployments with minReadySeconds=0, a pod is considered available once it is ready. @bgrant0607 do we want to document this in API conventions?

The field in the RC/RS would be useful: 1) on its own - currently just by looking at the status, users cannot determine if their apps are up and running, instead they need to look into pods. 2) Deployments already do this but they need to get into the pod level in order to determine pod availability, whereas for any other info they look into the replica set spec/status. Calculating available pods in the replica set level is pretty cheap and it will remove some complexity from the deployment controller (albeit not much until we consider adding minReadySeconds in RC/RS).

[livelace]

Thanks! It's a good news!

FIY @gabemontero @bparees

Tested with: v1.4.0-alpha.1

Status of the deployment with /bin/true in postStart hook:

status:
availableReplicas: 1
observedGeneration: 2
replicas: 1
updatedReplicas: 1

Status of the deployment with /bin/false in postStart hook:

status:
observedGeneration: 2
replicas: 1
unavailableReplicas: 1
updatedReplicas: 1

It means that we can say explicitly, that a deployment is done/failed :)

[gabemontero]

Sounds great @livelace. Once this change gets pulled into openshift's k8s godeps, we can look into updating the openshift java restclient (fyi @jcantril) and openshift jenkins plugin to interrogate the AvailableReplicas field.

And thanks @Kargakis for making this happen.

[bgrant0607]

@Kargakis Please name this field ReadyReplicas. It doesn't have the same meaning as the AvailableReplicas field in Deployment, and I think it would be useful for both APIs to have both fields eventually. We might add minReadySeconds to RC/RS, or could even add it to Pod, which might be useful in conjunction with DisruptionBudget.

Ref #7483

[0xmichalis]

@bgrant0607 switched to ReadyReplicas

[bgrant0607]

ref kubernetes-retired/contrib#869

[janetkuo]

LGTM

[0xmichalis]

Rebased + applying lgtm

[0xmichalis]

@deads2k look at the googlebot respecting me after so long:)

[0xmichalis]

From reviewable: 1 discussion left (janetkuo, lavalamp)

[k8s-bot]

GCE e2e build/test passed for commit 46291d5.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

[k8s-github-robot]

@k8s-bot test this [submit-queue is verifying that this PR is safe to merge]

[k8s-bot]

GCE e2e build/test passed for commit 46291d5.

• Test Results
• Build Log
• Test Artifacts
• Internal Jenkins Results

[k8s-github-robot]

Automatic merge from submit-queue