You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@camel.apache.org by GitBox <gi...@apache.org> on 2021/11/08 09:05:03 UTC
[GitHub] [camel-k] lburgazzoli opened a new issue #2732: use the OCI containers to distribute camel-k artifacts
lburgazzoli opened a new issue #2732:
URL: https://github.com/apache/camel-k/issues/2732
Open Container Initiative (OCI) has defined [specs](https://github.com/opencontainers/image-spec) to enable the creation of interoperable tools for building, transporting, and preparing a container image to run, however - in practice - registries have a little to do with container images and we can think about them as a content addressable storage.
In camel-k we have been struggling a lot about find an easy way to provide artifacts/blobs to the runtime and I think experimenting about leveraging OCI compatible registries could be a way to improve the situation.
This is not a brand new novel idea as:
- some discussion about leveraging container images have been happened already in the camel-k community
- solo.io [leverages](https://github.com/solo-io/wasm/blob/master/spec/spec.md) container images to distribute WASM
- there has been a recent talk about hacking the registry at [kubecon](https://t.co/hqeHSA4Yqf?amp=1)
Since each `layer` is essential a blob (often a `tar.gz`) and that the `layer` definition has an optional `annotations` property that can hold arbitrary key/value paris, we can leverage it to identify camel-k artifacts (i.e. additional dependencies, resources, kamelets repositories, etc):
```json
{
"schemaVersion": 2,
"layers": [{
"mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
"size": 16724,
"digest": "sha256:3c3a4604a545cdc127456d94e421cd355bca5b528f4a9c1905b15da2eb4a4c6b",
"annotations": {
"camel.apache.org.dependency": "com.acme:foo:1.0"
}
}, {
"mediaType": "application/vnd.oci.image.layer.v1.tar+gzip",
"size": 73109,
"digest": "sha256:ec4b8955958665577945c89419d1af06b5f7636b4ac3da7f12184802ad867736",
"annotations": {
"camel.apache.org.kamelets.repository": "acme-kamelets"
}
}
]
}
```
**NOTES**:
1. solo.io has introduced a set of additional `mediaType` values but that may not work with some registries or tools so IMHO, at this stage, it would be better not to introduce a custom media type and leverage annotations.
2. A further evolution would be to implement a [Kubernetes Container Storage Interface (CSI)](https://github.com/kubernetes-cs) to mount OCI layers to a POD
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] lburgazzoli commented on issue #2732: use the OCI containers to distribute camel-k artifacts
Posted by GitBox <gi...@apache.org>.
lburgazzoli commented on issue #2732:
URL: https://github.com/apache/camel-k/issues/2732#issuecomment-962944761
/cc @nicolaferraro @astefanutti
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] github-actions[bot] commented on issue #2732: use the OCI containers to distribute camel-k artifacts
Posted by GitBox <gi...@apache.org>.
github-actions[bot] commented on issue #2732:
URL: https://github.com/apache/camel-k/issues/2732#issuecomment-1030948147
This issue has been automatically marked as stale due to 90 days of inactivity.
It will be closed if no further activity occurs within 15 days.
If you think that’s incorrect or the issue should never stale, please simply write any comment.
Thanks for your contributions!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] lburgazzoli commented on issue #2732: use the OCI containers to distribute camel-k artifacts
Posted by GitBox <gi...@apache.org>.
lburgazzoli commented on issue #2732:
URL: https://github.com/apache/camel-k/issues/2732#issuecomment-962970792
> It seems like it would be the right level to abstract our needs for _packaging_ and _distributing_ artifacts.
>
> From the performance standpoint, interaction with the container registry is now the major contributor to "TTFB" (Camel K equivalent) on average. And it does not scale well with the number of nodes. I'd be eager to research how it could use in combination with some initiatives / approaches like the above to improve performance, especially for the serverless use case:
>
> * [medium.com/nttlabs/startup-containers-in-lightning-speed-with-lazy-image-distribution-on-containerd-243d94522361](https://medium.com/nttlabs/startup-containers-in-lightning-speed-with-lazy-image-distribution-on-containerd-243d94522361)
>
> * [stevelasker.blog/2019/10/29/azure-container-registry-teleportation](https://stevelasker.blog/2019/10/29/azure-container-registry-teleportation/)
There is also this one that may be interesting https://cloud.google.com/blog/products/containers-kubernetes/introducing-container-image-streaming-in-gke
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [camel-k] astefanutti commented on issue #2732: use the OCI containers to distribute camel-k artifacts
Posted by GitBox <gi...@apache.org>.
astefanutti commented on issue #2732:
URL: https://github.com/apache/camel-k/issues/2732#issuecomment-962963176
It seems like it would be the right level to abstract our needs for _packaging_ and _distributing_ artifacts.
From the performance standpoint, interaction with the container registry is now the major contributor to "TTFB" (Camel K equivalent) on average. And it does not scale well with the number of nodes. I'd be eager to research how it could use in combination with some initiatives / approaches like the above to improve performance, especially for the serverless use case:
* https://medium.com/nttlabs/startup-containers-in-lightning-speed-with-lazy-image-distribution-on-containerd-243d94522361
* https://stevelasker.blog/2019/10/29/azure-container-registry-teleportation/
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@camel.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org