Re:Rocket and App Container 0.2.0 Release
by robszumski on Friday January 23, 2015 @07:11PM
(#8938197)
Bitorrent was mentioned in the original blog post as a nice to have feature in the future:
> Image distribution. Discovery of container images should be simple and facilitate a federated namespace, and distributed retrieval. This opens the possibility of alternative protocols, such as BitTorrent, and deployments to private environments without the requirement of a registry.
There is an open issue if you want to help out or follow along: https://github.com/coreos/rocket/issues/405
Re:Rocket and App Container 0.2.0 Release
by lclarkmichalek on Friday January 23, 2015 @07:14PM
(#8938207)
Subscribed, though I was thinking of it rather more generically: how hard would it be to have some service that magically puts images in the correct place, and have rocket look there? The idea of rocket having a bittorrent client on board rather scares me :)
There are certainly a few ways this could work; for example, since Rocket currently uses a generic CAS backend to store assets, and is designed to expect multiple simultaneous invocations (using filesystem locking etc), it's feasible for an external service to be pulling down images out of band that Rocket could then consume.
Reading the signing and verification stuff, the section on "Distributing Images via Meta Discovery" reminded me of my personal dream: bittorrent based distribution. How hard would this be? Seeing as the ACI tarballs seem to be just stored on disk, would it simply be a case of telling my bittorrent client to dump all my ACIs in some folder and then getting rocket to look there? Or is there a need to write some kind of rocket plugin for that kind of thing?