|
| 1 | +## ADDED Requirements |
| 2 | + |
| 3 | +### Requirement: MongoDB Instance CPU Parameter |
| 4 | +The `tencentcloud_mongodb_instance` resource SHALL provide a `cpu` schema field to manage the instance CPU core count, allowing users to change the CPU specification of a running MongoDB instance through in-place update via the `ModifyDBInstanceSpec` API. |
| 5 | + |
| 6 | +#### Scenario: Schema defines optional and computed cpu field |
| 7 | +- **GIVEN** the `tencentcloud_mongodb_instance` resource schema definition |
| 8 | +- **THEN** `cpu` SHALL be a field of type `schema.TypeInt` |
| 9 | +- **AND** `cpu` SHALL have `Optional: true` and `Computed: true` |
| 10 | +- **AND** `cpu` SHALL NOT have `ForceNew` set (changes are applied via in-place update) |
| 11 | +- **AND** the field description SHALL document that the unit is C and that the supported CPU specifications can be obtained via the `DescribeSpecInfo` API |
| 12 | + |
| 13 | +#### Scenario: Update triggers ModifyDBInstanceSpec when cpu changes |
| 14 | +- **GIVEN** an existing `tencentcloud_mongodb_instance` resource |
| 15 | +- **WHEN** the user updates only the `cpu` field (without changing `memory`, `volume`, or `node_num`) |
| 16 | +- **THEN** the system SHALL detect `d.HasChange("cpu")` and enter the spec-modification branch |
| 17 | +- **AND** the system SHALL read the current `cpu` value from the schema |
| 18 | +- **AND** the system SHALL pass `cpu` into the params map of `MongodbService.UpgradeInstance` |
| 19 | +- **AND** the system SHALL call the `ModifyDBInstanceSpec` API with the `Cpu` request field set to the new CPU value |
| 20 | +- **AND** the system SHALL poll the returned deal id via `DescribeDBInstanceDeal` until the deal succeeds (when `in_maintenance == 0`) |
| 21 | +- **AND** the resource state SHALL be updated after a successful modification |
| 22 | + |
| 23 | +#### Scenario: Update triggers ModifyDBInstanceSpec when cpu changes together with other spec params |
| 24 | +- **GIVEN** an existing `tencentcloud_mongodb_instance` resource |
| 25 | +- **WHEN** the user updates `cpu` together with `memory`, `volume`, or `node_num` |
| 26 | +- **THEN** the system SHALL include the `cpu` value alongside the other changed spec parameters in a single `ModifyDBInstanceSpec` call |
| 27 | +- **AND** the `Cpu` request field SHALL be set from the user-specified `cpu` value |
| 28 | + |
| 29 | +#### Scenario: cpu omitted in update keeps existing behavior |
| 30 | +- **GIVEN** an existing `tencentcloud_mongodb_instance` resource where `cpu` was not configured |
| 31 | +- **WHEN** the user updates fields unrelated to spec modification (e.g., tags, project_id) |
| 32 | +- **THEN** the system SHALL NOT call `ModifyDBInstanceSpec` |
| 33 | +- **AND** the `cpu` field SHALL remain unset in the schema (populated only via Read) |
| 34 | + |
| 35 | +#### Scenario: Service layer maps cpu to ModifyDBInstanceSpecRequest.Cpu |
| 36 | +- **GIVEN** the `MongodbService.UpgradeInstance` service method |
| 37 | +- **WHEN** `params["cpu"]` is present with an integer value |
| 38 | +- **THEN** the system SHALL set `request.Cpu` to a `*int64` pointer constructed from the integer value |
| 39 | +- **AND** the type conversion SHALL use the `int64` helper matching the `ModifyDBInstanceSpecRequest.Cpu` field type |
| 40 | +- **WHEN** `params["cpu"]` is not present |
| 41 | +- **THEN** the system SHALL leave `request.Cpu` unset (nil) so the cloud API defaults to the current CPU size |
| 42 | + |
| 43 | +### Requirement: MongoDB Instance CPU Read Backfill |
| 44 | +The resource Read operation SHALL populate the `cpu` field from the cloud API response so that Terraform state reflects the actual CPU core count of the instance. |
| 45 | + |
| 46 | +#### Scenario: Read populates cpu from DescribeDBInstances |
| 47 | +- **GIVEN** an existing `tencentcloud_mongodb_instance` resource |
| 48 | +- **WHEN** the Read operation queries the instance via `DescribeDBInstances` (through `DescribeInstanceById`) |
| 49 | +- **AND** the returned `InstanceDetail.CpuNum` is not nil |
| 50 | +- **THEN** the system SHALL set the `cpu` field in state to `int(*instance.CpuNum)` |
| 51 | + |
| 52 | +#### Scenario: Read handles nil CpuNum gracefully |
| 53 | +- **GIVEN** an existing `tencentcloud_mongodb_instance` resource |
| 54 | +- **WHEN** the Read operation queries the instance |
| 55 | +- **AND** the returned `InstanceDetail.CpuNum` is nil |
| 56 | +- **THEN** the system SHALL NOT call `d.Set("cpu", ...)` (skip setting the field) |
| 57 | +- **AND** the Read operation SHALL NOT fail solely because `CpuNum` is nil |
| 58 | + |
| 59 | +#### Scenario: CpuNum not added to mandatory nil check |
| 60 | +- **GIVEN** the Read operation's `CheckNil` validation list |
| 61 | +- **THEN** `CpuNum` SHALL NOT be added to the mandatory nil-check map |
| 62 | +- **AND** existing instances that do not return `CpuNum` SHALL still be readable without error |
| 63 | + |
| 64 | +### Requirement: CPU Parameter Testing |
| 65 | +The resource SHALL have unit tests using gomonkey mocks (not Terraform test suites) covering the new `cpu` parameter behavior, runnable via `go test` with `-gcflags=all=-l`. |
| 66 | + |
| 67 | +#### Scenario: Unit test for cpu change triggering spec modification |
| 68 | +- **GIVEN** the `tencentcloud_mongodb_instance` resource update function |
| 69 | +- **WHEN** a unit test simulates a `cpu` change in the schema |
| 70 | +- **THEN** the test SHALL mock the `ModifyDBInstanceSpec` and `DescribeDBInstanceDeal` cloud APIs using gomonkey |
| 71 | +- **AND** verify that the update flow calls `ModifyDBInstanceSpec` with the expected `Cpu` value |
| 72 | +- **AND** verify the update completes without error |
| 73 | + |
| 74 | +#### Scenario: Unit test for cpu read backfill |
| 75 | +- **GIVEN** the `tencentcloud_mongodb_instance` resource read function |
| 76 | +- **WHEN** a unit test mocks `DescribeDBInstances` to return an instance with `CpuNum` set |
| 77 | +- **THEN** the test SHALL verify that `d.Set("cpu", ...)` is called with the correct CPU value |
| 78 | +- **AND** verify the read completes without error |
| 79 | + |
| 80 | +#### Scenario: Unit test for nil CpuNum read |
| 81 | +- **GIVEN** the `tencentcloud_mongodb_instance` resource read function |
| 82 | +- **WHEN** a unit test mocks `DescribeDBInstances` to return an instance with `CpuNum` nil |
| 83 | +- **THEN** the test SHALL verify the read operation does not fail |
| 84 | +- **AND** verify the `cpu` field is not set |
| 85 | + |
| 86 | +### Requirement: CPU Parameter Documentation |
| 87 | +The resource documentation SHALL be updated to describe the new `cpu` parameter, generated via the `make doc` command during the finalize phase. |
| 88 | + |
| 89 | +#### Scenario: cpu field documented |
| 90 | +- **GIVEN** the resource documentation file `resource_tc_mongodb_instance.md` |
| 91 | +- **THEN** the documentation SHALL include the `cpu` parameter description |
| 92 | +- **AND** the description SHALL state the unit is C and that supported specifications can be obtained via the `DescribeSpecInfo` API |
| 93 | +- **AND** the documentation SHALL NOT include manual `Argument Reference` or `Attribute Reference` sections (auto-generated) |
| 94 | + |
| 95 | +#### Scenario: Example usage includes cpu |
| 96 | +- **GIVEN** the resource documentation |
| 97 | +- **THEN** the example usage SHALL demonstrate specifying the `cpu` parameter in an update scenario |
0 commit comments