Skip to content
This repository has been archived by the owner on Jan 8, 2024. It is now read-only.

plugin/k8s: Add StatusFunc to Deploy and Release #1547

Merged
merged 9 commits into from
May 27, 2021

Conversation

briancain
Copy link
Member

This pull request introduces a status report forwarder for the k8s platform. It inspects the deployed Pods and its containers to determine the overall health of a deployment or release.

Relies on hashicorp/waypoint-plugin-sdk#32

This commit implements reporting on a deploy status, and leaves the
release implementation to a future commit. Some refactoring needs to be
put in place to reduce code duplication across the Platform and Releaser
components. This will be handled in the next commit
This commit moves some of the basic status report building funcs into a
utils file so that they can be used by both the Platform and Releaser
status funcs
@briancain briancain added the pr/no-changelog No automatic changelog entry required for this pull request label May 26, 2021
@briancain briancain added this to the 0.4.0 milestone May 26, 2021
@briancain briancain requested a review from a team May 26, 2021 22:41
@briancain briancain changed the title builtin/k8s: Add StatusFunc to Deploy and Release plugin/k8s: Add StatusFunc to Deploy and Release May 26, 2021
Copy link
Contributor

@evanphx evanphx left a comment

Choose a reason for hiding this comment

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

This looks good but I wonder if we might have a more release-oriented status in the future. Atm because a release uses a deployment, we're showing the same status twice. Not an issue for now, but we should dig into K8 more and figure out if there is some release/service specific status we could be showing.

@briancain
Copy link
Member Author

briancain commented May 26, 2021

@evanphx Agreed...was thinking the same thing after finishing this up! I thought about reporting on the Service itself that we release to, but it doesn't look like there's much the k8s api tells us about it compared to the pods themselves.

Copy link
Contributor

@krantzinator krantzinator left a comment

Choose a reason for hiding this comment

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

🎉

builtin/k8s/status_report_util.go Outdated Show resolved Hide resolved
builtin/k8s/status_report_util.go Show resolved Hide resolved
Copy link
Contributor

@mitchellh mitchellh 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, one easy comment.

builtin/k8s/platform.go Outdated Show resolved Hide resolved
builtin/k8s/releaser.go Show resolved Hide resolved
This commit adds some extra checks on the Pods condition when its phase
is running to give us some extra detail about if the pod is actually
ready, or just running and alive
@briancain briancain merged commit ad2b9b8 into main May 27, 2021
@briancain briancain deleted the feature/k8s/report-on-status branch May 27, 2021 17:44
result.Health = sdk.StatusReport_ALIVE
result.HealthMessage = "all pods are reporting alive"
} else {
result.Health = sdk.StatusReport_PARTIAL
Copy link
Contributor

Choose a reason for hiding this comment

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

Question here: "PARTIAL" implies to me "Partially Ready". With this logic, if 4/5 are down and 1/5 is unknown, we'll get PARTIAL.

Just double-checking that we really want PARTIAL to mean any non-homogeneous set of underlying statuses.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah, also just found this in the RFC: PARTIAL = 4; // Some resources in deployment are OK, others are not OK

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
plugin/k8s plugin pr/no-changelog No automatic changelog entry required for this pull request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants