Change Details

T264209 has shown that we'll need a different way of distributing docker images to kubernetes nodes. I did a evaluation of [[ https://github.com/uber/kraken | Kraken ]] and [[ https://github.com/dragonflyoss/Dragonfly | 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) -> Bug? * dfdaemon does not listen to localhost only, even though it is configured to 127.0.0.1 * Bug? * 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. * While testing, multiple ways where discovered to silently disable P2P with simple mistakes. Extra caution is advised. * https://gerrit.wikimedia.org/r/c/operations/puppet/+/705382 * https://gerrit.wikimedia.org/r/c/operations/puppet/+/705627 * What about TLS for supernode listenPort? * What about TLS for dfget --server on the peers? * What about [[ https://github.com/dragonflyoss/Dragonfly2 | 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?

T264209 has shown that we'll need a different way of distributing docker images to kubernetes nodes. I did a evaluation of [[ https://github.com/uber/kraken | Kraken ]] and [[ https://github.com/dragonflyoss/Dragonfly | 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 * Bug? * 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. * https://gerrit.wikimedia.org/r/c/operations/puppet/+/705382 * https://gerrit.wikimedia.org/r/c/operations/puppet/+/705627 * What about TLS for supernode listenPort? * What about TLS for dfget --server on the peers? * What about [[ https://github.com/dragonflyoss/Dragonfly2 | 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?

T264209 has shown that we'll need a different way of distributing docker images to kubernetes nodes. I did a evaluation of [[ https://github.com/uber/kraken | Kraken ]] and [[ https://github.com/dragonflyoss/Dragonfly | 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) -> Bug? : https://github.com/dragonflyoss/Dragonfly/issues/1558 * dfdaemon does not listen to localhost only, even though it is configured to 127.0.0.1 * Bug? * 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. * https://gerrit.wikimedia.org/r/c/operations/puppet/+/705382 * https://gerrit.wikimedia.org/r/c/operations/puppet/+/705627 * What about TLS for supernode listenPort? * What about TLS for dfget --server on the peers? * What about [[ https://github.com/dragonflyoss/Dragonfly2 | 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?