-
Notifications
You must be signed in to change notification settings - Fork 617
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make tests compatible with Vault 0.10 #497
Conversation
With this patch all tests passed for me with Consul 1.0.6, 1.0.7, and 1.1.0, so this may fix #494 entirely. |
hmm, why doesn't codeship pick this one up? |
When I change the versions in diff --git a/Makefile b/Makefile
index 6d2ff11..3a9ca94 100644
--- a/Makefile
+++ b/Makefile
@@ -27,8 +27,8 @@ GOVENDOR = $(shell which govendor)
VENDORFMT = $(shell which vendorfmt)
# pin versions for CI builds
-CI_CONSUL_VERSION=1.0.6
-CI_VAULT_VERSION=0.9.6
+CI_CONSUL_VERSION=1.1.0
+CI_VAULT_VERSION=0.10.1
CI_GO_VERSION=1.10.2
# all is the default target and run
|
Detect if a KV backend uses the new v2 versioning features and rewrite request paths and bodies if necessary. The new API uses additional /data/ and /metadata/ for GET/PUT and LIST operations, respectively. To facilitate versioning, v2 wraps the actual payload in a JSON object with "data" and "metadata" keys: { "data": {<payload (same as v1)>}, "metadata": { <versioning info> } }
Consul added suppported for compressed HTTP responses in 1.0.7, which means we can no longer rely on the Content-Length response header when checking if the server is ready yet.
d1ac0be
to
ac2a9a2
Compare
Turns out the API isn't directly backward compatible after all. I amended my commit, so that Fabio detects a v2 backend and modifies Vault requests accordingly. It's not exactly pretty but it works. The new methods are almost verbatim copies from Vault's cli implementation. This makes Fabio support the v2 backend automatically; no config change is required. The Vault policy must be updated, but that's not unique to Fabio. I seem to remember that a working sample policy is documented somewhere (in the wiki perhaps?) but I can't find it right now. The Consul tests failed because your sneaky readiness check stopped working when they introduced gzip support, and I addressed that too. |
When starting a new, empty Vault server, the mount at /secret will be
the K/V Version 2 backend by default. The API paths are subtly
different, but the new paths happen to also work with the Version 1
backend, so we can just always use the new paths in the test.
See https://www.vaultproject.io/docs/secrets/kv/kv-v2.html#acl-rules