-
Notifications
You must be signed in to change notification settings - Fork 372
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
Integration Test suite fails on modern versions of vault #852
Comments
FWIW, I collected possible causes for failures with Vault 1.9 in #786. |
@colin-pm @briantist most, if not all, of these failures are caused by breaking changes these features. Do we want version specific implementations of these features? Do we want to only support the current version? What are your thoughts on this? One idea would be for the client object to do a version check pretty early on, and then choose feature implementations based on that version. |
While it might be a pain, I think each failure/breaking change should be handled case-by-case,s o perhaps having an issue opened for each one would be best. I think it's going to be important to recognize whether My initial reaction is to avoid an implicit unavoidable version check by the library, in order to avoid extra round trips to the server. I hope in most cases we will not need that kind of workaround, but if we do, my general feeling is that the user of the library should specify the behavior in some way, with a parameter; one of the options for that parameter could be I would also be surprised if Vault had true breaking changes without incrementing major version number, but maybe they aren't using semver? I was not able to find out with a quick search. |
My thought was this issue would become a project, and one or more of the failing tests would be grouped into their own issues that are relevant to what is causing the failure. |
Ok that sounds good too. If we find we truly have breaking changes where we need to change behavior conditionally, due to incompatibilities in Vault, I had another idea for the longer term: we could have multiple major versions of Each new one has breaking changes, includes those needed to support newer Vault versions. The older ones keep compatibility with the Vault versions they maintain, and receive new non-breaking changes and bugfixes. The older stable versions would not be supported forever; we will have to drop support for them on some schedule, probably closely aligned to Vault's support. There are probably many ways to do this; the way I've seen it done in the world of Ansible collection projects is to have Changes landed to While specific to Ansible collections, this document describes the release branches process as it's done over there. This does add some complication to releasing, but it has the advantage of being able to release new major versions sooner to respond to changes in Vault, without shutting the door on any other changes and improvements being added to a release that's still compatible with an older version. Most importantly, it means we don't have to add a lot of conditionals or other workarounds to support multiple versions simultaneously. Those could be hard error prone, hard to test, and then there's additional work to remove them safely. With separate major versions, the older stable versions go out of support and we simply stop backporting and releasing to them. We don't have to do this right away, or before 1.0.0 either, just something to think about. |
Thanks @adammike and @yan12125 for documenting these test failures. I created #856, #857, #858, #859, #860, #861, #862, #863, #864, and #865 to break up the test failures into individual issues, grouped by module. Since we would like to have these tests fixed by the 1.0.0 release of HVAC, all issues have been assigned to that work effort. When I've looked at these tests failures previously, the failures in each module stem from a common issue, so I figure this will give us the granularity to address the failures on a case-by-case basis as @briantist suggested. |
…e most tests * Switch to PEP517 as upstream switches to poetry hvac/hvac#854 * python-pyhcl is now required instead of optional after the PR above * Re-enable most integration tests after upstream fixes - see hvac/hvac#852 and related pull requests git-svn-id: file:///srv/repos/svn-community/svn@1305193 9fca08f4-af9d-4005-b8df-a31f2cc04f65
…e most tests * Switch to PEP517 as upstream switches to poetry hvac/hvac#854 * python-pyhcl is now required instead of optional after the PR above * Re-enable most integration tests after upstream fixes - see hvac/hvac#852 and related pull requests git-svn-id: file:///srv/repos/svn-community/svn@1305193 9fca08f4-af9d-4005-b8df-a31f2cc04f65
The hvac pipeline runs all of the linting and documentation tests against vault 1.7.2+ent. The integration tests run on 1.4.7+ent, 1.5.9+ent, 1.6.5+ent, and 1.7.2+ent
Vault 1.9, 1.10, and 1.11 are supported. Hashicorp's official policy is that they support vault for the two previous major releases or 2 years, whichever is shorter. That means that our pipeline is currently testing on severely out of date versions of vault.
I've ran our test suite on every vault version from 1.6.0 to current and here are my findings:
✅ All tests pass on 1.6.0->1.7.10 on enterprise versions of vault
❌ Starting in 1.8.0 vault enterprise forces a license check on the dev server, which causes all of our tests to fail on any enterprise vault after 1.7.10.
✅ All tests pass on 1.6.0-1.8.12 on open-source versions of vault, but tests for enterprise features are skipped
❌ In 1.9.0 we start seeing test failures:
The text was updated successfully, but these errors were encountered: