List bundle dependencies

[ashvinmoro]

Describe the problem/challenge you have
List dependencies:
An imgpkg bundle can either be a standalone bundle or a package repository, with them referencing dependent artifacts which can either be OCI artifacts or other imgpkg bundles. The imgpkg CLI today does not provide an option to query a bundle to list all dependent artifacts (regardless of the level of nesting) without doing a pull and parsing through the contents of the bundle.

This requires knowing the internals of the imgpkg bundle layout which is an implementation detail and causes too tight a coupling for clients consuming the CLI.

This feature is very helpful to inspect contents of the bundle metadata without requiring to download it, similar to how artifact manifest can be inspected using the crane command.

Describe the solution you'd like
Provide a CLI option and an API to allow clients consuming the bundles to query for all dependent artifacts and their types (bundle, repo, image) with their references locked to the relocated repository, similar to how “imgpkg pull” would fix the images lock.

Example:
imgpkg -b <bundle-ref> --list-deps
returns images referenced after the images are locked
Images referenced in the ImagesLock of the bundle:
index.docker.io/test/package-repo@sha256:b5e1cfb8731bf5ba6a0fb7060c37bbca03e9fb12be56dbec4a1fe2bbdfff2bd3
index.docker.io/test/package-repo@sha256:42030f63b66e25a03c7d9ef28fa5369d230df5697b4ab2d94860e3f69026d18a

Anything else you would like to add:
None

---

Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

[ashvinmoro]

cc: @ncdc

[DennisDenuto]

Thanks for creating this issue.

Provide a CLI option and an API... to query for... types

The CLI option can be added to the pull command. If this flag is present, the last section of output can be a flat list of all the dependent images that were pulled (also whether the dependent image is a bundle or an OCI image) Assuming we display whether the dependent image is a bundle or OCI image, would you still expect an API to 'query' the type?

Are you able to expand on the use case driving this request? or, why do you want a full list of dependent images per bundle?

I am trying to understand whether this is purely for information (which in that case the pull command outputting additional information seems like a fine idea), or whether this is being used to maybe verify / validate something?

In which case, I think discussing a new command to 'inspect' a bundle, and output pertinent information such as dependencies, ImagesLocation, signatures and tags might be useful. As well as any additional options such as filtering too.

[ashvinmoro]

The CLI option can be added to the pull command. If this flag is present, the last section of output can be a flat list of all the dependent images that were pulled (also whether the dependent image is a bundle or an OCI image) Assuming we display whether the dependent image is a bundle or OCI image, would you still expect an API to 'query' the type?

To keep the semantic separation a separate query command is better. Under the hood, this command may likely do a pull command but that will then be an implementation detail.

Are you able to expand on the use case driving this request? or, why do you want a full list of dependent images per bundle?

I am trying to understand whether this is purely for information (which in that case the pull command outputting additional information seems like a fine idea), or whether this is being used to maybe verify / validate something?

The use case is to track the dependent images and establish policy based access controls for users downloading the bundles and its images. Right now we are having to unpack the bundle and identify the dependents manually which is too dependent on the bundle implementation.

In which case, I think discussing a new command to 'inspect' a bundle, and output pertinent information such as dependencies, ImagesLocation, signatures and tags might be useful. As well as any additional options such as filtering too.

+1

[DennisDenuto]

Thanks @ashvinmoro

I think given the specific use case for this feature, a new command to 'inspect' the bundle should be done.

[pivotaljohn]

We've gotten information that this is a higher priority:

• there was an assumption that this could achieved through inspecting images.yml by pull recursive. However, we get an incomplete set of images; that approach is not viable.

[DennisDenuto]

TODO:
Prior to picking this up / working on this

• detail what the command options/flags will be, and the format of the output and get 'early' feedback from @ashvinmoro

[pivotaljohn]

Review #124 — which may be requesting the same functionality.

• note the sample output: Create a describe command for a bundle #124 (comment)
• that other story was describing this feature, in general. What context from this story can help us prioritize what aspects of this feature to implement now (and what we might want to defer).