Add RFC for Stack metadata #78
Conversation
Signed-off-by: Kashyap Vedurmudi <kvedurmudi@pivotal.io>
|
I assume this metadata is optional? |
| `io.buildpacks.stack.release`: Release Number | ||
| `io.buildpacks.stack.release_date`: Release date of image | ||
| `io.buildpacks.stack.description`: Description | ||
|
|
There was a problem hiding this comment.
Could we add a generic metadata field that is defined by the stack author?
E.g., io.buildpacks.stack.metadata could be defined by another out-of-spec RFC when the stack ID is io.buildpacks.stacks.bionic.
There was a problem hiding this comment.
Yeah that makes sense. I think that we should keep the other labels I proposed since we already use this pattern for the stack.id and stack.mixins and add this generic metadata label. How does that sound?
There was a problem hiding this comment.
Agreed on this. I quite like the pattern of top-level keys being wholly reserved for the spec (i.e. io.buildpacks.stack.*) and having a key that is wholly reserved for users that the spec will never use (io.buildpacks.stack.metadata). Top-level keys as they are described here look good.
There was a problem hiding this comment.
E.g.,
io.buildpacks.stack.metadatacould be defined by another out-of-spec RFC when the stack ID is io.buildpacks.stacks.bionic.
@sclevine can you elaborate on what you hope to have in there?
There was a problem hiding this comment.
I quite like the pattern of top-level keys being wholly reserved for the spec (i.e. io.buildpacks.stack.*) and having a key that is wholly reserved for users that the spec will never use (io.buildpacks.stack.metadata).
While I agree in theory, we currently use a lot of io.buildpacks.*.metadata for our own purposes, rather than reserving them for users. (e.g io.buildpacks.{lifecycle,build,builder}.metadata)
There was a problem hiding this comment.
@ekcasey Well that's a kick in the shorts. We can pick another key (.user) that represents the same thing, but alas is a naming inconsistency. My priority stack is as follows:
- Designated area for all users data that we both agree to never spec inside of and that a user will never create outside of
- Naming consistency
Even if that means we have some exceptions (e.g. io.buildpacks{lifecycle,build,builder}.metadata), I don't think we should introduce new inconsistencies.
There was a problem hiding this comment.
@kvedurmu I don't think this one has been addressed yet.
There was a problem hiding this comment.
@nebhale oops just updated it.
|
Signed-off-by: Kashyap Vedurmudi <kvedurmudi@pivotal.io>
| `io.buildpacks.stack.release`: Release Number | ||
| `io.buildpacks.stack.release_date`: Release date of image | ||
| `io.buildpacks.stack.description`: Description | ||
|
|
There was a problem hiding this comment.
Agreed on this. I quite like the pattern of top-level keys being wholly reserved for the spec (i.e. io.buildpacks.stack.*) and having a key that is wholly reserved for users that the spec will never use (io.buildpacks.stack.metadata). Top-level keys as they are described here look good.
|
@kvedurmu We'd like to get this moving again, can you please address the comments with new content? |
nebhale
requested review from
hone,
sclevine,
matthewmcnew,
ekcasey,
a team and
nebhale
Signed-off-by: Kashyap Vedurmudi <kvedurmudi@pivotal.io>
| # Drawbacks | ||
| [drawbacks]: #drawbacks | ||
|
|
||
| This could make image rebasing slightly more complicated as labels like stack version will need to be updated. |
There was a problem hiding this comment.
How would rebase work with this RFC?
There was a problem hiding this comment.
I believe the io.buildpacks.stack.* labels would need to be updated on the app image.
There was a problem hiding this comment.
That sounds good to me. Can get how this works into the RFC itself?
|
I'm overall 👍 this RFC, but would like to see the rebase case addressed that was listed. |
|
We'll need to fix the DCO on my suggested commit. :( |
|
Final Comment Period with merge disposition, closing on 22 July, 2020. |
|
@kvedurmu Please do a rebase where you sign off on all the commits. |
Co-authored-by: Terence Lee <hone02@gmail.com> Signed-off-by: Kashyap Vedurmudi <kvedurmudi@pivotal.io>
Readable