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

Update watchPods() behavior for Patroni role change #3807

Merged
merged 1 commit into from
Dec 19, 2023

Conversation

tjmoore4
Copy link
Contributor

Checklist:

  • Have you added an explanation of what your changes do and why you'd like them to be included?
  • Have you updated or added documentation for the change, as applicable?
  • Have you tested your changes on all related environments with successful results, as applicable?
    • Have you added automated tests?

Type of Changes:

  • New feature
  • Bug fix
  • Documentation
  • Testing enhancement
  • Other

What is the current behavior (link to any open issues here)?
In certain circumstances, another reconcile is needed after an instance role change, but there is nothing to trigger it.

What is the new behavior (if this is a feature change)?

  • Breaking change (fix or feature that would cause existing functionality to change)

This change adds an additional check to the existing watchPods function to queue an event when an instance Pod is first given the 'master' role.

Other Information:
Issue: PGO-190

Add an additional check to the existing watchPods function to
queue an event when an instance Pod is first given the 'master'
role.

Issue: PGO-190
Copy link
Member

@cbandy cbandy left a comment

Choose a reason for hiding this comment

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

LGTM

Comment on lines +194 to +197
// - https://github.com/zalando/patroni/blob/v3.1.1/patroni/ha.py#L296
// - https://github.com/zalando/patroni/blob/v3.1.1/patroni/ha.py#L583
// - https://github.com/zalando/patroni/blob/v3.1.1/patroni/ha.py#L782
// - https://github.com/zalando/patroni/blob/v3.1.1/patroni/ha.py#L1574
Copy link
Member

Choose a reason for hiding this comment

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

👍🏻 Great to see the moments when/why this happens.

Comment on lines +63 to +65
if len(cluster) != 0 &&
!patroni.PodIsPrimary(e.ObjectOld) &&
patroni.PodIsPrimary(e.ObjectNew) {
Copy link
Member

Choose a reason for hiding this comment

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

🌱 I suspect that this also covers the case on L39. Something likely transitions to primary when "may have come out of standby."

I've observed stuff like this in the past using something like:

kubectl get pod --watch --output=json --output-watch-events | jq --unbuffered '
  { _ts: now, type } +
  (.object.metadata | { name, creationTimestamp }) +
  { status: (.object.metadata.annotations.status // "{}" | fromjson) }
'

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good note. I think it may be useful to look at our watches holistically in the future, but for now I'll plan to leave both in place. I will mention that my testing showed the reconcile behavior remains similar with this change compared to the existing code.

@tjmoore4 tjmoore4 merged commit a557bf2 into master Dec 19, 2023
12 checks passed
@tjmoore4 tjmoore4 deleted the update-watch-pod branch December 19, 2023 18:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants