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

[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.

[anmsharm1]

yes, I verified that in the current API documentation for MySQL, PostgreSQL, and Valkey, Fork restore is supported and each endpoint documents creating or restoring a database, and the OpenAPI request schema has a separate restore branch with a fork object. source is required, while restore_time is optional. It appears the fork fields aren’t shown in the regular create parameter list because create and restore are represented as separate request-body schemas.

The restore_time tag change is intentional. DatabaseFork.UnmarshalJSON parses the timestamp explicitly, but the tag is also needed to marshal it into fork-create requests. this should be covered by new unit test that verifies the request contains fork.restore_time.

[ezilber-akamai]

Thanks for the contribution!

[Copilot]

🟡 Changes recommended

Valkey endpoint data is dropped, null unmarshalling can retain stale values, and recorded fixtures expose account-specific infrastructure.

5 open findings

• Clear restore times when available_restore_times is null · New
• Sanitize unrelated account resources in recorded fixture · New
• Replace routable fixture IP with documentation address · New
• Model Valkey host endpoints in DatabaseHost · New
• Clear Valkey restore times when JSON value is null · New

4 resolved since last review

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

🧠 Review effort: Balanced

[zliang-akamai]

@anmsharm1 Does copilot make sense here? Can you look into this?