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

Allow XRs and XRCs to record when they last published connection details #227

Merged
merged 2 commits into from
Nov 5, 2020

Conversation

negz
Copy link
Member

@negz negz commented Nov 5, 2020

Description of your changes

See crossplane/crossplane#1927 for details.

I have:

  • Read and followed Crossplane's contribution process.
  • Run make reviewable test to ensure this PR is ready for review.

How has this code been tested

See crossplane/crossplane#1927 for testing details.

This information is useful both for debugging XRs and XRCs, and for controllers
to watch for updates to connection details (i.e. if those details were stored in
an external system rather than in Secrets, which can themselves be watched).

Signed-off-by: Nic Cope <negz@rk0n.org>
The claim controller in Crossplane core is the only place this machinery is
still used, so it will be migrated into that controller.

Signed-off-by: Nic Cope <negz@rk0n.org>
Copy link
Member

@muvaf muvaf left a comment

Choose a reason for hiding this comment

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

LGTM! I left a comment suggesting to have this as condition but I don't strongly think it's better either way.

v1alpha1.ConditionedStatus
ConnectionDetailsLastPublishedTimer
Copy link
Member

Choose a reason for hiding this comment

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

What do you think about having this as a Condition? I see that Equal check for condition doesn't include the last set time but maybe we can publish the time in the message. That could help keeping the schema simpler.

Copy link
Member Author

Choose a reason for hiding this comment

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

I considered that - it would be nice but I decided not to because we need a timestamp of some kind (or at least a state change) and working that into a condition felt tricky from a UX perspective. Today we set lastTransitionTime on our conditions, but that represents the last time we transitioned between condition statuses so it's not a good fit. API conventions mention that we could support lastHeartbeatTime which is a better fit (it's described as the "last time we got an update on a given condition"), but still a little less explicit. i.e.

status:
  connectionDetails:
    lastPublishedTime: T

Compared to:

status:
  conditions:
  - type: PublishedConnectionDetails
    status: True
    lastTransitionTime: T
    lastHeartbeatTime: T+N

In the condition example it's not super clear to the user (IMO) whether the "last heartbeat time" is the time the connection details were last published, or just the last time we assessed whether we had published connection details.

@negz negz merged commit 31eef9b into crossplane:master Nov 5, 2020
@negz negz deleted the intermediary branch November 5, 2020 08:51
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