We have been using this for a few weeks with 3.7 and no issue. I've tried to retain backwards compatibility, and I'm sure that this worked with puppet 3.4, although not very sure whether in an older code shape or in current rebase. Regarding older clients, /api/v1/releases.json is not ported in any way. It's a very complex operation, and my rewrite attempts did end with puppet client timeouts. Fortunately, it is served by current puppet V3 forge, so I'f left basically unchanged.
There is also an issue on modules served from git repositories, because V3 metadata includes a checksum of the tar.gz, and seems that creating them on the fly does not produce always the same md5, so that part of acceptance tests do randomly fail, although usually succeed after one or two retries.
The offline_proxy_forge_integration test is disabled because librarian-puppet ends with a query to V1 api that cannot be resolved, and I've also disabled a few of rspec examples for whom I did only get quite ad-hoc fixes.
drrb
commented
9 years ago
We have been using this for a few weeks with 3.7 and no issue. I've tried to retain backwards compatibility, and I'm sure that this worked with puppet 3.4, although not very sure whether in an older code shape or in current rebase. Regarding older clients, /api/v1/releases.json is not ported in any way. It's a very complex operation, and my rewrite attempts did end with puppet client timeouts. Fortunately, it is served by current puppet V3 forge, so I'f left basically unchanged.
There is also an issue on modules served from git repositories, because V3 metadata includes a checksum of the tar.gz, and seems that creating them on the fly does not produce always the same md5, so that part of acceptance tests do randomly fail, although usually succeed after one or two retries.
The offline_proxy_forge_integration test is disabled because librarian-puppet ends with a query to V1 api that cannot be resolved, and I've also disabled a few of rspec examples for whom I did only get quite ad-hoc fixes.
Resolve #6