Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Always populate volume status from node #16384

Merged
merged 1 commit into from
Sep 16, 2017

Conversation

gnufied
Copy link
Member

@gnufied gnufied commented Sep 15, 2017

Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1481729

Actual Upstream PR - kubernetes/kubernetes#52221

But we think, we won't be able to get this in 1.8

@openshift-ci-robot openshift-ci-robot added the size/M Denotes a PR that changes 30-99 lines, ignoring generated files. label Sep 15, 2017
@gnufied
Copy link
Member Author

gnufied commented Sep 15, 2017

[test]

@@ -281,7 +281,7 @@ func (adc *attachDetachController) populateActualStateOfWorld() error {
glog.Errorf("Failed to mark the volume as attached: %v", err)
continue
}
adc.processVolumesInUse(nodeName, node.Status.VolumesInUse, true /* forceUnmount */)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use this to build openshift start kubernetes controller-manager which is supposed to be true to the upstream. Unconditional carries like this shouldn't be added and we are actively trying to remove the ones we have.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right I don't disagree, but we have hit bit of road block in merging this PR upstream.cc @eparis @childsb

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gnufied is not allowed to let 52221 miss for 1.9. But this must be carried in 3.7+ even if that doesn't happen. This is mission critical.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gnufied is not allowed to let 52221 miss for 1.9. But this must be carried in 3.7+ even if that doesn't happen. This is mission critical.

This is currently listed as a carry. As such, it will prevent convergence with upstream. If its related to an upstream pull, then it doesn't cause us to diverge forever and its a risk assessment, not a case of preventing any future reconciliation.

Is this just an upstream pick?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a pick, but if upstream fails to merge, it is a carry. you tell me :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a pick, but if upstream fails to merge, it is a carry. you tell me :)

Its a pick, reference the upstream number. If you don't, we'll never know that we either have to never converge onto upstream or find another way to handle it.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay I am happy rewording the commit. doesn't seem like a biggie.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright I have updated this PR to have upstream's PR ref. number.

@childsb
Copy link
Contributor

childsb commented Sep 15, 2017

This is for customer bug, upstream is reluctant to merge this late in the 1.8 release. This is approved and ready to hit 1.9 when code re-opens.

@eparis approved this for carry

Upstream here: kubernetes/kubernetes#52221

@childsb childsb changed the title UPSTREAM: <carry>: Always populate volume status from node Always populate volume status from node Sep 15, 2017
@childsb
Copy link
Contributor

childsb commented Sep 15, 2017

/test cmd

@eparis
Copy link
Member

eparis commented Sep 15, 2017

/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Sep 15, 2017
@openshift-merge-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: eparis, gnufied

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these OWNERS Files:

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

@openshift-merge-robot openshift-merge-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Sep 15, 2017
@eparis
Copy link
Member

eparis commented Sep 16, 2017

/retest

@openshift-merge-robot
Copy link
Contributor

/test all [submit-queue is verifying that this PR is safe to merge]

@openshift-ci-robot
Copy link

openshift-ci-robot commented Sep 16, 2017

@gnufied: The following test failed, say /retest to rerun them all:

Test name Commit Details Rerun command
ci/openshift-jenkins/cmd 263a57e link /test cmd

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@openshift-merge-robot
Copy link
Contributor

Automatic merge from submit-queue (batch tested with PRs 16384, 16327, 16199, 16286, 16378)

@openshift-merge-robot openshift-merge-robot merged commit 6edb23d into openshift:master Sep 16, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. queue/fix size/M Denotes a PR that changes 30-99 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants