[VAULT-35162] Development Cluster setting docs #30659
Merged
Conversation
This file contains hidden or 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
|
CI Results: |
|
Build Results: |
VioletHynes
reviewed
May 16, 2025
divyaac
previously approved these changes
May 16, 2025
Co-authored-by: Violet Hynes <violet.hynes@hashicorp.com>
Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com>
e5f3901 to
35b5210
Compare
yhyakuna
approved these changes
May 19, 2025
divyaac
approved these changes
May 19, 2025
erentantekin
pushed a commit
that referenced
this pull request
May 23, 2025
* add docs * change wording * add changelog * Update changelog/30659.txt Co-authored-by: Violet Hynes <violet.hynes@hashicorp.com> * Apply suggestions from code review Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com> --------- Co-authored-by: Violet Hynes <violet.hynes@hashicorp.com> Co-authored-by: Yoko Hyakuna <yoko@hashicorp.com>
finnstech
reviewed
Jun 10, 2025
| indicates whether the cluster is used for development (non-production) purposes. By default, the field is set to `false`, | ||
| indicating the cluster is running in a production environment. Changing the value is done via HCL configuration by adding | ||
| the `development_cluster` field to the `license` parameter within the `reporting` stanza. | ||
|
|
There was a problem hiding this comment.
Would be helpful to indicate that this should only be done if the cluster is not a production cluster -- there are EULA implications if this is applied to a prod cluster
| reported `development_cluster` value when the primary cluster changes. | ||
|
|
||
| Within each cluster, each node must have the same `development_cluster` setting in its configuration to be consistent. | ||
| In the event of leadership change, nodes will use its server configuration to determine the value to report. |
There was a problem hiding this comment.
"In the event of a leadership change, each node will use its own server configuration to determine the value to report."
|
|
||
| Within each cluster, each node must have the same `development_cluster` setting in its configuration to be consistent. | ||
| In the event of leadership change, nodes will use its server configuration to determine the value to report. | ||
| Inconsistent configuration between nodes will change the `development_cluster` setting reported upon active unseal. |
There was a problem hiding this comment.
Can you be more specific with an example?
| @@ -240,6 +280,7 @@ HashiCorp collects the following utilization data as JSON payloads: | |||
|
|
|||
| - `cluster_id` - The cluster UUID as shown by `vault status` on the reporting | |||
| cluster | |||
There was a problem hiding this comment.
put a period at the end for consistency
6 tasks
6 tasks
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.
Description
This PR adds the documentation for the new
development_clusterconfig value and Census report metadata field. It also includes the changelog for the feature.Jira: https://hashicorp.atlassian.net/browse/VAULT-35162
RFC: https://go.hashi.co/rfc/vlt-348
TODO only if you're a HashiCorp employee
backport/label that matches the desired release branch. Note that in the CE repo, the latest release branch will look likebackport/x.x.x, but older release branches will bebackport/ent/x.x.x+ent.of a public function, even if that change is in a CE file, double check that
applying the patch for this PR to the ENT repo and running tests doesn't
break any tests. Sometimes ENT only tests rely on public functions in CE
files.
in the PR description, commit message, or branch name.
description. Also, make sure the changelog is in this PR, not in your ENT PR.