@technosophos Actually, I see image relocation as a responsibility of an invocation image rather than something runtimes need to be concerned about. (From that perspective, the refs section isn't needed in the spec.)

To this point in time, we've assumed the following:

• Invocation images are never responsible for image management (partly because they may not even know the image type (eg. VM, OCI, MSIX, etc)
• Information about an image location must be injected into the bundle from outside

That raised the problem that we're trying to solve here. An example goes like this:

I have a bundle that contains a Kubernetes manifest. That manifest points to example.com/foo/bar:v1, but I just exported the image and imported it into an isolated network. The new image was loaded to inner-network.local/foo/bar:v1

The thing that knows about inner-network.local is the CNAB Runtime. The invocation image is blissfully unaware of whether it's on the public network or the inner network, and blissfully unaware of its network constraints. It will work just as well in the external public network as in the internal network.

BUT... when we moved the images, we now need to notify the invocation image that it needs to rewrite its Kubernetes manifest to point to the new inner-network.local/foo/bar:v1 location.

Now, you raise a really good point: If the invocation image knows its own internal file system layout (which it does), then the refs field is not particularly useful. The invocation image itself should have all the internal logic it needs. So I suppose we could just ax that part of the spec. What we would seem to need in this case is just a mapping of old image names to their new image names. /cc @simonferquel <-- is that what you had in mind in your earlier PR?

To this point in time, we've assumed the following:

• Invocation images are never responsible for image management (partly because they may not even know the image type (eg. VM, OCI, MSIX, etc)

I'd like to challenge this assumption.

I wonder if invocation images might actually be better able to support the image types in their bundles than a runtime, which would need a pretty complex extension mechanism to cope with arbitrary image types.

This would avoid the need for explicit support for image management in the spec or runtime.

We could reduce the complexity for bundle authors, by building management features for docker (and other types of) images into base invocation images and/or adding tooling features (such as porter mixins).

• Information about an image location must be injected into the bundle from outside

I'd also like to challenge this assumption.

In the use case of image relocation, it would be sufficient to pass a parameter describing the target registry. This would avoid the need for explicit support in the spec or runtime.

That raised the problem that we're trying to solve here. An example goes like this:

I have a bundle that contains a Kubernetes manifest. That manifest points to example.com/foo/bar:v1, but I just exported the image and imported it into an isolated network. The new image was loaded to inner-network.local/foo/bar:v1

The thing that knows about inner-network.local is the CNAB Runtime. The invocation image is blissfully unaware of whether it's on the public network or the inner network, and blissfully unaware of its network constraints. It will work just as well in the external public network as in the internal network.

BUT... when we moved the images, we now need to notify the invocation image that it needs to rewrite its Kubernetes manifest to point to the new inner-network.local/foo/bar:v1 location.

Now, you raise a really good point: If the invocation image knows its own internal file system layout (which it does), then the refs field is not particularly useful. The invocation image itself should have all the internal logic it needs. So I suppose we could just ax that part of the spec.

I agree we could ax that part of the spec.

I'd also like us to consider the option of images being provided to a bundle separately to the invocation image: this is the subject of #95.

What we would seem to need in this case is just a mapping of old image names to their new image names. /cc @simonferquel <-- is that what you had in mind in your earlier PR?

Of course, if we made invocation images responsible for image relocation and passed a target registry as a parameter, then the spec and runtime wouldn't need to provide a mapping.

[An aside: the more features we can omit from v1 of the specification, the easier it will be to finalise the specification and implement runtimes.

Additional spec features may turn out to be desirable as the community gains experience in building runtimes for v1, but I think that's a healthy way to discover spec requirements. Trying to nail down all the spec requirements in v1 is a tall order given that only a few runtimes are currently being developed.

In general, it would be much easier to add features to future spec versions than have to cope with features that later turned out to be unnecessary.]

To my understanding, refs "declarative" replacements were to be handled by the CNAB runtime, whereas invocation images may support an imperative approach (by consuming the injected image map)

That is, after creation of the container, but before starting it, the driver would apply the refs rules without requiring anything within the invocation image.

In my mind, the refs are completely ignored by the invocation image then.

@glyn you make some very good points there.

For now, I am going to focus on removing the refs section as part of this PR. Would you mind opening a new issue that specifically deals with adding whatever is necessary to make it the bundle's responsibility? We can then shift the related conversation to that thread and not lose track of it.

@glyn you make some very good points there.

For now, I am going to focus on removing the refs section as part of this PR.

Thanks!

Would you mind opening a new issue that specifically deals with adding whatever is necessary to make it the bundle's responsibility? We can then shift the related conversation to that thread and not lose track of it.

#122

I was slightly confused to see the expressionType of css-selector in this example for setting a chart value. Was this intentional? Or should it be pcre?

On that note, what would the behavior be if css-selector was used? If I understand the spec correctly, the invocation image would attempt the substitution and should produce an error if it can't be made?