Skip to content

Comments

Upstream: <880>: openshift: Record machine sync error event#24

Merged
openshift-merge-robot merged 1 commit intoopenshift:openshift-4.0-cluster-api-0.0.0-alpha.4from
vikaschoudhary16:syncerrms-4.0
Apr 10, 2019
Merged

Upstream: <880>: openshift: Record machine sync error event#24
openshift-merge-robot merged 1 commit intoopenshift:openshift-4.0-cluster-api-0.0.0-alpha.4from
vikaschoudhary16:syncerrms-4.0

Conversation

@vikaschoudhary16
Copy link

What this PR does / why we need it:

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:

Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.

Release note:


@openshift-ci-robot openshift-ci-robot added the size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. label Apr 8, 2019
return reconcile.Result{}, errors.Wrap(err, "failed to update machine set status")
}

if syncErr != nil {
Copy link

Choose a reason for hiding this comment

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

Why do we only handle this after the updateMachineSetStatus bit? Are those always tied together this way? If so, should that just be a part of syncReplicas?

Copy link
Author

Choose a reason for hiding this comment

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

MachinesetStatus and events are two mechanisms through which user can get to know about current state. Even if syncReplicas is facing error, i thought it would help if we let the stats updated in the machinesetstatus.

Choose a reason for hiding this comment

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

From a purely pattern perspective, why do we not check for a syncErr straight after we call:

syncErr := r.syncReplicas(machineSet, filteredMachines)

Choose a reason for hiding this comment

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

If calling syncReplicas can fail why do we not fail fast when this is true?

Copy link
Author

Choose a reason for hiding this comment

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

Copy link

Choose a reason for hiding this comment

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

Discussed this offline. I think it might make sense to just move the updateMachineSetStatus call to syncReplicas if we always want to update the status while syncing. Not a big deal though, and this merged as-is upstream, so LGTM.

Choose a reason for hiding this comment

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

kubernetes-sigs#880 (comment)

In which case I would say add those exact words as to why we delay checking for success/failure on this call.

Copy link
Author

Choose a reason for hiding this comment

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

so that machineset status status could get updated and along with error message in the events, user could have latest stats.

@enxebre
Copy link
Member

enxebre commented Apr 10, 2019

@vikaschoudhary16 commit message still looks broken could you please update?

@vikaschoudhary16 vikaschoudhary16 force-pushed the syncerrms-4.0 branch 2 times, most recently from b2e1142 to 2f510ca Compare April 10, 2019 11:42
Copy link

@bison bison left a comment

Choose a reason for hiding this comment

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

/lgtm

return reconcile.Result{}, errors.Wrap(err, "failed to update machine set status")
}

if syncErr != nil {
Copy link

Choose a reason for hiding this comment

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

Discussed this offline. I think it might make sense to just move the updateMachineSetStatus call to syncReplicas if we always want to update the status while syncing. Not a big deal though, and this merged as-is upstream, so LGTM.

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Apr 10, 2019
@enxebre
Copy link
Member

enxebre commented Apr 10, 2019

/approve

@openshift-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: enxebre

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

The pull request process is described here

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Apr 10, 2019
@openshift-merge-robot openshift-merge-robot merged commit 34fb0d0 into openshift:openshift-4.0-cluster-api-0.0.0-alpha.4 Apr 10, 2019
@vikaschoudhary16 vikaschoudhary16 deleted the syncerrms-4.0 branch April 10, 2019 13:21
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. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants