How are images stored in thick bundles and made available to invocation images?

[glyn]

The spec doesn't currently define how binary images are stored in a thick bundle. For example, It would be good to allow images to be stored as single files (e.g. .tar), for simplicity, or as a graph of layers, to optimise bundle size.

duffle seems to create an artifacts directory and corresponding JSON file in a thick bundle, but the spec doesn't mention either of these or how they might be made available to the invocation image(s).

Perhaps the simplest sufficient spec would be to allow arbitrary files and directories inside an optional artifacts directory in the root directory of a bundle and to mount the artifacts directory at a defined location, such as /cnab/app/artifacts, for invocation image(s) to access.

[technosophos]

I am not sure it was ever intended that the invocation image would have direct access to the images. We should figure out if that is something we want to do. But the previous assumption had been that the image driver(s) would be responsible for unmarshaling the exported archive and placing the files at defined locations.

At issue is whether the invocation image can and should know where the proper destination for images (of whatever form) should be. e.g. should it know which service account a VM image should be loaded to, or which registry a Docker image should be sent to?

But as far as the thick bundle on-disk format goes, yes, we do need to update that section to explain the internal structure of the thick bundle. And with In-Toto support coming, we need to make it flexible enough to contain chains and links.

[glyn]

I am not sure it was ever intended that the invocation image would have direct access to the images. We should figure out if that is something we want to do. But the previous assumption had been that the image driver(s) would be responsible for unmarshaling the exported archive and placing the files at defined locations.

I guess it depends on whether the set of valid image types is going to be part of the spec, in which case runtimes could implement support for all image types. But if the intention is to allow arbitrary image types, then there is a "chicken and egg" situation if an invocation image has a custom image type: how would a CNAB runtime which doesn't support that image type be able to install the bundle?

You mention the term image driver, but searching through the spec, this term looks like it may have been superseded in which case remaining usages of it may need replacing. Is the plan to remove image drivers from the spec or to flesh them out?

At issue is whether the invocation image can and should know where the proper destination for images (of whatever form) should be. e.g. should it know which service account a VM image should be loaded to, or which registry a Docker image should be sent to?

It would seem reasonable to define such "destinations" using parameters or credentials. Maybe a concrete use case where the invocation image needs to know the destination for images would help. The Pivotal Function Service (PFS; based on riff/knative/kubernetes) is shipped as an archive (analogous to a thick bundle) containing:

• docker images which need to be pushed to a registry of the user's choosing
• kubernetes configuration files which need "relocating" (so that image names refer to the user's registry) and then installing.

If PFS was to use CNAB, the invocation image would need to know the user's registry in order to relocate the kubernetes configuration files before installing them.

Whether the invocation image would also be responsible for pushing the images to the user's registry is a good question. Not being aware of options in the spec, I was assuming so.

[glyn]

@technosophos Given that #117 acknowledges the idea of image relocation, what's your take on this issue?

[ryanmoran]

As a runtime implementor, I still have concerns with the current specification for thick bundles. It is unclear what a runtime is supposed to do with the images that are included with the thick bundle.

Is a runtime responsible for the relocation of these bundled images into a location that can be addressed by the run tool? If so, I think we still have the issue that @glyn outlines, that bundles are limited by what "registries" a runtime supports.

To add some more color to @glyn's use-case above, it is entirely possible that the registry that the user might configure to push PFS images to wouldn't be the only registry in use by our customers. We have use-cases where a customer might want some images from a special bundle pushed to a specific registry while they might want all other bundles to push to a common registry. If we had runtimes responsible for this, then we would need some way to indicate which registry is to be targeted on a per-bundle basis.

[glyn]

I think it may be simplest if the runtime simply mounted a directory containing the images/layers/other files so that the invocation image could do the rest. In particular, I don't want to tie the runtime to a particular representation of images in a thick bundle (that's something we've already seen change in PFS). If we make image relocation the responsibility of an invocation image, then the chosen representation would be an implementation detail of the bundle.

As for bundle-specific registries, these could be specified using a parameter with no impact on the specification or runtime.

[GreenCee]

A dictated location for the innvocation image would line up with my interpretation as well as expectations
In the case of a docker image the innvocation image would probably upload it to a select registry from a parameter and then pass that further along to customize things as needed (Adjust Helm Chart, K8s Deployment etc). I would not expect the runtime to need to know anything beyond the file location to source the thick images from.

Pulling my experience deploying things that feel like thick bundles, artifacts will be extracted then moved to the location it will actually be needed rather than exposing that as a share directly.
So that directory of binary files (Images, VHDs etc.) would be available to the invocation image locally, but would then rely on the invocation image to handle putting in the appropriate location (S3, Blob, Registry, Gallery etc.). Parameter of that location then gets passed.

One thought would be, is this a series of 2 CNABs

1. Extract - Input parameters of where to put artifacts
2. Deploy - Input parameters of where to pull artifacts

Or would those be 2 actions in the same invocation image. Or squashed into 1 action that runs both those steps.

[glyn]

Clearly one squashed action is sufficient for a one-off deployment. But it would be more natural to separate the relocate step from the install step if the same bundle were to be deployed across multiple clusters (or whatever) sharing a registry. Perhaps relocate could be a custom action which would be executed prior to install when relocation is required?

[jonjohnsonjr]

@glyn FWIW the OCI image-spec defines an on-disk format for a collection of artifacts, called an Image Layout: https://github.com/opencontainers/image-spec/blob/master/image-layout.md

[technosophos]

@ryanmoran @glyn take a look at how Duffle does import/export. @michelleN is the author of that system.

[glyn]

@glyn FWIW the OCI image-spec defines an on-disk format for a collection of artifacts, called an Image Layout: https://github.com/opencontainers/image-spec/blob/master/image-layout.md

That looks great. However, even though this is an OCI standard, I think it need not be a concern for CNAB. An OCI-aware base invocation image could process an OCI image layout providing the layout was made available to the invocation image.

[glyn]

@ryanmoran @glyn take a look at how Duffle does import/export. @michelleN is the author of that system.

Thanks @technosophos. I see that duffle export stores a bundle as a tar file including binary images. But what does duffle import do with those images? More importantly, what has duffle import/export got to do with the (present or future) spec? ;-) /cc @michelleN

[glyn]

Now that the spec defines how binary images are stored in thick bundles, this issue can be closed. Making binary images in a bundle available to the invocation image is no longer needed as pushing the images turns out not to be the responsibility of an invocation image (see the closed issue #122).