Specific error message on failed rolling update issued by older kubectl against 1.4 master #32751

caesarxuchao · 2016-09-15T00:50:01Z

kubernetes-e2e-gke-1.4-1.3-kubectl-skew (1.3 kubectl and 1.4 master) test suite failed with:

k8s.io] Kubectl client [k8s.io] Kubectl rolling-update should support rolling-update to same image [Conformance]
...
Error from server: object is being deleted: replicationcontrollers "e2e-test-nginx-rc" already exists error: exit status 1 not to have occurred

It's because the old RC had an orphanFinalizer, so it is not deleted from the key-value store immediately. In turn, the creation of the new RC of the same name failed.

In this failure, the RC and pods are updated, it's just that the RC is of different name, i.e., original name + a hash generated based on podTemplate. The error is confusing to user, but not that bad. So this PR just prints a warning message to instruct users how to work around.

1.4 kubectl rolling-update uses different logic so it's working.

@lavalamp @gmarek @janetkuo @pwittrock

cc @liggitt for the ctx changes.

This change is

lavalamp

It would be good to make these changes but not if it means we don't make the next cherry-pick.

lavalamp · 2016-09-15T00:57:17Z

pkg/registry/generic/registry/store.go

+			if e.QualifiedResource.Resource != "replicationcontrollers" {
+				return nil, err
+			}
+			*msg = fmt.Sprintf("Note: if you are using \"kubectl rolling-update\" and your kubectl version is older than v1.4.0, your rolling-update is probably failed. Your pods are successfully updated, but the name of the RC is its original name plus a hash value. If you want to rename the RC, please use a kubectl newer than v1.4.0, then run rolling-update to change the name. : %s", *msg)


Link to a document instead of explaining the entire problem right here?

This is really really nasty. Is this the best we can do? I'd like a mini-post-mortem on how we got this far with an incompatible change...

I cannot think of a better way. @lavalamp suggested kubectl's user-agent should contain the operation name, then we can do finer control from the server side. See #32725.

I think the 'mini-postmortem' would contain mostly the statement that the problem appeared because no one from people working on this feature knew anything about kubectl, and it wasn't caught by our upgrade tests because we didn't have any that were passing ever...

I knew it from the beginning...I stated the backward incompatibility in #29971. I was under the impression kubectl rolling-update was being deprecated by deployment, and we were not looking at the upgrade tests, so it went unnoticed.

lavalamp · 2016-09-15T00:57:46Z

pkg/registry/generic/registry/store.go

+			if !strings.Contains(userAgent, "kubectl") {
+				return nil, err
+			}
+			// example userAgent string: kubectl-1.3/v1.3.8 (linux/amd64) kubernetes/e328d5b


Move this parsing into its own function.

thockin · 2016-09-15T03:23:07Z

pkg/registry/generic/registry/store.go

+			if versionErr != nil {
+				return nil, err
+			}
+			if kubectlVersion.GTE(version.MustParse("v1.4.0")) {


Please TODO this to remove after 1.6.

So we have to be compatible for 3 versions? Is this documented?

Todo added.

thockin · 2016-09-15T03:24:22Z

pkg/registry/generic/registry/store.go

+			if e.QualifiedResource.Resource != "replicationcontrollers" {
+				return nil, err
+			}
+			*msg = fmt.Sprintf("Note: if you are using \"kubectl rolling-update\" and your kubectl version is older than v1.4.0, your rolling-update is probably failed. Your pods are successfully updated, but the name of the RC is its original name plus a hash value. If you want to rename the RC, please use a kubectl newer than v1.4.0, then run rolling-update to change the name. : %s", *msg)


This is really really nasty. Is this the best we can do? I'd like a mini-post-mortem on how we got this far with an incompatible change...

caesarxuchao · 2016-09-15T05:12:23Z

@lavalamp comments addressed.

thockin · 2016-09-15T05:25:47Z

I was just wild-guessing. I mean, really, we should NEVER be incompatible
until v2, and even then plus 1 year.

On Wed, Sep 14, 2016 at 10:10 PM, Chao Xu notifications@github.com wrote:

@caesarxuchao commented on this pull request.

In pkg/registry/generic/registry/store.go
#32751:
@@ -249,6 +250,27 @@ func (e _Store) Create(ctx api.Context, obj runtime.Object) (runtime.Object, err
if accessor.GetDeletionTimestamp() != nil {
msg := &err.(_kubeerr.StatusError).ErrStatus.Message
*msg = fmt.Sprintf("object is being deleted: %s", *msg)
    userAgent, _ := api.UserAgentFrom(ctx)
    if !strings.Contains(userAgent, "kubectl") {
        return nil, err
    }
    // example userAgent string: kubectl-1.3/v1.3.8 (linux/amd64) kubernetes/e328d5b
    userAgent = strings.Split(userAgent, " ")[0]
    subs := strings.Split(userAgent, "/")
    if len(subs) != 2 {
        return nil, err
    }
    kubectlVersion, versionErr := version.Parse(subs[1])
    if versionErr != nil {
        return nil, err
    }
    if kubectlVersion.GTE(version.MustParse("v1.4.0")) {
So we have to be compatible for 3 versions? Is this documented?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#32751, or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVOO40FN_nyJA6GqzKGDGZXm7eGKzks5qqNM3gaJpZM4J9ZUP
.

caesarxuchao · 2016-09-15T18:34:02Z

CHANGELOG.md

@@ -188,6 +189,9 @@ binary | sha256 hash

 **No notable changes for this release**

+## Known issues
+
+* master newer than v1.4.0 has backward compatible issues with older kubectl. Specifically, if "kubectl rolling-update" does not change the name of the replication controller (RC), the command will fail to create the new RC and report the RC already exists. When this happens, the pods are successfully updated, but the name of the RC is its original name plus a hash value. If you want to rename the RC, please download a kubectl newer than v1.4.0, then run rolling-update to change the name.


TODO: I'll paste this to #32332 when the PR is approved.

I'm going to help out with the wording here-- I've started something better below. Also, please start a section specifically about the behavior changes the garbage collector introduces and put this there.

`kubectl` 1.3's rolling-update command is compatible with Kubernetes 1.4 and higher **only if** you specify a new replication controller name. You will need to update to kubectl 1.4 or higher to use the rolling update command against a 1.4 cluster if you want to keep the original name, or you'll have to do two rolling updates. If you do happen to use kubectl 1.3's rolling update against a 1.4 cluster, it will fail, usually with an error message that will direct you here. If you saw that error, then don't worry, the operation succeeded except for the part where the new replication controller is renamed back to the old name. You can just do another rolling update to change the name back: look for a replication controller that has the original name plus a random suffix. Unfortunately, there is a second possible failure mode: <describe failure mode> If this happens to you, then <describe fix>

caesarxuchao · 2016-09-15T21:35:32Z

@lavalamp could you take another look? Thanks.

lavalamp · 2016-09-15T22:04:34Z

pkg/registry/generic/registry/store.go

+			if e.QualifiedResource.Resource != "replicationcontrollers" {
+				return nil, err
+			}
+			*msg = fmt.Sprintf("Note: if you are using \"kubectl rolling-update\" and your kubectl version is older than v1.4.0, your rolling-update is probably failed, though the pods are correctly updated. Please see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#known-backward-compatibility-issues for a workaround. : %s", *msg)


s/rolling-update is probably/rolling-update has probably/

The link is not specific enough, it needs to link not to the rolling changelog but to a specific heading within it.

lavalamp · 2016-09-15T22:12:47Z

CHANGELOG.md

@@ -188,6 +189,9 @@ binary | sha256 hash

 **No notable changes for this release**

+## Known issues
+
+* master newer than v1.4.0 has backward compatible issues with older kubectl. Specifically, if "kubectl rolling-update" does not change the name of the replication controller (RC), the command will fail to create the new RC and report the RC already exists. When this happens, the pods are successfully updated, but the name of the RC is its original name plus a hash value. If you want to rename the RC, please download a kubectl newer than v1.4.0, then run rolling-update to change the name.


I'm going to help out with the wording here-- I've started something better below. Also, please start a section specifically about the behavior changes the garbage collector introduces and put this there.

`kubectl` 1.3's rolling-update command is compatible with Kubernetes 1.4 and higher **only if** you specify a new replication controller name. You will need to update to kubectl 1.4 or higher to use the rolling update command against a 1.4 cluster if you want to keep the original name, or you'll have to do two rolling updates. If you do happen to use kubectl 1.3's rolling update against a 1.4 cluster, it will fail, usually with an error message that will direct you here. If you saw that error, then don't worry, the operation succeeded except for the part where the new replication controller is renamed back to the old name. You can just do another rolling update to change the name back: look for a replication controller that has the original name plus a random suffix. Unfortunately, there is a second possible failure mode: <describe failure mode> If this happens to you, then <describe fix>

janetkuo · 2016-09-15T23:22:59Z

CHANGELOG.md

@@ -216,6 +217,9 @@ binary | sha256 hash

 **No notable changes for this release**

+## Known issues
+
+* master newer than v1.4.0 has backward compatible issues with older kubectl. Specifically, if "kubectl rolling-update" does not change the name of the replication controller (RC), the command will fail to create the new RC and report the RC already exists. When this happens, the pods are successfully updated, but the name of the RC is its original name plus a hash value. If you want to rename the RC, please download a kubectl newer than v1.4.0, then run rolling-update to change the name.


Suggest making a section or bullet point here to let people know it's specific to kubectl rolling-update so they can skip if they're not using it. Something like:

kubectl rolling-update

blah blah

or

kubectl rolling-update: blah blah

…t 1.4 cluster

caesarxuchao · 2016-09-16T00:21:39Z

@lavalamp PTAL. Thanks.

lavalamp · 2016-09-16T03:25:15Z

CHANGELOG.md

+
+### kubectl delete
+
+If you use an old version kubectl to delete a replication controller or replicaset, then after the delete command has returned, the replication controller or the replicaset will continue to exist in the key-value store for a short period of time (<1s). You probably will not notice any difference if you use kubectl manually, but you might notice it if you are using kubectl in a script.


What should people do to fix their scripts?

lavalamp · 2016-09-16T03:26:26Z

OK, the contents look pretty good now, but we need to fix the grammar :)

Maybe we should merge and fix in a followup.

lavalamp · 2016-09-16T03:34:54Z

@pwittrock @eparis this doesn't fix kubectl 1.3 but it does make the failure mode much better. Please cherrypick.

k8s-github-robot · 2016-09-16T03:58:42Z

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

k8s-bot · 2016-09-16T04:37:14Z

GCE e2e build/test passed for commit c4ea205.

k8s-github-robot · 2016-09-16T04:41:56Z

Automatic merge from submit-queue

gmarek · 2016-09-16T14:06:12Z

pkg/registry/generic/registry/store.go

+			if !isOldKubectl(userAgent) {
+				return nil, err
+			}
+			if e.QualifiedResource.Resource != "replicationcontrollers" {


Can't it happen for replica sets as well?

OK, this new review thingy is strange - I see @lavalamp's reply at the bottom.

I don't know - I thought that replica set is just a copy of replication controller + new selector.

kubectl rolling-update only works with rc, so we don't worry about rs.

gmarek · 2016-09-16T14:06:48Z

pkg/registry/generic/registry/store.go

+			if e.QualifiedResource.Resource != "replicationcontrollers" {
+				return nil, err
+			}
+			*msg = fmt.Sprintf("Note: if you are using \"kubectl rolling-update\" and your kubectl version is older than v1.4.0, your rolling-update has probably failed, though the pods are correctly updated. Please see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#kubectl-rolling-update for a workaround. : %s", *msg)


Shouldn't we check if the error is actually a name collision, not e.g. internal server error?

It's checked a few lines before.

if !kubeerr.IsAlreadyExists(err) { return nil, err }

Oh, OK - I was looking only at your changes.

lavalamp · 2016-09-16T17:01:04Z

There's also the step where Chao fixed kubectl and I must have been asleep
because it failed to trigger the "oh hey that's compatibility problem"
mental module. :(

On Fri, Sep 16, 2016 at 4:48 AM, Marek Grabowski notifications@github.com
wrote:

@gmarek commented on this pull request.

In pkg/registry/generic/registry/store.go
#32751:
      userAgent = strings.Split(userAgent, " ")[0]
    subs := strings.Split(userAgent, "/")
    if len(subs) != 2 {
        return nil, err
    }
    kubectlVersion, versionErr := version.Parse(subs[1])
    if versionErr != nil {
        return nil, err
    }
    if kubectlVersion.GTE(version.MustParse("v1.4.0")) {
        return nil, err
    }
    if e.QualifiedResource.Resource != "replicationcontrollers" {
        return nil, err
    }
    *msg = fmt.Sprintf("Note: if you are using \"kubectl rolling-update\" and your kubectl version is older than v1.4.0, your rolling-update is probably failed. Your pods are successfully updated, but the name of the RC is its original name plus a hash value. If you want to rename the RC, please use a kubectl newer than v1.4.0, then run rolling-update to change the name. : %s", *msg)
I think the 'mini-postmortem' would contain mostly the statement that the
problem appeared because no one from people working on this feature knew
anything about kubectl, and it wasn't caught by our upgrade tests because
we didn't have any that were passing ever...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#32751, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnglmfyI3J16akPxQ82ZzGwv-mIDd4Cks5qqoIrgaJpZM4J9ZUP
.

lavalamp · 2016-09-16T17:01:49Z

I was under the impression that rolling-update doesn't work on RS, if
that's not the case then we need to see if it's broken in 1.4 as well...

On Fri, Sep 16, 2016 at 7:06 AM, Marek Grabowski notifications@github.com
wrote:

@gmarek commented on this pull request.

In pkg/registry/generic/registry/store.go
#32751 (review)
:
@@ -252,6 +272,15 @@ func (e _Store) Create(ctx api.Context, obj runtime.Object) (runtime.Object, err
if accessor.GetDeletionTimestamp() != nil {
msg := &err.(_kubeerr.StatusError).ErrStatus.Message
*msg = fmt.Sprintf("object is being deleted: %s", *msg)
    // TODO: remove this block after 1.6
    userAgent, _ := api.UserAgentFrom(ctx)
    if !isOldKubectl(userAgent) {
        return nil, err
    }
    if e.QualifiedResource.Resource != "replicationcontrollers" {
Can't it happen for replica sets as well?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#32751 (review),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAngll83YHAp_J_7k19YKizIZXK_fMUQks5qqqJegaJpZM4J9ZUP
.

lavalamp · 2016-09-16T17:02:15Z

Yeah, good point. @ceaserxuchao can you make a followup? Thanks!

On Fri, Sep 16, 2016 at 7:06 AM, Marek Grabowski notifications@github.com
wrote:

@gmarek commented on this pull request.

In pkg/registry/generic/registry/store.go
#32751 (review)
:
@@ -252,6 +272,15 @@ func (e _Store) Create(ctx api.Context, obj runtime.Object) (runtime.Object, err
if accessor.GetDeletionTimestamp() != nil {
msg := &err.(_kubeerr.StatusError).ErrStatus.Message
*msg = fmt.Sprintf("object is being deleted: %s", *msg)
    // TODO: remove this block after 1.6
    userAgent, _ := api.UserAgentFrom(ctx)
    if !isOldKubectl(userAgent) {
        return nil, err
    }
    if e.QualifiedResource.Resource != "replicationcontrollers" {
        return nil, err
    }
    *msg = fmt.Sprintf("Note: if you are using \"kubectl rolling-update\" and your kubectl version is older than v1.4.0, your rolling-update has probably failed, though the pods are correctly updated. Please see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#kubectl-rolling-update for a workaround. : %s", *msg)
Shouldn't we check if the error is actually a name collision, not e.g.
internal server error?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#32751 (review),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAngllxudus3JG5hbiKpK-KwKYrMLrb0ks5qqqKBgaJpZM4J9ZUP
.

@lavalamp

…rolling-update Automatic merge from submit-queue Specific error message on failed rolling update issued by older kubectl against 1.4 master Fix kubernetes#32706 `kubernetes-e2e-gke-1.4-1.3-kubectl-skew` (1.3 kubectl and 1.4 master) test suite failed with: ``` k8s.io] Kubectl client [k8s.io] Kubectl rolling-update should support rolling-update to same image [Conformance] ... Error from server: object is being deleted: replicationcontrollers "e2e-test-nginx-rc" already exists error: exit status 1 not to have occurred ``` It's because the old RC had an orphanFinalizer, so it is not deleted from the key-value store immediately. In turn, the creation of the new RC of the same name failed. In this failure, the RC and pods are updated, it's just that the RC is of different name, i.e., original name + a hash generated based on podTemplate. The error is confusing to user, but not that bad. So this PR just prints a warning message to instruct users how to work around. 1.4 kubectl rolling-update uses different logic so it's working. @lavalamp @gmarek @janetkuo @pwittrock cc @liggitt for the ctx changes. (cherry picked from commit a39cee9) [remove the CHANGELOG changes to make pick possible]

k8s-cherrypick-bot · 2016-09-17T08:07:27Z

Commit found in the "release-1.4" branch appears to be this PR. Removing the "cherrypick-candidate" label. If this is an error find help to get your PR picked.

@lavalamp

…-collector-error Automatic merge from submit-queue Improve error message when kubectl rolling-update fail due to version skew  **What this PR does / why we need it**: follow up #32751, we should print the real error message first, the workaround later **Before:** ```console $ kubectl rolling-update nginx --image=redis Created nginx-6ee4372891ec51a97dfbf83ed0846886 Scaling up nginx-6ee4372891ec51a97dfbf83ed0846886 from 0 to 1, scaling down nginx from 1 to 0 (keep 1 pods available, don't exceed 2 pods) Scaling nginx-6ee4372891ec51a97dfbf83ed0846886 up to 1 Scaling nginx down to 0 Update succeeded. Deleting old controller: nginx Renaming nginx-6ee4372891ec51a97dfbf83ed0846886 to nginx Error from server: Note: if you are using "kubectl rolling-update" and your kubectl version is older than v1.4.0, your rolling-update has probably failed, though the pods are correctly updated. Please see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#kubectl-rolling-update for a workaround. : object is being deleted: replicationcontrollers "nginx" already exists ``` **After:** (see the error message) ```console $ kubectl rolling-update nginx --image=redis Created nginx-12b5782bcdff627fca46537e9e1045f8 Scaling up nginx-12b5782bcdff627fca46537e9e1045f8 from 0 to 1, scaling down nginx from 1 to 0 (keep 1 pods available, don't exceed 2 pods) Scaling nginx-12b5782bcdff627fca46537e9e1045f8 up to 1 Scaling nginx down to 0 Update succeeded. Deleting old controller: nginx Renaming nginx-12b5782bcdff627fca46537e9e1045f8 to nginx Error from server: object is being deleted: replicationcontrollers "nginx" already exists: if you're using "kubectl rolling-update" with kubectl version older than v1.4.0, your rolling update has failed, though the pods are correctly updated. Please see https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#kubectl-rolling-update for a workaround ``` **Which issue this PR fixes** *(optional, in `fixes #<issue number>(, #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes # **Special notes for your reviewer**: **Release note**:  ```release-note NONE ``` Print the real error message first, the workaround later @lavalamp @gmarek

@lavalamp

…rolling-update Automatic merge from submit-queue Specific error message on failed rolling update issued by older kubectl against 1.4 master Fix kubernetes#32706 `kubernetes-e2e-gke-1.4-1.3-kubectl-skew` (1.3 kubectl and 1.4 master) test suite failed with: ``` k8s.io] Kubectl client [k8s.io] Kubectl rolling-update should support rolling-update to same image [Conformance] ... Error from server: object is being deleted: replicationcontrollers "e2e-test-nginx-rc" already exists error: exit status 1 not to have occurred ``` It's because the old RC had an orphanFinalizer, so it is not deleted from the key-value store immediately. In turn, the creation of the new RC of the same name failed. In this failure, the RC and pods are updated, it's just that the RC is of different name, i.e., original name + a hash generated based on podTemplate. The error is confusing to user, but not that bad. So this PR just prints a warning message to instruct users how to work around. 1.4 kubectl rolling-update uses different logic so it's working. @lavalamp @gmarek @janetkuo @pwittrock cc @liggitt for the ctx changes. (cherry picked from commit a39cee9) [remove the CHANGELOG changes to make pick possible]

@liggitt

Automatic merge from submit-queue (batch tested with PRs 39114, 36004) Revert #32751 and #35840 in 1.6 Revert backward compatibility hacks (#36004, #32751) that are no-longer needed in release 1.6 @kubernetes/sig-api-machinery @liggitt

caesarxuchao added the sig/api-machinery Categorizes an issue or PR as relevant to SIG API Machinery. label Sep 15, 2016

caesarxuchao assigned lavalamp Sep 15, 2016

googlebot added the cla: yes label Sep 15, 2016

caesarxuchao changed the title ~~Specific error on failed rolling update issued by older kubectl against 1.4 master~~ Specific error message on failed rolling update issued by older kubectl against 1.4 master Sep 15, 2016

caesarxuchao added this to the v1.4 milestone Sep 15, 2016

k8s-github-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. release-note-label-needed labels Sep 15, 2016

lavalamp reviewed Sep 15, 2016

View reviewed changes

k8s-github-robot mentioned this pull request Sep 15, 2016

[k8s.io] Kubectl client [k8s.io] Kubectl run --quiet job should not output anything except the command when --quiet is set {Kubernetes e2e suite} #32548

Closed

thockin reviewed Sep 15, 2016

View reviewed changes

caesarxuchao force-pushed the specific-error-rolling-update branch 3 times, most recently from d680695 to 9d1bb90 Compare September 15, 2016 05:11

caesarxuchao force-pushed the specific-error-rolling-update branch from 9d1bb90 to 0534a3a Compare September 15, 2016 05:16

caesarxuchao force-pushed the specific-error-rolling-update branch from 0534a3a to 9b30f67 Compare September 15, 2016 17:02

k8s-github-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 15, 2016

caesarxuchao commented Sep 15, 2016

View reviewed changes

caesarxuchao mentioned this pull request Sep 15, 2016

[k8s.io] Kubectl client [k8s.io] Kubectl rolling-update should support rolling-update to same image [Conformance] #32706

Closed

caesarxuchao force-pushed the specific-error-rolling-update branch from 9b30f67 to 23f401b Compare September 15, 2016 20:45

k8s-github-robot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Sep 15, 2016

lavalamp suggested changes Sep 15, 2016

View reviewed changes

janetkuo reviewed Sep 15, 2016

View reviewed changes

caesarxuchao force-pushed the specific-error-rolling-update branch 4 times, most recently from e992784 to 380a32e Compare September 16, 2016 00:16

print instruction in case of failed kubectl 1.3 rolling-update agains…

c4ea205

…t 1.4 cluster

caesarxuchao force-pushed the specific-error-rolling-update branch from 380a32e to c4ea205 Compare September 16, 2016 00:20

lavalamp reviewed Sep 16, 2016

View reviewed changes

lavalamp added release-note Denotes a PR that will be considered when it comes time to generate release notes. lgtm "Looks good to me", indicates that a PR is ready to be merged. and removed release-note-label-needed labels Sep 16, 2016

lavalamp approved these changes Sep 16, 2016

View reviewed changes

lavalamp added the priority/important-soon Must be staffed and worked on either currently, or very soon, ideally in time for the next release. label Sep 16, 2016

lavalamp added the cherrypick-candidate label Sep 16, 2016

k8s-github-robot merged commit a39cee9 into kubernetes:master Sep 16, 2016

gmarek reviewed Sep 16, 2016

View reviewed changes

janetkuo mentioned this pull request Sep 16, 2016

Improve error message when kubectl rolling-update fail due to version skew #32885

Merged

eparis added the cherry-pick-approved Indicates a cherry-pick PR into a release branch has been approved by the release branch manager. label Sep 17, 2016

eparis mentioned this pull request Sep 17, 2016

Release 1.4 Cherrypick Batch #32911

Merged

k8s-cherrypick-bot removed the cherrypick-candidate label Sep 17, 2016

caesarxuchao mentioned this pull request Dec 21, 2016

Revert #32751 and #35840 in 1.6 #36004

Merged


		### kubectl delete

		If you use an old version kubectl to delete a replication controller or replicaset, then after the delete command has returned, the replication controller or the replicaset will continue to exist in the key-value store for a short period of time (<1s). You probably will not notice any difference if you use kubectl manually, but you might notice it if you are using kubectl in a script.

Specific error message on failed rolling update issued by older kubectl against 1.4 master #32751

Specific error message on failed rolling update issued by older kubectl against 1.4 master #32751

Conversation

caesarxuchao commented Sep 15, 2016 • edited Loading

lavalamp left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

caesarxuchao commented Sep 15, 2016

thockin commented Sep 15, 2016

@caesarxuchao commented on this pull request.

Choose a reason for hiding this comment

Choose a reason for hiding this comment

caesarxuchao commented Sep 15, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

janetkuo Sep 15, 2016 • edited Loading

Choose a reason for hiding this comment

kubectl rolling-update

Choose a reason for hiding this comment

caesarxuchao commented Sep 16, 2016

Choose a reason for hiding this comment

lavalamp commented Sep 16, 2016

lavalamp commented Sep 16, 2016

k8s-github-robot commented Sep 16, 2016

k8s-bot commented Sep 16, 2016

k8s-github-robot commented Sep 16, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lavalamp commented Sep 16, 2016

@gmarek commented on this pull request.

lavalamp commented Sep 16, 2016

@gmarek commented on this pull request.

lavalamp commented Sep 16, 2016

@gmarek commented on this pull request.

k8s-cherrypick-bot commented Sep 17, 2016

caesarxuchao commented Sep 15, 2016 •

edited

Loading

janetkuo Sep 15, 2016 •

edited

Loading