T264209 has shown that we'll need a different way of distributing docker images to kubernetes nodes.
I did a evaluation of Kraken and Dragonfly as docker-registry P2P layers (https://wikitech.wikimedia.org/wiki/User:JMeybohm/Docker-Registry-P2P) and settled with Dragonfly for a first test.
Notes I took during initial packaging, testing and writing first puppet code:
- Does "supernode --cdn-pattern source" mean the supernode is not used as seeder at all (and does requests parts from remote/source in any case?)
- While this seems to be the case, dfget does not work when the file server/downloadPort is not set
- tcpdump says dfget just connects to downloadPort (no requests are send) : https://github.com/dragonflyoss/Dragonfly/issues/1558
- dfdaemon does not listen to localhost only, even though it is configured to 127.0.0.1
- dfdeamon/dfget will probably leak authentication credentials (HTTP headers) as they are passed as arguments
- Yep, it does - during the download but not during the serving. https://github.com/dragonflyoss/Dragonfly/issues/1557
- I'd assume that there also is no credential checking, so pulling "restricted" chunks from peers might work without authentication
- supernode writes debug logs although "debug: false" is configured. https://github.com/dragonflyoss/Dragonfly/issues/1559
- While testing, multiple ways where discovered to silently disable P2P with simple mistakes. Extra caution is advised.
- What about TLS for supernode listenPort?
- What about TLS for dfget --server on the peers?
- What about Dragonfly2?
- Can't find proper info on roadmap or so
- Seems like a full fledge registry rewrite (like kraken)
- Will development on old Drafgonfly stop?