jhaals / puppet-anvil Goto Github PK

I'm opening this up to start a conversation about potentially adding the ability to proxy requests to another forge, such as the Puppet public forge.

My use case is as following.

Currently, I'm using puppet-anvil and puppet-forge-mirror (thanks for putting those out there!) to successfully serve up privately developed modules as well as modules from the forge. However, there is a period of time from whenever the forge server comes up and when puppet-forge-mirror gets a complete mirror of the public forge. During that time, any hosts that come online would have a pretty good chance of not being able to have a successful puppet run. I'm also anticipating some issues with running the puppet-forge-mirror periodically (daily most likely) and an update to a module gets pushed to the forge, but is unavailable in my mirror until the next puppet-forge-mirror run.

I'm toying with the idea of adding optional proxy support to help with this use case. If the module/release is unavailable, then proxy the request to the user-configured forge.

I haven't given too much thought to the implementation, but it seems doable.

What are your thoughts?

Thanks!
Paul

The modules endpoint is used by librarian-puppet to fetch module information, so currently it doesn't work with puppet-anvil.

The puppet_forge ruby gem (used by librarian-puppet for example) depends on the pagination in the V3 API. It would be good if puppet anvil supported that.

I was thinking, in the spirit of keeping things light weight and free of external resource dependencies, we would use a simple token based auth.

The server can be informed of the token via its environment:

ANVIL_TOKEN=275dece4-3092-11e5-9c7c-34e6d77dca6c PORT=8080 MODULEPATH=/var/lib/puppet-anvil/modules ./build/puppet-anvil

and clients accessing /admin resources could supply the token in a header:

curl -H "X-ANVIL-TOKEN: 275dece4-3092-11e5-9c7c-34e6d77dca6c" -X PUT http://localhost:8080/admin/module/puppetlabs-stdlib-4.6.0.tar.gz -T ./puppetlabs-stdlib-4.6.0.tar.gz

Not supplying this env var could result in either making the /admin namespace unreachable / always Forbidden, or it could default to being always open.

Alternatively, we could skip this alltogether and say that it is the responsibility of a reverse proxy with content splitting.

What do you think?