3 ms·

I love lxc/lxd. Its really a shame that there is little to no interest by the lxd team in supporting the oci container format.

cyphar 7y ago
I assume you're referring to the OCI image format (not the runtime spec). This is because the OCI image format doesn't quite meet what they want for LXD -- in particular the whole layering design that OCI uses (which was inherited from Docker) is simply wrong for them. In fact there is a strong argument that the layering design doesn't even match what OCI really wants (it effectively embeds an optimisation for "docker build" into the storage format). I am actually working on improving the current state of OCI images[1] by using a snapshot-based tree structure -- which will also solve many problems we have in OCI that are independent from LXD. But it is possible that the LXD folks would be more interested if the OCI format more closely matched what they need. Though it should be noted that LXC has had an OCI template for several years now[2] (and it actually uses a tool I wrote -- umoci -- to extract the OCI image). [1]: https://www.youtube.com/watch?v=bbTxdzbjv7I https://www.youtube.com/watch?v=bbTxdzbjv7I [2]: https://github.com/lxc/lxc/blob/lxc-3.2.1/templates/lxc-oci.in https://github.com/lxc/lxc/blob/lxc-3.2.1/templates/lxc-oci....
- psanford 7y ago
  Yeah I am aware of the oci-template. I was mostly thinking of discussions like this[1] where Stéphane says there are no plans to support anything like that in LXD. I find the distinction between "system containers" and "application containers" to be a bit arbitrary from a technical perspective. What does it matter what I'm running as PID 1? I find both system containers and application containers to be useful. It seems like LXD would see larger adoption if it were easy to run docker container images directly (built into the LXD tooling). [1]: https://discuss.linuxcontainers.org/t/using-oci-templates-in-lxd/1911 https://discuss.linuxcontainers.org/t/using-oci-templates-in...

cyphar 7y ago

I assume you're referring to the OCI image format (not the runtime spec). This is because the OCI image format doesn't quite meet what they want for LXD -- in particular the whole layering design that OCI uses (which was inherited from Docker) is simply wrong for them. In fact there is a strong argument that the layering design doesn't even match what OCI really wants (it effectively embeds an optimisation for "docker build" into the storage format). I am actually working on improving the current state of OCI images[1] by using a snapshot-based tree structure -- which will also solve many problems we have in OCI that are independent from LXD. But it is possible that the LXD folks would be more interested if the OCI format more closely matched what they need. Though it should be noted that LXC has had an OCI template for several years now[2] (and it actually uses a tool I wrote -- umoci -- to extract the OCI image). [1]: https://www.youtube.com/watch?v=bbTxdzbjv7I https://www.youtube.com/watch?v=bbTxdzbjv7I [2]: https://github.com/lxc/lxc/blob/lxc-3.2.1/templates/lxc-oci.in https://github.com/lxc/lxc/blob/lxc-3.2.1/templates/lxc-oci....

psanford 7y ago
Yeah I am aware of the oci-template. I was mostly thinking of discussions like this[1] where Stéphane says there are no plans to support anything like that in LXD. I find the distinction between "system containers" and "application containers" to be a bit arbitrary from a technical perspective. What does it matter what I'm running as PID 1? I find both system containers and application containers to be useful. It seems like LXD would see larger adoption if it were easy to run docker container images directly (built into the LXD tooling). [1]: https://discuss.linuxcontainers.org/t/using-oci-templates-in-lxd/1911 https://discuss.linuxcontainers.org/t/using-oci-templates-in...