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

feat: add pebble.CheckInfo.change_id field #1197

Merged
merged 4 commits into from
Apr 24, 2024

Conversation

benhoyt
Copy link
Collaborator

@benhoyt benhoyt commented Apr 24, 2024

This is new with health checks being implemented as changes and tasks (canonical/pebble#409).

Ops/charms will likely not use this new field. Even once we have the new change-updated event, that has a .get_change() method to get the change directly. But we're adding it to the Pebble client/types for completeness.

We shouldn't merge this before that Pebble PR is merged, just in case anything changes.

This is new with health checks being implemented as changes and tasks
(canonical/pebble#409). We shouldn't merge this
before that Pebble PR is merged, just in case anything changes.
@benhoyt benhoyt changed the title feat: add CheckInfo.change_id field feat: add pebble.CheckInfo.change_id field Apr 24, 2024
Copy link
Contributor

@tonyandrewmeyer tonyandrewmeyer left a comment

Choose a reason for hiding this comment

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

Looks good - just one small question (about the drive-by).

I'm not sure I totally understand the use-case for knowing the change ID in ops - is there one? Or is this more for the Python Pebble API and completeness?

)

def __repr__(self):
return ('CheckInfo('
f'name={self.name!r}, '
f'level={self.level!r}, '
f'level={self.level}, '
Copy link
Contributor

Choose a reason for hiding this comment

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

This seems like it's better if level is a CheckLevel and worse if it's a str. Maybe both should be explicitly handled?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

True. However, realistically this is always going to be a CheckLevel (UP or DOWN). I think I'll leave this as is for now, as explicitly handling both is messy. We can update them all if we want in a later PR. But right now we don't test repr() and don't guarantee that eval(repr(x)) works, so I think it's probably fine as is.

@benhoyt benhoyt merged commit be7f8ac into canonical:main Apr 24, 2024
24 checks passed
@benhoyt benhoyt deleted the health-checks-changes branch April 24, 2024 03:50
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.

3 participants