Add SBOM generator for ModelCar OCI images

[Victoremepunto]

This adds a helper script to generate SBOM reports for ModelCar image.

A ModelCar is a containerized approach to deploying machine learning models. It involves packaging
model artifacts within a container image, enabling efficient and standardized deployment in
Kubernetes environments, used as Sidecar containers (secondary containers that run alongside the
main application container within the same Pod)

This is a helper script that is used in the ModelCar task introduced with konflux-ci/build-definitions#2038, to produce the necessary SBOM report.

[ralphbean]

/ok-to-test

[ralphbean]

modelcars aren't yet a well known thing. I can imagine someone coming across this script later outside the context of your usage with olot and saying "what!?".

Can you provide a brief docstring at the top of the script explaining what modelcars are and a link to more upstream information about them?

[ralphbean]

Also, please - a short paragraph explaining why the two arguments (model image and base image) are sufficient to faithfully create an SBOM of the modelcar.

[Victoremepunto]

Thanks for the review, I've added a docstring with the description

[tnevrlka]

I am a little wary of using links in the dosctrings. Links can die and I don't think it's necessary to link whole blog posts since those could be looked up by anyone interested enough anyway.
I imagine that a short paragraph describing it would work better instead of expecting someone to go through the links

[ralphbean]

@tnevrlka's opinion trumps mine here!

[Victoremepunto]

I have refactored the contents of the docstring to remove the links from it and to provide a succinct explanation of what a ModelCar is and what is the purpose of the script. The contents now match those of the help function output

[tnevrlka]

I have a similar concern as Ralph.
I believe it would be great to write a description and motivation behind the change into the commit message(s) and PR description.
I would also prefer to avoid references to Red Hat's internal Jira.
At this moment, I don't understand why this change is being proposed and would appreciate clarification. Thank you!

[tkdchen]

nitpick: you don't need to write such a long docstring. Instead, using the argparse API to set program description and arguments description, then, -h will print the whole description.

[Victoremepunto]

Thanks for the suggestion, it makes sense. I've accordingly updated the docstring to match the output of the help function, and refactored the former contents using the Argparse API as suggested.

[twaugh]

To represent that "aipcc/modelcar-image" descends from both "aipcc/base-image" and "aipcc/model-image", I wonder if the structure ought to be like:

"components": {
  {
    "type": "container",
    "name": "aipcc-modelcar-image",
    ...
    "components": [
        {
            "type": "container",
            "name": "aipcc/base-image",
            ...
        },
        {
            "type": "container",
            "name": "aipcc/model-image",
            ...
        }
    ]
}

[Victoremepunto]

I've updated the structure to accommodate the suggestion, please could you review it again?

[ralphbean]

/ok-to-test

[Victoremepunto]

I have a similar concern as Ralph. I believe it would be great to write a description and motivation behind the change into the commit message(s) and PR description. I would also prefer to avoid references to Red Hat's internal Jira. At this moment, I don't understand why this change is being proposed and would appreciate clarification. Thank you!

Thanks for the review.

I have updated the docstring following the review comments, to expand on the nature of the script and its context.

I have also updated title and description of the PR to remove any external references to internal JIRA projects, and to provide details about what this script is meant to used for and why is it required.

I hope this changes help clarifying the PR's motivation.

[tnevrlka]

/ok-to-test

[twaugh]

Minor: indentation looks off