List bundle dependencies #204
Comments
ashvinmoro
added
carvel triage
|
cc: @ncdc |
|
Thanks for creating this issue.
The CLI option can be added to the 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. |
DennisDenuto
added
triage/needs-more-information
priority/unprioritized-backlog
To keep the semantic separation a separate
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.
+1 |
|
Thanks @ashvinmoro I think given the specific use case for this feature, a new command to 'inspect' the bundle should be done. |
|
We've gotten information that this is a higher priority:
|
pivotaljohn
added
priority/important-soon
|
TODO:
|
|
Review #124 — which may be requesting the same functionality.
|
|
As @pivotaljohn mentioned we have discussed the creation of a |
|
@ashvinmoro any comments about the output of the |
|
@pivotaljohn @joaopapereira I went through the issue #124. There are a couple of aspects I had suggestions about
|
|
@ashvinmoro Take a look at the following example to see if they look good for your use case: ExamplesExample 1: Describe command without any argument Example 2: Describe command listing all images Example 3: Describe command listing all images in the current bundle without searching inner bundles Example 4: Describe command listing all images displaying the origin Example 5: Describe command listing all images when Bundle was not copied Previous examples but using a yaml outputExample 1: Describe command with yaml output Example 2: Describe command listing all images with yaml output Example 3: Describe command listing all images in the current bundle without searching inner bundles with yaml output Example 4: Describe command listing all images displaying the origin with yaml output |
|
Nice, but as mentioned before in other discussions, it'll be nice to somehow have the original image tags annotated so that describe can provide some information that a human can understand :-D |
|
In some sense, the original tag will be present if you use $ kbld -f basic-step-2/config.yml --imgpkg-lock-output basic-step-2/.imgpkg/images.yml
resolve | final: index.docker.io/dkalinin/k8s-simple-app:latest -> index.docker.io/dkalinin/k8s-simple-app@sha256:4c8b96d4fffdfae29258d94a22ae4ad1fe36139d47288b8960d9958d1e63a9d0
---
apiVersion: v1
kind: Service
metadata:
name: simple-app
namespace: default
spec:
ports:
- port: 80
targetPort: 80
selector:
simple-app: ""
---
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
kbld.k14s.io/images: |
- origins:
- resolved:
tag: latest
url: index.docker.io/dkalinin/k8s-simple-app:latest
url: index.docker.io/dkalinin/k8s-simple-app@sha256:4c8b96d4fffdfae29258d94a22ae4ad1fe36139d47288b8960d9958d1e63a9d0
name: simple-app
namespace: default
spec:
selector:
matchLabels:
simple-app: ""
template:
metadata:
labels:
simple-app: ""
spec:
containers:
- env:
- name: HELLO_MSG
value: stranger
image: index.docker.io/dkalinin/k8s-simple-app@sha256:4c8b96d4fffdfae29258d94a22ae4ad1fe36139d47288b8960d9958d1e63a9d0
name: simple-app
Succeeded
$ imgpkg push -b localhost:5000/test -f basic-step-2
dir: .
dir: .imgpkg
file: .imgpkg/bundle.yml
file: .imgpkg/images.yml
file: config.yml
Pushed 'localhost:5000/test@sha256:3cd8f0d917a92fafeef2d44eb63195d5351c35cf46b8b7448cb126c7d68c6291'
Succeeded
$ imgpkg describe -b localhost:5000/test@sha256:3cd8f0d917a92fafeef2d44eb63195d5351c35cf46b8b7448cb126c7d68c6291 -o yaml
sha: sha256:3cd8f0d917a92fafeef2d44eb63195d5351c35cf46b8b7448cb126c7d68c6291
content:
images:
sha256:4c8b96d4fffdfae29258d94a22ae4ad1fe36139d47288b8960d9958d1e63a9d0:
annotations:
kbld.carvel.dev/id: index.docker.io/dkalinin/k8s-simple-app:latest
kbld.carvel.dev/origins: |
- resolved:
tag: latest
url: index.docker.io/dkalinin/k8s-simple-app:latest
image: index.docker.io/dkalinin/k8s-simple-app@sha256:4c8b96d4fffdfae29258d94a22ae4ad1fe36139d47288b8960d9958d1e63a9d0
imageType: Image
origin: index.docker.io/dkalinin/k8s-simple-app@sha256:4c8b96d4fffdfae29258d94a22ae4ad1fe36139d47288b8960d9958d1e63a9d0
image: localhost:5000/test@sha256:3cd8f0d917a92fafeef2d44eb63195d5351c35cf46b8b7448cb126c7d68c6291
metadata: {}
origin: localhost:5000/test@sha256:3cd8f0d917a92fafeef2d44eb63195d5351c35cf46b8b7448cb126c7d68c6291
SucceededAnother thing we need to keep in mind is that |
|
Nice thanks for clarification. Is this also true for imgpkg copy, which is how most of the times images get to local clusters? |
|
Not following 100% what you mean, but the information we are displaying is the information that is part of the ImagesLock, so if the information is in the ImagesLock it will be displayed |
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-depsreturns images referenced after the images are locked
Images referenced in the ImagesLock of the bundle:index.docker.io/test/package-repo@sha256:b5e1cfb8731bf5ba6a0fb7060c37bbca03e9fb12be56dbec4a1fe2bbdfff2bd3index.docker.io/test/package-repo@sha256:42030f63b66e25a03c7d9ef28fa5369d230df5697b4ab2d94860e3f69026d18aAnything 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.
The text was updated successfully, but these errors were encountered: