-
Notifications
You must be signed in to change notification settings - Fork 543
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
config: Add a media type for the configuration format #611
Conversation
The reason this was not included from the start is because it breaks compatibility with Docker's config blobs (resulting in the manifest blobs referencing different blob IDs and so on). |
On Sat, Nov 05, 2016 at 09:56:04PM -0700, Aleksa Sarai wrote:
Having a media type does not mean you have to use it in place of the |
Ah, sorry I thought this PR was against |
How and when is this used for the runtime-spec. I'm confused why we need it here? |
@crosbymichael I think that @wking is implying that he would like to have Image configuration is more declarative, while runtime configuration is much more fine-grained and descriptive. Things being "open to interpretation" is a benefit here IMO because runtimes might have different opinions to the image author about how the image will be used. As for the actual issue of having a mediatype in |
On Tue, Nov 15, 2016 at 02:54:47AM -0800, Aleksa Sarai wrote:
This is one use case (covered in more detail in
I'm not suggesting a mediaType JSON property (like image-spec uses |
I see. like @cyphar said, this is a really bad idea and that is the reason these two are separate. The runtime holds host specific information and the right way to handle the runtime spec is that it is generated at runtime and destroyed along with the container. This spec should not be stored or used inside the image. |
On Wed, Nov 16, 2016 at 10:00AM -0800, Michael Crosby wrote:
This is presumably in response to opencontainers/image-spec#451. All this PR is doing is giving the configuration a media type. I don't see why that's a bad idea.
I'm not convinced, but rejecting opencontainers/image-spec#451 is a good way to say “the runtime spec should not be stored in the image”. Rejecting this PR, on the other hand, is saying “we don't want a machine-recognizable name this schema, because we think having such a name is a really bad idea”. I don't see why that would be the case. For example, it would be helpful to tell a validator “I'd like you to validate this |
@wking i think it would be nice to list out the cases where this is helpful/necessary, because "put these in image-spec CAS, or serve them over HTTP," is definitely what we dont want to do, which probably leads to the confusions here. |
On Wed, Nov 16, 2016 at 12:47:49PM -0800, Daniel, Dao Quang Minh wrote:
Necessary is too high a bar. Not having a canonical media type just ValidationWe briefly had a validator.opencontainers.org repository (e.g. see Flexible runtimesWith a runtime that supports multiple configurations, a media type $ flexibleRuntime --type application/vnd.oci.runtime.config.v1+json --config config.json create hello-1 Those are command-line examples, but you could also imagine a runtime $ curl -XPOST -H 'Content-Type: application/vnd.oci.runtime.config.v1+json; charset=utf-8' -d - https://container.example.com/create/hello-3 <config.json Emailing configurationsAsking for help: MIME-Version: 1.0 {
I'm still not convinced, but that discussion is part of |
@@ -2,6 +2,7 @@ | |||
|
|||
The container's top-level directory MUST contain a configuration file called `config.json`. | |||
The canonical schema is defined in this document, but there is a JSON Schema in [`schema/config-schema.json`](schema/config-schema.json) and Go bindings in [`specs-go/config.go`](specs-go/config.go). | |||
The media type for this file is configuration is `application/vnd.oci.runtime.config.v1+json`, and all specifications using that media type will require [JSON](glossary.md#json) objects with an [`ociVersion`](#specification-version). |
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.
The media type for this configuration file is [`application/vnd.oci.runtime.config.v1+json`](application/vnd.oci.runtime.config.v1+json)
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.
What are you suggesting? I don't think that Markdown link will resolve. Are you suggesting I drop the JSON and ociVersion
requirements for that media type? Do you expect those requirements to be overly restrictive? How do you expect consumers to process instances of this media type if we break either restriction?
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'm suggesting the text for this file is configuration is
includes a typo. And was hoping for a link to something that describes the media types. Should've looked it up, pretty sure I saw it somewhere around 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.
I'm suggesting the text for this file is configuration is includes a typo.
Ah, right. Fixed with 8696dfa → 32a192f, although I've gone with “format” instead of “file”.
And was hoping for a link to something that describes the media types. Should've looked it up, pretty sure I saw it somewhere around here :)
You may be thinking of this. I'm not aware of anything similar in this repo.
So we can put these in image-spec CAS, or serve them over HTTP, or whatever. Signed-off-by: W. Trevor King <wking@tremily.us>
8696dfa
to
32a192f
Compare
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.
Looks good to me.
@stevvooe PTAL |
@wking So, I don't see a problem with defining a media type here. We should actually make these declaration in a central location (currently the image spec). For runtime config, we should include a warning about the utility and dangers of distributing them. These might be two separate PRs. One to runtime repo with warning on distribution and one to image-spec registering the mediatype. @philips Does this sound reasonable? |
On Wed, Jan 11, 2017 at 02:40:19PM -0800, Stephen Day wrote:
We should actually make these declaration in a central location
(currently the image spec).
I think it's easier to make the fundamental claim in the spec that
declares the format. Having a central location that collects any
registered media types makes sense, but the IANA already does that [1]
(and registration for the vendor tree is optional [2]). If we want
our own OCI-wide collection of declared media types, I think that
should probably be the responsibility of whoever's maintaining
www.opencontainers.org (which may move back into a gh-pages site at
some point [3]).
For runtime config, we should include a warning about the utility
and dangers of distributing them.
I'm fine with this, but (as opencontainer/image-spec#451 shows ;), I
don't have a clear handle on the dangers. I'll leave that warning PR
for someone who does.
[1]: https://www.iana.org/assignments/media-types/media-types.xhtml
[2]: https://tools.ietf.org/html/rfc6838#section-3.2
[3]: opencontainers/web#20 (comment)
|
-1 because I don't what to have anything in this format that promotes transfer or distribution, which was the original reason for this PR. I don't think it belongs in the runtime-sepc |
Maybe change it to say that the runtime-spec does not include an image specification for distribution. Then provide a link to the OCI image specification as one possible future image distribution spec? Or should we just be silent to the other project here? |
“transfer or distribution” are hard to pin down. The validation and flexible runtime cases from this comment may be about transfer from one local process to another. Do we not want to facilitate those?
I'm fine with this. Maybe wording like:
or did you have something else in mind? |
the only value i see in this is having some kind of versioning of the docs being referenced. That could be handled by a dedicated field for document version. By giving these docs a media-type gives it encouragement to be distributed, which is not wanted. |
Many of the maintainers on both image and runtime are against this universally as this is not inline with the overall goals of the project and have security implications if encouraged to distribute the runtime configuration. If you want to store and distribute these then go ahead, but we don't want to add anything to encourage this. |
So we can put these in image-spec CAS, or serve them over HTTP, or whatever.