To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@opencontainers.org.
Understandable. Rpm and debs have solved some this. And their verification (I.e. `rpm -qV ...`) are not terribly expensive. Tar archives are nice and awful, though working on tar-split, I've seen how it wouldnt be a big undertaking to have fileselt-like entries for speed validation. Though these are implementation approaches.
I don't think the features are so much "hard" as just step removed from where the focus is. There can be primitives leveraged that should enable this. It's just drawing out these base requirements for these OCI values.
I don't dislike IPFS, but that is a way of how to distribute bundles. And one that requires setup by clients and has its own discoverability integration.
To my point, were there some primitives that could allow a discoverable pointer to an IPFS distribution of images. It would then be up to you of bubbling up the cryptographic identity of a container, so it is discoverable, because despite the trust assumption in IPFS, others would need to validate this.
vb
I don't dislike IPFS, but that is a way of how to distribute bundles. And one that requires setup by clients and has its own discoverability integration.
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@opencontainers.org.
On Aug 30, 2015 6:45 PM, "Solomon Hykes" <solomo...@docker.com> wrote:
>
> Personally I think naming/trust/discovery is going to be really hard to specify in a way that makes everyone happy, and should remain out of scope. For example ipfs is designed to not depend on DNS for naming. If we specify that dns *must* be used, does that make ipfs non-compliant? As another example, Docker registries and the Docker image format do not map 1-1 to container bundles. They may carry additional, Docker-specific metadata and artifacts, and may for example bundke multiple containers in a single image. I'm guessing something similar could be done with the RPM format for example.
Correct that some packages have reinvented the wheel, but that wheel has similar characteristics.
The discussion of backwards-compat vs. "non-compliance" is definitely something to discuss.
Though, ipfs doesn't require dns, having something like the DNS TXT record, which is for attestible arbitrary pointers (see vspf mail entries) a publisher could have a pointer to their ipfs information, or Docker registry.
For docker additional metadata, I don't think that should rule out that the base bundle include OCI configuration.
> I would like to remind everyone that the task of this group is to define a portable runnable format - "the ELF of containers" which can be packaged and distributed in many ways. Our task is not to specify yet another packaging and distribution system. Naming and discovery are a packaging concern, and we should resist the temptation to choose the "one and true way". That would be a clear case of feature creep and would stretch us too thin. We have plenty of work left defining a solid executable format, let's focus on that!
The runtime is a thin piece that is heavy focused on, but true to the tenent values of the OCI charter it extends beyond just that elf runtime. If we don't have the semantics around supporting OCI roots and to enable further innovation with a common vocabulary, then relevance of a coomon format won't be broadly received. This isn't scope creep, it is following the charter.
As we are hoping to have a draft of the release out soon, if these thoughts are not considered, it may have negative impact later.
vb
On Aug 30, 2015 6:45 PM, "Solomon Hykes" <solomo...@docker.com> wrote:
>
> Personally I think naming/trust/discovery is going to be really hard to specify in a way that makes everyone happy, and should remain out of scope. For example ipfs is designed to not depend on DNS for naming. If we specify that dns *must* be used, does that make ipfs non-compliant? As another example, Docker registries and the Docker image format do not map 1-1 to container bundles. They may carry additional, Docker-specific metadata and artifacts, and may for example bundke multiple containers in a single image. I'm guessing something similar could be done with the RPM format for example.Correct that some packages have reinvented the wheel, but that wheel has similar characteristics.
The discussion of backwards-compat vs. "non-compliance" is definitely something to discuss.
Though, ipfs doesn't require dns, having something like the DNS TXT record, which is for attestible arbitrary pointers (see vspf mail entries) a publisher could have a pointer to their ipfs information, or Docker registry.
For docker additional metadata, I don't think that should rule out that the base bundle include OCI configuration.> I would like to remind everyone that the task of this group is to define a portable runnable format - "the ELF of containers" which can be packaged and distributed in many ways. Our task is not to specify yet another packaging and distribution system. Naming and discovery are a packaging concern, and we should resist the temptation to choose the "one and true way". That would be a clear case of feature creep and would stretch us too thin. We have plenty of work left defining a solid executable format, let's focus on that!
The runtime is a thin piece that is heavy focused on, but true to the tenent values of the OCI charter it extends beyond just that elf runtime.
If we don't have the semantics around supporting OCI roots and to enable further innovation with a common vocabulary, then relevance of a coomon format won't be broadly received.
This isn't scope creep, it is following the charter.
As we are hoping to have a draft of the release out soon, if these thoughts are not considered, it may have negative impact later.
To me, OCI spec looks very much like 'rpm'.
When the OCI was first announced I was most excited about moving the image format and distribution system forward. From my reading of the charter it seems to be clearly in scope.
Given that the image format, naming and distribution are all in scope it seems reasonable to start with a DNS based name.
On Sun, Aug 30, 2015 at 8:57 PM Joe Beda <j...@bedafamily.com> wrote:When the OCI was first announced I was most excited about moving the image format and distribution system forward. From my reading of the charter it seems to be clearly in scope.Yes, this is my understanding of reading the charter[1] too. From section 4.b.ii the TDC members are charged with "ensuring OCI Specifications incorporate and align to the OCI Values". And included in our values from section 6.d: "Decentralized. Discovery of container images should be simple and facilitate a federated namespace and distributed retrieval."
Given that the image format, naming and distribution are all in scope it seems reasonable to start with a DNS based name.Agreed, I would like to hear from more TDC members on their thoughts on adding a name to the bundle config.json, if there is a rough consensus I will put up the patch I posted earlier so we can continue discuss the finer points on GitHub.
It is by having declared language around this that we can facilitate
strongly federated naming, and get of of the way other's innovation
Taking another step back.
Are we all in agreement with 'A developer wanting to distribute an open container image for their application can build once, cryptographically sign once, and host in a human discoverable location a container image that can execute under any OCI runtime. ‘? Getting agreement there sounds like the first step.
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@opencontainers.org.
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@opencontainers.org.
On Mon, Aug 31, 2015 at 11:06:52AM -0700, Joe Beda wrote:
> - IPNS
> <https://github.com/ipfs/examples/tree/master/examples/ipns> --
> the base namespace for IPNS seems to be based on the hash of your
> public key. This can easily be translated into a DNS name with
> something like "<peer_id>.ipfs.io"
Is that going to be a special-case that all clients know about?
Otherwise what happens if the owners of iofs.io or the *.io DNS
registrar decide to serve something at https://<peer-id>.ipfs.io?
> An alternative would be to use a URN here for naming and allow different
> schemes.
>
> - urn:oci:ipfs:...
> - urn:oci:docker:...
> - urn:oci:deb:...
> - urn:oci:dns:foo.example.com:...
>
> Discovery methods and ease of use might be different depending on
> each of these.
This puts everyone on a more even footing (and avoids the DNS-or-not
confusion about something like <peer-id>.ipfs.io. But putting it
inside the bundle means you'd still need a new bundle if you wanted to
change a metadata location, and there would be no way to offer several
parallel locations [1,2].
Cheers,
Trevor
[1]: https://groups.google.com/a/opencontainers.org/d/msg/dev/OqnUp4jOacs/r_x7cmwVFgAJ
Message-ID: <20150831174...@odin.tremily.us>
[2]: https://github.com/philips/specs/commit/5ff2b14c0a2c59ca5538fa75e046516233b6cbc4#commitcomment-12981584
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@opencontainers.org.
can you elaborate on how and when this "name" field would be used?
For example, if I already have the config.json
downloaded would the runtime code ever need to use this URL at all?
If I'm downloading the config.json
then I clearly got the URL via some other mechanism since I can't get to 'name' w/o first downloading it.
If this is just a way to say "where this config.json/image came from",
then if I copy an image from someone else am I expected to crack it open
and modify this field (so it points to my copy) prior to using it?
I'm not against a 'name' field, but we need a clearer definition of its purpose in life.
w.r.t using URLs for a discovery mechanism, I totally agree with using a URL scheme but my gut is telling me that the URL needs to live outside of the image since you can't look inside it until you downloaded it.
Trying to return to the original question... do we need a name field in config.json, I’ll ask here what I asked on Brandon’s branch:
To unsubscribe from this group and stop receiving emails from it, send an email to dev+uns...@opencontainers.org.
What I'd *rather* do, is have a set of references for higher-level
specs, and just point to the things folks had already built: