Upstream tag v1.14.3 (revision 56debfa71) #56
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Co-authored-by: Alexander Scheel <alex.scheel@hashicorp.com>
Co-authored-by: Violet Hynes <violet.hynes@hashicorp.com>
Co-authored-by: Anton Averchenkov <84287187+averche@users.noreply.github.com>
Co-authored-by: Nick Cabatoff <ncabatoff@hashicorp.com>
Co-authored-by: Josh Black <raskchanky@gmail.com>
Co-authored-by: Violet Hynes <violet.hynes@hashicorp.com>
Co-authored-by: Violet Hynes <violet.hynes@hashicorp.com>
Co-authored-by: miagilepner <mia.epner@hashicorp.com>
* Backport initial release notes drafting * Updates for GA
Co-authored-by: Steven Clark <steven.clark@hashicorp.com>
Co-authored-by: Alexander Scheel <alex.scheel@hashicorp.com>
Co-authored-by: Alexander Scheel <alex.scheel@hashicorp.com>
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
Co-authored-by: Nick Cabatoff <ncabatoff@hashicorp.com>
Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com>
Co-authored-by: Violet Hynes <violet.hynes@hashicorp.com>
Co-authored-by: Rowan Smith <86935689+rowansmithhc@users.noreply.github.com>
Co-authored-by: Meggie <meggie@hashicorp.com>
Co-authored-by: Anton Averchenkov <84287187+averche@users.noreply.github.com> Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
Co-authored-by: Nick Cabatoff <ncabatoff@hashicorp.com> Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
Co-authored-by: Doug Knight <doug.knight@karmix.org>
Co-authored-by: Shubham P <shubham.prajapat@sourcefuse.com>
Co-authored-by: claire bontempo <68122737+hellobontempo@users.noreply.github.com>
Co-authored-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Jason O'Donnell <2160810+jasonodonnell@users.noreply.github.com>
Co-authored-by: Anton Averchenkov <84287187+averche@users.noreply.github.com>
Add an updated `target_ec2_instances` module that is capable of dynamically splitting target instances over subnet/az's that are compatible with the AMI architecture and the associated instance type for the architecture. Use the `target_ec2_instances` module where necessary. Ensure that `raft` storage scenarios don't provision unnecessary infrastructure with a new `target_ec2_shim` module. After a lot of trial, the state of Ec2 spot instance capacity, their associated APIs, and current support for different fleet types in AWS Terraform provider, have proven to make using spot instances for scenario targets too unreliable. The current state of each method: * `target_ec2_fleet`: unusable due to the fact that the `instant` type does not guarantee fulfillment of either `spot` or `on-demand` instance request types. The module does support both `on-demand` and `spot` request types and is capable of bidding across a maximum of four availability zones, which makes it an attractive choice if the `instant` type would always fulfill requests. Perhaps a `request` type with `wait_for_fulfillment` option like `aws_spot_fleet_request` would make it more viable for future consideration. * `target_ec2_spot_fleet`: more reliable if bidding for target instances that have capacity in the chosen zone. Issues in the AWS provider prevent us from bidding across multiple zones succesfully. Over the last 2-3 months target capacity for the instance types we'd prefer to use has dropped dramatically and the price is near-or-at on-demand. The volatility for nearly no cost savings means we should put this option on the shelf for now. * `target_ec2_instances`: the most reliable method we've got. It is now capable of automatically determing which subnets and availability zones to provision targets in and has been updated to be usable for both Vault and Consul targets. By default we use the cheapest medium instance types that we've found are reliable to test vault. * Update .gitignore * enos/modules/create_vpc: create a subnet for every availability zone * enos/modules/target_ec2_fleet: bid across the maximum of four availability zones for targets * enos/modules/target_ec2_spot_fleet: attempt to make the spot fleet bid across more availability zones for targets * enos/modules/target_ec2_instances: create module to use ec2:RunInstances for scenario targets * enos/modules/target_ec2_shim: create shim module to satisfy the target module interface * enos/scenarios: use target_ec2_shim for backend targets on raft storage scenarios * enos/modules/az_finder: remove unsed module Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Steven Clark <steven.clark@hashicorp.com>
Co-authored-by: Sean Ellefson <sellefson@hashicorp.com> Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
Co-authored-by: Luis (LT) Carbonell <lt.carbonell@hashicorp.com>
Signed-off-by: Alexander Scheel <alex.scheel@hashicorp.com>
…14.x (hashicorp#22707) * Manual backport of changes via cherrypicking
…r each lease (hashicorp#22651) (hashicorp#22730) * Add config value that gives users options to skip calculating role for each lease * add changelog * change name * add config for testing * Update changelog/22651.txt * update tests, docs and reorder logic in conditional * fix comment * update comment * fix comment again * Update comments and change if order * change comment again * add other comment * fix tests * add documentation * edit docs * Update http/util.go * Update vault/core.go * Update vault/core.go * update var name * udpate docs * Update vault/request_handling.go * 1 more docs change --------- Co-authored-by: Ellie <ellie.sterner@hashicorp.com> Co-authored-by: Violet Hynes <violet.hynes@hashicorp.com> Co-authored-by: Mike Palmiotto <mike.palmiotto@hashicorp.com>
Co-authored-by: Jason O'Donnell <2160810+jasonodonnell@users.noreply.github.com>
Co-authored-by: Mike Palmiotto <mike.palmiotto@hashicorp.com>
Co-authored-by: Sarah Chavis <62406755+schavis@users.noreply.github.com>
Co-authored-by: Josh Black <raskchanky@gmail.com>
Co-authored-by: Alexander Scheel <alex.scheel@hashicorp.com>
Co-authored-by: Cinthia Conti <cinthiaconti@gmail.com>
…corp#22768) * Update go-kms-wrapping to get Azure HTTP/2 workaround (1.14.x) * changelog
Co-authored-by: Bianca Moreira <48203644+biazmoreira@users.noreply.github.com>
Co-authored-by: Scott Miller <smiller@hashicorp.com>
Co-authored-by: Scott Miller <smiller@hashicorp.com>
…ase/1.14.x (hashicorp#22830) * backport of commit 2ca784a --------- Co-authored-by: Chelsea Shaw <82459713+hashishaw@users.noreply.github.com> Co-authored-by: Chelsea Shaw <cshaw@hashicorp.com>
* bump go version to 1.20.8 on 1.14.x * go mod tidy
…hicorp#22933) Replace our prior implementation of Enos test groups with the new Enos sampling feature. With this feature we're able to describe which scenarios and variant combinations are valid for a given artifact and allow enos to create a valid sample field (a matrix of all compatible scenarios) and take an observation (select some to run) for us. This ensures that every valid scenario and variant combination will now be a candidate for testing in the pipeline. See QT-504[0] for further details on the Enos sampling capabilities. Our prior implementation only tested the amd64 and arm64 zip artifacts, as well as the Docker container. We now include the following new artifacts in the test matrix: * CE Amd64 Debian package * CE Amd64 RPM package * CE Arm64 Debian package * CE Arm64 RPM package Each artifact includes a sample definition for both pre-merge/post-merge (build) and release testing. Changes: * Remove the hand crafted `enos-run-matrices` ci matrix targets and replace them with per-artifact samples. * Use enos sampling to generate different sample groups on all pull requests. * Update the enos scenario matrices to handle HSM and FIPS packages. * Simplify enos scenarios by using shared globals instead of cargo-culted locals. Note: This will require coordination with vault-enterprise to ensure a smooth migration to the new system. Integrating new scenarios or modifying existing scenarios/variants should be much smoother after this initial migration. [0] hashicorp/enos#102 Signed-off-by: Ryan Cragun <me@ryan.ec> Co-authored-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Kit Haines <khaines@mit.edu>
Co-authored-by: Niklas Rosencrantz <niklasr@protonmail.com>
…rp#22945) Signed-off-by: Ryan Cragun <me@ryan.ec>
…corp#22948) (hashicorp#22951) Signed-off-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: Ryan Cragun <me@ryan.ec>
Co-authored-by: xka5h <74259424+xka5h@users.noreply.github.com>
Co-authored-by: Ryan Cragun <me@ryan.ec>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Integrating latest changes from hashicorp/vault tag v1.14.3
Commit summary omitted as it exceeds maximum message size.