Introduce the gRPC-based UpgradeLog#67
Conversation
Signed-off-by: Zespre Chang <[email protected]>
Add a log collector/shipper architecture using gRPC and Protocol Buffers. Introduce the UpgradeLog CRD with a phase state machine and per-pod log tracking, a new pkg/upgradelog controller pipeline, CLI subcommands for the collector and shipper, and LogPreparing/LogPrepared phases in UpgradePlan. Signed-off-by: Zespre Chang <[email protected]>
…rsion Signed-off-by: Zespre Chang <[email protected]>
Replace the inline shell script in the log-viewer sidecar with a proper Go subcommand that recursively scans directories for .log files, tails each file, and prints lines to stdout prefixed with the relative path. Signed-off-by: Zespre Chang <[email protected]>
…ading deletion Signed-off-by: Zespre Chang <[email protected]>
…al phase Signed-off-by: Zespre Chang <[email protected]>
brandboat
left a comment
brandboat
left a comment
There was a problem hiding this comment.
Looks promising, the goal is to replace the rancher-logging in the upgrade flow, right?
| // Finalizer for UpgradeLog cleanup on deletion | ||
| UpgradeLogFinalizer = AnnotationPrefix + "/" + "upgradelog-cleanup" |
| upgradePlanLabel = "management.harvesterhci.io/upgrade-plan" | ||
| upgradeComponentLabel = "management.harvesterhci.io/upgrade-component" |
There was a problem hiding this comment.
nit: can be replaced with const in upgradelog/constants.go
| } | ||
|
|
||
| // Only mutate pods with the upgrade-plan label | ||
| upgradePlanName, hasLabel := pod.Labels[upgradePlanLabel] |
There was a problem hiding this comment.
It appears we are now only collecting logs from pods with the label management.harvesterhci.io/upgrade-plan. Is that correct?
In the v1 implementation, we collected logs from all pods within specific namespaces (as seen in common.go). This raises a deeper question: do we actually need to collect all logs from kube-system, cattle-system, and harvester-system during an upgrade? How useful is that data in practice?
There was a problem hiding this comment.
Thanks for the question. I remember that @bk201 raised the same concern. I am totally aware of that and figuring out some way to collect logs from those components. But it seems there is no easy way.
Note: This is still a draft PR. I opened this only for collecting early feedback. There will be an HEP for the whole plan.
There was a problem hiding this comment.
Yeah, I know this is still a draft, but I couldn’t stop myself from getting curious and digging into the proposal.
2 participants
Problem:
Solution:
Related Issue(s):
harvester/harvester#10464
Test plan:
Additional documentation or context