-
Notifications
You must be signed in to change notification settings - Fork 99
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How are images stored in thick bundles and made available to invocation images? #95
Comments
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. |
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?
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:
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. |
@technosophos Given that #117 acknowledges the idea of image relocation, what's your take on this issue? |
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. |
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. |
A dictated location for the innvocation image would line up with my interpretation as well as expectations 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. One thought would be, is this a series of 2 CNABs
Or would those be 2 actions in the same invocation image. Or squashed into 1 action that runs both those steps. |
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 |
@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 |
@ryanmoran @glyn take a look at how Duffle does import/export. @michelleN is the author of that system. |
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. |
Thanks @technosophos. I see that |
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). |
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 theartifacts
directory at a defined location, such as/cnab/app/artifacts
, for invocation image(s) to access.The text was updated successfully, but these errors were encountered: