Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
OCI layout documentation #574
OCI layout documentation #574
Changes from 6 commits
9e63ee3
24038b9
0b0121a
3a9c147
56c077a
95e7f83
e596648
c944b90
6a3cf81
8292b0e
550a987
20b2378
d0c772d
22e144f
db5efd4
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we need a table somewhere comparing the
cnb
layout with theoci
layout. The first question I'd ask as a user is "Which layout should I choose?", and such a table would contain enough "Why?" to answer which layout to choose.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does
pack config experimental true
add the "layout-repo-dir" toconfig.toml
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that's correct
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need
layout-repo-dir
if the OCI layout is saved to the PWD?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are using the
layout-repo-dir
to save therun-image
on disk because actually invoking the lifecycle. When lifecycle is configured to use OCI layout it is expecting to have all the require inputs (like the run-image) on disk, because that should be transparent for users, we are saving those images in that particular folder.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There a number of tools here that we might need to explain to end-users. I think we're using
umoci
because it is a strict-OCI compliant tool? That assembles an image. I presume that docker can also execute a strict-OCI image? If so, should we prefer to not introduce a new runtime there?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I had some doubts about including those tool, maybe we can suppose users know what they can do with the OCI layout format
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here it becomes more unclear why
layout-repo-dir
was necessary above.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do these things pass/fail due to the state of our current implementation? Or because of a limitation in
crane
, or because the operation violates part of the OCI spec? Or for some other reason?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree, helpful to add a little more detail here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It fails because of the state or our current implementation, it should be improve on new versions of the feature. I will add it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me explain this part a little better so you can guide me on how to document it.
According to the RFC if you want to export your application image on disk, you need to mount to the lifecycle a local storage with the images require by the build process, for example, the
run-image
. This storage must contain images in OCI layout format and name resolution will follow some rules defined also in the RFC.The documented part was based on a feedback provided by @natalieparellano here, which is basically the following scenario: Suppose you want to execute the lifecycle directly without using pack, for example, a platform implementor. They need to create this local storage and save everything there before executing the build, right?, well the problem is: If they save in the local storage a manifest list and then they execute the lifecycle, right now, we are not smart enough to detect which manifest we need to pick to execute the build.
That is the actual comment we want to document so users can take it into consideration, now I am not sure this is the right place to do it, or maybe I didn't write it correctly, so any advice will be appreciate!