Skip to content

MGMT-23802: Fix manifest format in log bundles#10121

Open
zaneb wants to merge 1 commit intoopenshift:masterfrom
zaneb:log-manifest-yaml-json
Open

MGMT-23802: Fix manifest format in log bundles#10121
zaneb wants to merge 1 commit intoopenshift:masterfrom
zaneb:log-manifest-yaml-json

Conversation

@zaneb
Copy link
Copy Markdown
Member

@zaneb zaneb commented Apr 8, 2026

Manifests included in cluster log bundles were being JSON-encoded as strings instead of preserving their original YAML format. This occurred because uploadDataAsFile() JSON-marshals all inputs, which is correct for cluster metadata and events but inappropriate for manifests that are already serialized YAML.

This change bypasses uploadDataAsFile() and directly uploads manifest content using objectHandler.Upload(), preserving the original YAML format in downloaded log bundles.

List all the issues related to this PR

  • New Feature
  • Enhancement
  • Bug fix
  • Tests
  • Documentation
  • CI/CD

What environments does this code impact?

  • Automation (CI, tools, etc)
  • Cloud
  • Operator Managed Deployments
  • None

How was this code tested?

  • assisted-test-infra environment
  • dev-scripts environment
  • Reviewer's test appreciated
  • Waiting for CI to do a full test run
  • Manual (Elaborate on how it was tested)
  • No tests needed

Checklist

  • Title and description added to both, commit and PR.
  • Relevant issues have been associated (see CONTRIBUTING guide)
  • This change does not require a documentation update (docstring, docs, README, etc)
  • Does this change include unit-tests (note that code changes require unit-tests)

Reviewers Checklist

  • Are the title and description (in both PR and commit) meaningful and clear?
  • Is there a bug required (and linked) for this change?
  • Should this PR be backported?

Manifests included in cluster log bundles were being JSON-encoded
as strings instead of preserving their original YAML format. This
occurred because uploadDataAsFile() JSON-marshals all inputs,
which is correct for cluster metadata and events but
inappropriate for manifests that are already serialized YAML.

This change bypasses uploadDataAsFile() and directly uploads
manifest content using objectHandler.Upload(), preserving the
original YAML format in downloaded log bundles.

Assisted-by: Claude Code
@openshift-ci-robot openshift-ci-robot added the jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. label Apr 8, 2026
@openshift-ci-robot
Copy link
Copy Markdown

openshift-ci-robot commented Apr 8, 2026

@zaneb: This pull request references MGMT-23802 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the bug to target the "4.22.0" version, but no target version was set.

Details

In response to this:

Manifests included in cluster log bundles were being JSON-encoded as strings instead of preserving their original YAML format. This occurred because uploadDataAsFile() JSON-marshals all inputs, which is correct for cluster metadata and events but inappropriate for manifests that are already serialized YAML.

This change bypasses uploadDataAsFile() and directly uploads manifest content using objectHandler.Upload(), preserving the original YAML format in downloaded log bundles.

List all the issues related to this PR

  • New Feature
  • Enhancement
  • Bug fix
  • Tests
  • Documentation
  • CI/CD

What environments does this code impact?

  • Automation (CI, tools, etc)
  • Cloud
  • Operator Managed Deployments
  • None

How was this code tested?

  • assisted-test-infra environment
  • dev-scripts environment
  • Reviewer's test appreciated
  • Waiting for CI to do a full test run
  • Manual (Elaborate on how it was tested)
  • No tests needed

Checklist

  • Title and description added to both, commit and PR.
  • Relevant issues have been associated (see CONTRIBUTING guide)
  • This change does not require a documentation update (docstring, docs, README, etc)
  • Does this change include unit-tests (note that code changes require unit-tests)

Reviewers Checklist

  • Are the title and description (in both PR and commit) meaningful and clear?
  • Is there a bug required (and linked) for this change?
  • Should this PR be backported?

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

@coderabbitai
Copy link
Copy Markdown

coderabbitai bot commented Apr 8, 2026

Walkthrough

The createClusterDataFiles function in the cluster management module now uploads manifest log contents directly via objectHandler.Upload() instead of using the manager's uploadDataAsFile helper method, which previously JSON-marshalled the data before uploading.

Changes

Cohort / File(s) Summary
Manifest upload handler change
internal/cluster/cluster.go
Modified manifest log file upload to use direct object handler instead of manager helper, changing payload encoding from JSON-marshalled to raw content.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

Comment @coderabbitai help to get the list of available commands and usage tips.

@openshift-ci openshift-ci bot added the size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. label Apr 8, 2026
@openshift-ci openshift-ci bot requested review from CrystalChun and avishayt April 8, 2026 04:48
@openshift-ci
Copy link
Copy Markdown

openshift-ci bot commented Apr 8, 2026

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: zaneb
Once this PR has been reviewed and has the lgtm label, please assign jhernand for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Copy link
Copy Markdown

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

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

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)
internal/cluster/cluster.go (1)

1365-1376: ⚠️ Potential issue | 🟠 Major

Close the downloaded manifest reader to prevent handle leaks.

Download returns an io.ReadCloser, but response is never closed in this loop. The reader leaks across all code paths: both when ReadAll fails (line 1373) and when it succeeds (before the next iteration). On clusters with many manifests, this exhausts available file/HTTP handles.

Suggested fix
-		fileContent, err := io.ReadAll(response)
+		fileContent, err := func() ([]byte, error) {
+			defer func() {
+				if closeErr := response.Close(); closeErr != nil {
+					log.WithError(closeErr).Warnf("failed to close file %s from cluster while building log: %s", path, *c.ID)
+				}
+			}()
+			return io.ReadAll(response)
+		}()
 		if err != nil {
 			log.WithError(err).Errorf("failed to read file data %s (%d) from cluster while building log: %s", path, numberOfBytes, *c.ID)
 			continue
 		}
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@internal/cluster/cluster.go` around lines 1365 - 1376, The Download call
(m.objectHandler.Download) returns an io.ReadCloser (response) which is never
closed; update the loop to close response on all paths by calling
response.Close() — e.g., after a successful non-nil response do defer
response.Close() immediately (or ensure explicit Close() in both the error
branch after io.ReadAll fails and after the successful Upload) so the reader is
released whether io.ReadAll fails or succeeds; keep references to response,
io.ReadAll, and objectHandler.Upload when adding the close to ensure no handle
leaks.
🧹 Nitpick comments (1)
internal/cluster/cluster.go (1)

1361-1376: Use the same storage handler for download and upload.

This block checks existence and uploads via objectHandler, but still downloads via m.objectHandler. If a caller passes a non-default handler, the copy path spans two backends.

Suggested fix
-		response, numberOfBytes, err := m.objectHandler.Download(ctx, objectName)
+		response, numberOfBytes, err := objectHandler.Download(ctx, objectName)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.

In `@internal/cluster/cluster.go` around lines 1361 - 1376, The code uses
objectHandler for DoesObjectExist and Upload but calls m.objectHandler.Download,
which can mix backends; change the download call to use the same handler
variable (objectHandler) so all operations (DoesObjectExist, Download, Upload)
use the provided handler; specifically replace the m.objectHandler.Download(...)
invocation with objectHandler.Download(...) and ensure any error
logging/variables (response, numberOfBytes, err) remain unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In `@internal/cluster/cluster.go`:
- Around line 1365-1376: The Download call (m.objectHandler.Download) returns an
io.ReadCloser (response) which is never closed; update the loop to close
response on all paths by calling response.Close() — e.g., after a successful
non-nil response do defer response.Close() immediately (or ensure explicit
Close() in both the error branch after io.ReadAll fails and after the successful
Upload) so the reader is released whether io.ReadAll fails or succeeds; keep
references to response, io.ReadAll, and objectHandler.Upload when adding the
close to ensure no handle leaks.

---

Nitpick comments:
In `@internal/cluster/cluster.go`:
- Around line 1361-1376: The code uses objectHandler for DoesObjectExist and
Upload but calls m.objectHandler.Download, which can mix backends; change the
download call to use the same handler variable (objectHandler) so all operations
(DoesObjectExist, Download, Upload) use the provided handler; specifically
replace the m.objectHandler.Download(...) invocation with
objectHandler.Download(...) and ensure any error logging/variables (response,
numberOfBytes, err) remain unchanged.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 62de1fc7-a457-41ad-855b-df4573d1a457

📥 Commits

Reviewing files that changed from the base of the PR and between c184c74 and 0556198.

📒 Files selected for processing (1)
  • internal/cluster/cluster.go

@codecov
Copy link
Copy Markdown

codecov bot commented Apr 8, 2026

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 44.25%. Comparing base (c184c74) to head (0556198).
⚠️ Report is 2 commits behind head on master.

Files with missing lines Patch % Lines
internal/cluster/cluster.go 0.00% 1 Missing ⚠️
Additional details and impacted files

Impacted file tree graph

@@           Coverage Diff           @@
##           master   #10121   +/-   ##
=======================================
  Coverage   44.24%   44.25%           
=======================================
  Files         415      415           
  Lines       72499    72499           
=======================================
+ Hits        32079    32083    +4     
+ Misses      37509    37507    -2     
+ Partials     2911     2909    -2     
Files with missing lines Coverage Δ
internal/cluster/cluster.go 66.35% <0.00%> (ø)

... and 3 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@openshift-ci
Copy link
Copy Markdown

openshift-ci bot commented Apr 8, 2026

@zaneb: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name Commit Details Required Rerun command
ci/prow/edge-e2e-ai-operator-ztp 0556198 link true /test edge-e2e-ai-operator-ztp

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

jira/valid-reference Indicates that this PR references a valid Jira ticket of any type. size/XS Denotes a PR that changes 0-9 lines, ignoring generated files.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants