=> terraform plan
datadog_application_key.jackakeller-foo: Refreshing state... [id=ad77b716-c871-4e94-bb53-cef5ed244551]
data.datadog_application_key.foo: Reading...
data.datadog_application_key.foo: Read complete after 0s [id=ad77b716-c871-4e94-bb53-cef5ed244551]
No changes. Your infrastructure matches the configuration.
Terraform has compared your real infrastructure against your configuration and found no differences, so no changes are needed.
╷
│ Warning: Deprecated
│
│ with data.datadog_application_key.foo,
│ on main.tf line 24, in data "datadog_application_key" "foo":
│ 24: data "datadog_application_key" "foo" {
│
│ The datadog_application_key data source is deprecated and will be removed in a future release with prior notice. Securely store your application key using a secret management
│ system or use the datadog_application_key resource to manage application keys in your Datadog account.
│
This also is printed for terraform refresh and terraform apply. On either refresh or apply the key is still stored in Terraform state.
Error when deprecated source is used and application key is not provided from the datadog API:
=> terraform plan
data.datadog_application_key.foo: Reading...
datadog_application_key.jackakeller-foo: Refreshing state... [id=ad77b716-c871-4e94-bb53-cef5ed244551]
Planning failed. Terraform encountered an error while generating this plan.
╷
│ Warning: Deprecated
│
│ with data.datadog_application_key.foo,
│ on main.tf line 24, in data "datadog_application_key" "foo":
│ 24: data "datadog_application_key" "foo" {
│
│ The datadog_application_key data source is deprecated and will be removed in a future release with prior notice. Securely store your application key using a secret management
│ system or use the datadog_application_key resource to manage application keys in your Datadog account.
│
│ (and one more similar warning elsewhere)
╵
╷
│ Error: Deprecated
│
│ with data.datadog_application_key.foo,
│ on main.tf line 24, in data "datadog_application_key" "foo":
│ 24: data "datadog_application_key" "foo" {
│
│ The datadog_application_key data source is deprecated and will be removed in a future release. Securely store your application key using a secret management system or use the
│ datadog_application_key resource to manage application keys in your Datadog account.
This also is printed for terraform refresh and terraform apply.
Testing note:
If in the future we stop returning the key field, then the integration tests will start failing. This is okay because at that point the data source is no longer functional and the tests can be removed.
Note:
We are not going to simply preserve pre-existing data sources by not overwriting the key value like for the resource here.
Right now, if you configure a data source based on the name, then it reads the current state from that name and overwrites key and UUID. In other words, it's always up to date with Datadog.
This means if you delete an app key that is already configured as a data source, and then create a new one with the same name, you'll get the new app key UUID and key.
If we preserve the original key's raw value, you could get the new UUID but have the old key value. Similarly, if we were to stop updating both UUID and key, then the name also wouldn't match current state. This would cause state drift.
(This is not a problem for imported resources because those import based solely on UUID, and name can still be read on future refreshes even without the key field)
Add new deprecation message to datadog_application_key data source.
Followed these guidelines: https://developer.hashicorp.com/terraform/plugin/framework/deprecations#provider-data-source-or-resource-removal
Tested locally.
Warning when deprecated data source is used:
This also is printed for
terraform refreshandterraform apply. On eitherrefreshorapplythe key is still stored in Terraform state.Error when deprecated source is used and application key is not provided from the datadog API:
This also is printed for
terraform refreshandterraform apply.Testing note:
If in the future we stop returning the
keyfield, then the integration tests will start failing. This is okay because at that point the data source is no longer functional and the tests can be removed.Note:
We are not going to simply preserve pre-existing data sources by not overwriting the key value like for the resource here.
Right now, if you configure a data source based on the name, then it reads the current state from that name and overwrites key and UUID. In other words, it's always up to date with Datadog.
This means if you delete an app key that is already configured as a data source, and then create a new one with the same name, you'll get the new app key UUID and key.
If we preserve the original key's raw value, you could get the new UUID but have the old key value. Similarly, if we were to stop updating both UUID and key, then the name also wouldn't match current state. This would cause state drift.
(This is not a problem for imported resources because those import based solely on UUID, and name can still be read on future refreshes even without the key field)