Files
vault/changelog
Mike Palmiotto f503f739de identity: Resolve conflicts with rename (#29356)
This PR introduces a new type of conflict resolution for duplicate
Entities and Groups. Renaming provides a way of preventing Vault from
entering case-sensitive mode, which is the current behavior for any kind
of duplicate.

Renames append the conflicting identity artifact's UUID to its name and
updates a metadata field to indicate the pre-existing artifact's UUID.

The feature is gated by the force-identity-deduplication activation flag.

In order to maintain consistent behavior between the reporting resolver
and the rename operation, we need to adjust the behavior of generated
reports. Previously, they intentionally preserved existing Group merge
determinism, wherein the last MemDB update would win and all others
would be renamed. This approach is more complicated for the rename
resolver, since we would need to update any duplicated entity in the
cache while inserting the new duplicate (resulting in two MemDB
operations). Though we can ensure atomic updates of the two identity
artifacts with transactions (which we could get for groups with a minor
adjustment, and we will get along with batching of Entity upserts on 
load), it's far simpler to just rename all but the first insert as proposed
in the current PR.

Since the feature is gated by an activation flag with appropriate 
warnings of potential changes via the reporting resolver, we opt
for simplicity over maintaining pre-existing behavior. We can revisit
this assumption later if we think alignment with existing behavior
outweighs any potential complexity in the rename operation.

Entity alias resolution is left alone as a destructive merge operation
to prevent a potentially high-impact change in existing behavior.
2025-01-15 14:24:49 -05:00
..
2023-02-03 12:26:25 -05:00
2023-06-15 12:52:13 -07:00
2024-09-10 16:59:08 +00:00
2024-11-15 13:32:09 -05:00
2022-08-24 09:03:30 -04:00
2024-06-04 10:19:18 -07:00
2022-12-07 13:29:51 -05:00
2022-05-18 09:16:13 -07:00
2022-05-20 10:41:24 -05:00
2022-05-25 13:37:42 -05:00
2022-06-13 13:17:07 -05:00
2022-06-03 09:17:41 -07:00
2022-06-03 14:22:50 -07:00
2022-06-09 15:55:49 -07:00
2022-07-22 09:50:28 -07:00
2022-06-21 12:27:24 -04:00
2022-09-22 09:12:41 -04:00
2022-07-27 15:22:38 -05:00
2022-08-03 20:44:57 -05:00
2022-08-05 10:27:37 -07:00
2022-08-23 11:08:23 -04:00
2022-09-08 11:32:46 -04:00
2022-09-01 16:15:54 -06:00
2022-09-06 15:49:35 -04:00
2022-10-18 09:46:02 -06:00
2022-09-30 18:28:27 -04:00
2022-10-26 15:34:43 -06:00
2022-12-01 16:56:59 -08:00
2022-11-16 09:27:56 -05:00
2022-11-02 13:23:09 -06:00
2022-11-10 12:11:23 -08:00
2022-11-09 12:00:24 -05:00
2022-11-11 11:04:10 -08:00
2022-11-18 10:38:18 -05:00
2022-12-01 09:33:30 -06:00
2022-12-08 15:02:18 -05:00
2022-12-13 14:50:11 -07:00
2023-01-16 13:49:28 -05:00
2023-03-07 16:23:45 +00:00
2023-01-23 15:51:22 -05:00
2023-01-17 16:37:07 -07:00
2023-01-25 15:19:45 +00:00
2023-01-27 18:07:55 +00:00
2023-02-06 09:41:56 -05:00
2023-02-07 14:22:22 -07:00
2023-02-14 17:00:24 +00:00
2023-02-16 22:44:33 +00:00
2023-05-02 19:36:15 -06:00
2023-03-17 07:52:54 -07:00
2023-04-05 10:54:27 -05:00
2023-03-31 11:01:02 -04:00
2023-03-31 15:05:16 +00:00
2023-04-03 15:24:58 -06:00
2023-04-18 14:20:27 -07:00
2023-04-18 07:39:05 -04:00
2023-04-19 14:30:18 -05:00
2023-05-01 16:43:05 +00:00
2023-05-04 13:23:06 -07:00
2023-05-17 11:41:02 -05:00
2023-05-16 10:38:53 -06:00
2023-08-25 10:54:29 -06:00
2023-05-31 14:21:36 -06:00
2023-08-22 15:21:38 +00:00
2023-06-07 15:19:29 +02:00
2023-06-21 14:47:53 -07:00
2023-08-14 15:25:39 -07:00
2023-07-05 17:20:18 +00:00
2023-07-10 10:28:42 -07:00
2023-07-19 23:57:37 +00:00
2023-07-19 19:23:42 +00:00
2023-08-01 14:02:21 -05:00
2023-08-15 19:00:29 +00:00
2023-08-08 13:49:26 -07:00
2023-08-14 12:35:34 -07:00
2024-04-30 10:47:45 -04:00
2023-08-31 23:31:42 +01:00
2023-09-06 11:07:48 -04:00
2023-10-23 18:46:42 +00:00
2023-09-18 10:48:03 -05:00
2023-10-05 13:50:16 -07:00
2023-10-05 09:29:20 -06:00
2023-10-11 09:12:44 -06:00
2023-10-12 17:34:38 +00:00
2023-12-13 11:16:44 -08:00
2024-02-14 11:52:34 -06:00
2023-10-17 15:36:35 -06:00
2023-10-25 21:02:58 +00:00
2023-11-13 21:29:39 +00:00
2023-11-08 11:01:01 +00:00
2023-11-21 15:11:14 -06:00
2023-12-04 10:40:34 -06:00
2023-12-18 17:03:35 +00:00
2024-01-11 15:19:16 -06:00
2024-01-24 18:04:44 +00:00
2024-02-14 11:52:34 -06:00
2024-02-20 11:42:59 -08:00
2024-02-26 09:02:05 -07:00
2024-02-26 20:19:35 +00:00
2024-03-28 13:45:43 -05:00
2024-04-09 12:35:39 -07:00
2024-04-12 22:13:45 +00:00
2024-05-27 15:03:59 -04:00
2024-05-07 11:34:21 -05:00
2024-07-09 09:36:23 -07:00
2024-06-28 13:12:10 -07:00
2024-08-05 16:26:24 -07:00
2024-08-15 09:26:51 -07:00
2024-08-29 12:17:51 -06:00
2024-10-21 15:12:31 -04:00
2024-10-22 14:57:26 +02:00
2024-11-06 00:52:29 +00:00
2024-12-04 13:23:55 -05:00
2025-01-09 11:58:29 -08:00

changelog

This folder holds changelog updates from commit 3bc7d15 onwards.

Release notes are text files with three lines:

  1. An opening code block with the release-note:<MODE> type annotation.

    For example:

    ```release-note:bug
    

    Valid modes are:

    • bug - Any sort of non-security defect fix.
    • change - A change in the product that may require action or review by the operator. Examples would be any kind of API change (as opposed to backwards compatible addition), a notable behavior change, or anything that might require attention before updating. Go version changes are also listed here since they can potentially have large, sometimes unknown impacts. (Go updates are a special case, and dep updates in general aren't a change). Discussion of any potential change items in the pull request to see what other communication might be warranted.
    • deprecation - Announcement of a planned future removal of a feature. Only use this if a deprecation notice also exists in the docs.
    • feature - Large topical additions for a major release. These are rarely in minor releases. Formatting for feature entries differs from normal changelog formatting - see the new features instructions.
    • improvement - Most updates to the product that arent bugs, but aren't big enough to be a feature, will be an improvement.
  2. A component (for example, secret/pki or sdk/framework or), a colon and a space, and then a one-line description of the change.

  3. An ending code block.

If more than one area is impacted, use separate code blocks for each entry.

This should be in a file named after the pull request number (e.g., 12345.txt).

There are many examples in this folder; check one out if you're stuck!

See hashicorp/go-changelog for full documentation on the supported entries.

New and Major Features

For features we are introducing in a new major release, we prefer a single changelog entry representing that feature. This way, it is clear to readers what feature is being introduced. You do not need to reference a specific PR, and the formatting is slightly different - your changelog file should look like:

changelog/<pr num OR feature name>.txt:
```release-note:feature
**Feature Name**: Description of feature - for example "Custom password policies are now supported for all database engines."
```