Persistent build metadata about spec HOT 9 CLOSED

Shouldn’t this just be a launch layer with a .profile.d that sets the value?

from spec.

There's a couple problems with that: the launch layer won't be available to subsequent builds (right?) and even so a bash script won't be parseable. I'm talking about this on behalf of others who need it (I don't actually need it myself) so I'm not the best one to go into detail. I'll let @hone bring it up at a sync.

from spec.

To me it seems like:

1. If it needs to be available at launch every time, persistently, then it should be set in <launch>/<layer>/profile.d
2. If it needs to be available at build every time, persistently, then it should be written to <launch>/<layer>.toml

from spec.

Ah so I was not planning on providing the launch layers from previous builds during a build (that's what the cache is for?). We should discussion.

from spec.

The launch layers are never available in subsequent builds — just the launch layer metadata TOML files.

from spec.

@hone and @jkutner Can you please write up your understanding and close out if your comfortable with our discussion?

from spec.

Given that the <launch>/<layer>.toml files are provided for subsequent builds (as described in Phase #2: Analysis), and assuming that a given a platform defines previous builds/OCI images as persistent, then I think <launch>/<layer>.toml satisfies the need for persistent metadata.

But is the <layer>.toml meant to be persistent? Would/should a new version of the lifecycle invalidate it? If so, that would be problematic for this use case. The spec is unclear i think, when it says "Was created using the lifecycle". (if we want to be unclear i think that's ok).

Related to this, the spec states "The lifecycle MUST NOT download any filesystem layers from the previous OCI image". I found this surprising given that I would expect to get the <launch>/<layer>.toml files from the previous image. Are we suggesting that the <launch>/<layer>.toml files are stored outside of the image?

from spec.

But is the .toml meant to be persistent? Would/should a new version of the lifecycle invalidate it? If so, that would be problematic for this use case. The spec is unclear i think, when it says "Was created using the lifecycle". (if we want to be unclear i think that's ok).

The intent was for it to be guaranteed. We could clarify the spec to specify that the platform must always restore the metadata on a rebuild of the same image unless the developer or operator explicitly indicates otherwise.

Related to this, the spec states "The lifecycle MUST NOT download any filesystem layers from the previous OCI image". I found this surprising given that I would expect to get the /.toml files from the previous image. Are we suggesting that the /.toml files are stored outside of the image?

The <launch>/<layer>.toml files are stored as JSON metadata on the config blob, which is a component of the OCI image that isn't a layer.

from spec.

Closing as this should be covered by #37 and #35. Feel free to re-open if I missed anything.

from spec.