HVT-4279 add support for cloudwatch observability on vault_cluster resource #580
Conversation
|
|
| Description: "CloudWatch access key ID for streaming audit logs", | ||
| Type: schema.TypeString, | ||
| Computed: true, | ||
| }, |
There was a problem hiding this comment.
Looks like we need cloudwatch_secret_access_key here as well?
There was a problem hiding this comment.
done, funny how the code for preventing the value from the state file from being updated with "redacted" prevented this issue from surfacing in my tests 😆
|
Looks great! Just one small question |
| configMap["cloudwatch_access_key_id"] = cloudwatch.AccessKeyID | ||
| configMap["cloudwatch_region"] = cloudwatch.Region | ||
| // ensure we only set properties that are defined in metrics/audit-logs streaming | ||
| if propertyName == "metrics_config" { |
There was a problem hiding this comment.
How do you find out whether a field within a provider should only be set for metrics/only set for audit logs?
There was a problem hiding this comment.
sorry, it's kinda messy. Have a look at applyObservabilityConfigMutations on cloud-vault-service to see what fields are automatically set by us when creating/updating the observability configs, not how they're different for metrics/logs. There's also elsasticsearch.go with the Vector definition for each of the providers.
There was a problem hiding this comment.
let me know if it's still unclear and I can walk you through the relevant code.
Also, you could open the UI and see what fields are shown for logs/ metrics when configuring elasticsearch
🛠️ Description
Add CloudWatch option for observability providers on HCP Vault clusters. See HVT-4279. I manually tested updating the audit-logs and metrics settings using the TF provider on cluster creation and cluster updates. Didn't add an acceptance test because the increase in the test duration didn't seem justified by such a small change.
🏗️ Acceptance tests
Output from acceptance testing: