no-jira: collect OS Image Stream resource

[patrickdillon]

Adds collection of OS Image Stream resource.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: b406cd82-6f41-40b9-9350-c81481b965cb

📥 Commits

Reviewing files that changed from the base of the PR and between a174fdd and de725eb.

📒 Files selected for processing (1)

• collection-scripts/gather

---

Walkthrough

Added a new OS Image Stream resource group (osimagestreams.machineconfiguration.openshift.io) to the group_resources array in the cluster-wide inspection collection step. No control flow, error handling, or resource selection logic was modified.

Changes

Cohort / File(s)	Summary
Resource Configuration collection-scripts/gather	Added osimagestreams.machineconfiguration.openshift.io resource group to group_resources array for inclusion in cluster-wide oc adm inspect collection.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 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]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: patrickdillon
Once this PR has been reviewed and has the lgtm label, please assign sferich888 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:

• collection-scripts/OWNERS

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

[openshift-ci-robot]

@patrickdillon: This pull request explicitly references no jira issue.

Details

In response to this:

Adds collection of OS Image Stream resource.

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.

[patrickdillon]

/testwith openshift/installer/main/e2e-aws-ovn-rhel10-devpreview openshift/installer#10357

[openshift-ci]

@patrickdillon, testwith: could not generate prow job. ERROR:

create refs for PR: path alias: resolve config openshift/must-gather@: got unexpected http 400 status code from configresolver: branch query missing or incorrect

[openshift-ci]

@patrickdillon: all tests passed!

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.

[ingvagabund]

A single cluster scoped CR with few KBs at most?

[patrickdillon]

A single cluster scoped CR with few KBs at most?

Thanks for taking a look. Good question, I'm only familiar with the installer piece where we are laying down the manifest, which is indeed super simple.

# cat c/openshift/99_osimagestream.yaml

apiVersion: machineconfiguration.openshift.io/v1alpha1
kind: OSImageStream
metadata:
  name: cluster
spec:
  defaultStream: rhel-10

@pablintino does anything update the status or does this CR grow?

[pablintino]

@patrickdillon oh! I wasn't expecting someone taking care of this important side, must-gather, thanks for taking a look :)
So, yes, the MCO is the one that performs the actual discovery of the streams and populates the status at boot time and during the first run on each upgrade.

I had this in mind, but I was thinking adding the CR to this list https://github.com/openshift/machine-config-operator/blob/c564b220f27b907206273edaaa0ee9f037b796ff/install/0000_80_machine-config_06_clusteroperator.yaml#L16. Not sure which path is better. I didn't even tried because it's still TP and I wasn't sure what to expect from must-gather or relatedObjects for TP CRDs.

About the size, yes, it grows, but not much. This is an example: 1KB at most? the status is just a list of the stream images, and we have only 2 streams. In the future we will have more, but no more than ~5 I think.

[patrickdillon]

@patrickdillon oh! I wasn't expecting someone taking care of this important side, must-gather, thanks for taking a look :) So, yes, the MCO is the one that performs the actual discovery of the streams and populates the status at boot time and during the first run on each upgrade.

I had this in mind, but I was thinking adding the CR to this list https://github.com/openshift/machine-config-operator/blob/c564b220f27b907206273edaaa0ee9f037b796ff/install/0000_80_machine-config_06_clusteroperator.yaml#L16. Not sure which path is better. I didn't even tried because it's still TP and I wasn't sure what to expect from must-gather or relatedObjects for TP CRDs.

@pablintino yeah I was about to message you directly. This came up when I was trying to validate another PR. I figured I would open the PR because it looked super simple, and sometimes it's easier to just take care of things rather than discuss them.

On the other hand, looks can be deceiving and things are not simple. If this is on your radar, I'm happy to close/defer this until you are working on it.

I had this in mind, but I was thinking adding the CR to this list https://github.com/openshift/machine-config-operator/blob/c564b220f27b907206273edaaa0ee9f037b796ff/install/0000_80_machine-config_06_clusteroperator.yaml#L16. Not sure which path is better.

I wasn't even aware of this, and so perhaps it makes more sense for an MCO developer to look there. :D

[pablintino]

@patrickdillon no worries, thanks for the taking care of it. I'm gonna ask @djoshy about how relatedObjects work. If that works for CRDs that are not deployed (ie a non-TP cluster that doesn't have the CRD) I'd maybe lean towards the relatedObjects approach just to be be consistent and list in the same place all the CRDs we are interested in.

[pablintino]

@patrickdillon I has a quick chat with the team and I think I miss-understood the purpose of related objects. When we have added CRDs to must-gather we did this #487 so I think your approach should be good.
If @ingvagabund is fine I'm all good too.

[ingvagabund]

No objection here. It's mainly up to you what you need to collect. It's just important to keep in mind how much extra data will get collected, whether this is going to be collected by default and whether you are excluding user created objects.