I'm requesting improvements of this provider based on my experience:
1. Severely Outdated Dependencies
The go.mod pins Go 1.16 (released Feb 2021) and terraform-plugin-sdk v2.6.1 (2021-era). These are years behind current versions and carry known security vulnerabilities in transitive dependencies (e.g., golang.org/x/net, google.golang.org/grpc).
2. No Acceptance or Unit Tests for Resources
The only tests cover the internal rate-limiting (apimutex_test.go, governed_transport_test.go). There are zero acceptance tests for any of the 14 resources or 15 data sources. The testacc Makefile target exists but there are no test files to run. This means regressions go undetected.
3. Missing 404 Handling in Read Functions (Configuration Drift)
The Read functions (e.g., getDeviceById) do not check for 404 responses and call d.SetId("") to signal resource removal. This is a Terraform best practice and its absence causes terraform plan/apply to crash when a resource is deleted outside Terraform — confirmed by open issue #133.
4. api_key Not Marked Sensitive
The api_key provider attribute lacks Sensitive: true, meaning it appears in plaintext in logs and plan output. This is a security risk.
5. Auto-Generated Code with No Customization Layer
Resource files are generated by go-swagger (noted in headers like device_resource.go), and schemata files are similarly generated. The generated code has issues:
Query parameters like end, start, netflow_filter are exposed as Terraform resource attributes — these are API query parameters, not resource properties.
The d.Partial(true) call in updateDevice is a no-op in SDK v2 (deprecated in v1, removed in v2).
Empty HasChange loops that build a props list but never use it for partial updates.
6. Configuration Drift Issues
Multiple open issues (#85, #92, #53) report configuration drift. The custom_properties handling uses ordered lists instead of TypeSet, causing spurious diffs when the API returns properties in a different order.
7. Vendored Dependencies
The repo checks in a full vendor/ directory, which bloats the repository (13.5 MB) and makes dependency auditing harder. Modern Go projects use module proxy caching instead.
8. Stale CI Configuration
A .travis.yml file is present, but Travis CI has largely been superseded. The .github/ directory suggests some GitHub Actions may exist, but the CI story is unclear.
9. Schema versioning is not used
The provider does not use SchemaVersion or StateUpgraders on any of its resources. Every resource returns a bare schema.Resource
This means any future schema changes (e.g., renaming attributes, changing types, restructuring nested blocks) will break existing state files with no migration path. Users would be forced to manually edit state or destroy/recreate resources.
8. CI check
Implement proper CI: e.g. formatting checks, tests, ...
Can product manager comment this ticket here, please? So community will have ideas what are priorities of these improvements (when community pull requests are not accepted) and expected date for each improvement.
Thank you
I'm requesting improvements of this provider based on my experience:
1. Severely Outdated Dependencies
The go.mod pins Go 1.16 (released Feb 2021) and terraform-plugin-sdk v2.6.1 (2021-era). These are years behind current versions and carry known security vulnerabilities in transitive dependencies (e.g., golang.org/x/net, google.golang.org/grpc).
2. No Acceptance or Unit Tests for Resources
The only tests cover the internal rate-limiting (apimutex_test.go, governed_transport_test.go). There are zero acceptance tests for any of the 14 resources or 15 data sources. The testacc Makefile target exists but there are no test files to run. This means regressions go undetected.
3. Missing 404 Handling in Read Functions (Configuration Drift)
The Read functions (e.g., getDeviceById) do not check for 404 responses and call d.SetId("") to signal resource removal. This is a Terraform best practice and its absence causes terraform plan/apply to crash when a resource is deleted outside Terraform — confirmed by open issue #133.
4. api_key Not Marked Sensitive
The api_key provider attribute lacks Sensitive: true, meaning it appears in plaintext in logs and plan output. This is a security risk.
5. Auto-Generated Code with No Customization Layer
Resource files are generated by go-swagger (noted in headers like device_resource.go), and schemata files are similarly generated. The generated code has issues:
6. Configuration Drift Issues
Multiple open issues (#85, #92, #53) report configuration drift. The custom_properties handling uses ordered lists instead of TypeSet, causing spurious diffs when the API returns properties in a different order.
7. Vendored Dependencies
The repo checks in a full vendor/ directory, which bloats the repository (13.5 MB) and makes dependency auditing harder. Modern Go projects use module proxy caching instead.
8. Stale CI Configuration
A .travis.yml file is present, but Travis CI has largely been superseded. The .github/ directory suggests some GitHub Actions may exist, but the CI story is unclear.
9. Schema versioning is not used
The provider does not use SchemaVersion or StateUpgraders on any of its resources. Every resource returns a bare schema.Resource
This means any future schema changes (e.g., renaming attributes, changing types, restructuring nested blocks) will break existing state files with no migration path. Users would be forced to manually edit state or destroy/recreate resources.
8. CI check
Implement proper CI: e.g. formatting checks, tests, ...
Can product manager comment this ticket here, please? So community will have ideas what are priorities of these improvements (when community pull requests are not accepted) and expected date for each improvement.
Thank you