TPT-4130: Feature/dbaas valkey integration

[anmsharm1]

📝 Description

- TPT-4130
This change set adds full Valkey database support to the Linode API client and covers it end-to-end with unit and integration tests.

It was developed and staged originally across four related PRs:

1. Shared database data model update for available_restore_times
2. Core Valkey database types and serialization support
3. Valkey client methods and shared engine/status handling
4. Integration coverage for Valkey lifecycle and config catalog operations

This PR adds support for available_restore_times on the shared Database model, Valkey database response deserialization, Valkey create/update option models, client methods for list/get/create/update/delete, SSL, credentials, patch, suspend/resume and advanced config.

• The shared engine mapping and database status polling support for Valkey has also been updated.
• Integration tests covering Valkey lifecycle management and configuration metadata have been added.

This follows the existing database patterns used by MySQL/PostgreSQL and ensures Valkey behaves consistently within the shared client surface.

✔️ How to Test

Here are some notes I took for doing my local development environment setup for linodego development:
linodego developer setup

What are the steps to reproduce the issue or verify the changes?
The test suite helps validate:

• available_restore_times deserializes correctly for both Valkey and PostgreSQL response shapes
• Valkey database objects deserialize correctly, including nullable fields and engine config metadata
• Valkey create/update requests serialize correctly
• Valkey client endpoints work for database lifecycle operations
• Valkey config catalog metadata is retrieved and validated
• Status polling and lifecycle flows behave as expected for Valkey databases

How do I run the relevant unit/integration tests?

Unit tests

cd test
go test ./unit/... -run '^Test(UnmarshalDatabase|UnmarshalValkeyDatabase|MarshalValkey|ListDatabaseValkey|DatabaseValkey|Valkey)' -v
go test ./unit/...

Integration tests

Linodego’s integration tests can exercise the real API against a live Linode account, using the same client code that users call in production. They typically create or mutate real database resources, wait for the resource to reach the expected state, assert on the returned fields and lifecycle behavior, and then clean up so the tests validate end-to-end behavior rather than just mocked JSON parsing.

To trigger the live tests, a LINODE_TOKEN should be set an env var,

cd test
LINODE_TOKEN=your_token ENABLE_CLOUD_FW=false go test ./integration/... -run '^TestDatabase(_Valkey_Suite|Valkey_EngineConfig_Get)$' -v

[Copilot]

Copilot review overview

🟡 Changes recommended

Two moderate issues remain in valkey.go involving ClusterSize serialization and discarded oldest_restore_time data.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 2

Open (2)

• Parse and expose Valkey oldest_restore_time metadata · New
• Make ClusterSize nil-able or remove omitzero · New

What changed in this PR

Adds end-to-end Valkey Managed Database support, including API operations, lifecycle polling, configuration handling, and tests.

Changes:

• Adds Valkey models, serialization, CRUD, lifecycle, SSL, credentials, patch, and configuration APIs.
• Extends shared engine and restore-time support.
• Adds unit, integration, and fixture coverage.

File	Description
waitfor.go	Valkey status polling
valkey.go	Valkey models and API methods
test/​unit/​valkey_test.go	Valkey unit tests
test/​unit/​fixtures/​valkey_databases_list.json	Valkey list fixture
test/​unit/​fixtures/​valkey_database_update.json	Valkey update fixture
test/​unit/​fixtures/​valkey_database_unmarshal.json	Valkey unmarshal fixture
test/​unit/​fixtures/​valkey_database_unmarshal_engine_config.json	Engine configuration fixture
test/​unit/​fixtures/​valkey_database_ssl_get.json	SSL response fixture
test/​unit/​fixtures/​valkey_database_get.json	Database response fixture
test/​unit/​fixtures/​valkey_database_credentials_get.json	Credentials fixture
test/​unit/​fixtures/​valkey_database_create.json	Create response fixture
test/​unit/​fixtures/​valkey_database_config_get.json	Configuration fixture
test/​unit/​fixtures/​database_unmarshal.json	Shared database fixture
test/​unit/​fixtures/​database_unmarshal_oldest_restore_time.json	Restore-time fixture
test/​unit/​database_test.go	Shared restore-time tests
test/​integration/​valkey_test.go	Valkey lifecycle tests
test/​integration/​valkey_db_config_test.go	Configuration catalog tests
test/​integration/​fixtures/​TestDatabaseValkey_EngineConfig_Get.yaml	Integration replay fixture
databases.go	Shared Valkey and restore-time support
.ci-trigger	CI trigger marker

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Copilot review overview

🟡 Changes recommended

Unresolved moderate issues affect database response parsing and Valkey request serialization.

Get a fresh assessment by requesting another Copilot review.

Review effort: Lite
Findings: 3 · 1

Open (4)

• Make optional update scalars pointer types · New
• Make ClusterSize nil-able or remove omitzero
• Parse and expose Valkey oldest_restore_time metadata
• Fix tautological Valkey engine assertion · New

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[ezilber-akamai]

Can this be changed back to json:"-"? RestoreTime is unmarshaled explicitly in UnmarshalJSON, so it should be excluded from the default JSON unmarshaling.

[anmsharm1]

I'd added this as part of this commit. Users can provide an explicit restore time for the fork-to-restore path for point-in-time-recovery supporting database engines. To clarify the semantics, would reverting to - make json.Marshal to omit the field for engines like Valkey, so on the marshalling path the user reading this response may not identify what restore time was used?

[ezilber-akamai]

Yes, reverting to - would indeed omit this field from json.Marshal. I noticed that fork is no longer listed as a parameter in the API docs for creating MySQL, PostgreSQL, or Valkey databases. Do you know if this is intentional?

If fork is still meant to be a settable field during database creation, then I agree that changing it from - to restore_time makes sense.