[Compute] Add support for Future Capacity Reservations in New- and Get-AzCapacityReservation

[Alex Estevez (AEst2002)]

🤖 PR Validation — 🔄 Running

Tests
🔄 60/60

Description

Please see original cmdlet design here: https://github.com/Azure/azure-powershell-cmdlet-review-pr/issues/1570.
This PR replaces the copilot-generated PR #30011 by adding/fixing on top of it.

• Adds support for schedule profile and minimumCommitmentDays parameters in New-AzCapacityReservation, and ensures the reservationStateInfo and modifiableUntil parameters are displayed when using Get-AzCapacityReservation (with instanceView for state info).
• Test included to create a future reservation with a near and far start date to ensure modifiableUntil is null or non-null, respectively.
• Updates changelog to reflect additions from this PR.

Mandatory Checklist

• Please choose the target release of Azure PowerShell. (⚠️Target release is a different concept from API readiness. Please click below links for details.)

  • General release
  • Public preview
  • Private preview
  • Engineering build
  • No need for a release

• Check this box to confirm: I have read the Submitting Changes section of CONTRIBUTING.md and reviewed the following information:

• SHOULD update ChangeLog.md file(s) appropriately
  • Update src/{{SERVICE}}/{{SERVICE}}/ChangeLog.md.
    • A snippet outlining the change(s) made in the PR should be written under the ## Upcoming Release header in the past tense.
  • Should not change ChangeLog.md if no new release is required, such as fixing test case only.
• SHOULD regenerate markdown help files if there is cmdlet API change. Instruction
• SHOULD have proper test coverage for changes in pull request.
• SHOULD NOT adjust version of module manually in pull request

[Copilot]

🟡 Changes recommended

The cmdlet currently serializes scheduleProfile.start with a full datetime format and lacks required parameter-dependency validation for -MinimumCommitmentDays, which can result in invalid request payloads.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR extends the Az.Compute Capacity Reservation cmdlets to support Future Capacity Reservations by surfacing Schedule Profile fields during create (New-AzCapacityReservation) and on output (Get-AzCapacityReservation), with accompanying help, tests, and changelog updates.

Changes:

• Added -ScheduleProfileStart and -MinimumCommitmentDays parameters to New-AzCapacityReservation and mapped them into the request payload’s scheduleProfile.
• Updated output model (PSCapacityReservation) to expose ScheduleProfile so Get-AzCapacityReservation can display Start, MinimumCommitmentDays, and ModifiableUntil.
• Added a new scenario test for future reservations and updated help + changelog.

File summaries

File	Description
src/Compute/Compute/help/New-AzCapacityReservation.md	Documents new parameters and adds a future reservation example.
src/Compute/Compute/help/Get-AzCapacityReservation.md	Adds an example demonstrating instance view reservation state access.
src/Compute/Compute/Generated/Models/PSCapacityReservation.cs	Exposes ScheduleProfile on the PowerShell output type.
src/Compute/Compute/Generated/CapacityReservation/NewAzCapacityReservationCommand.cs	Adds new parameters and request mapping for schedule profile fields.
src/Compute/Compute/ChangeLog.md	Adds user-facing release note for the new Future Capacity Reservation support.
src/Compute/Compute.Test/ScenarioTests/VirtualMachineTests.ps1	Adds scenario script to validate future reservation behavior and output fields.
src/Compute/Compute.Test/ScenarioTests/VirtualMachineTests.cs	Wires the new scenario script into check-in CI via xUnit.

Review details

Suppressed comments (1)

src/Compute/Compute.Test/ScenarioTests/VirtualMachineTests.ps1:5437

• The new scenario test validates the positive cases, but it doesn't cover the parameter-dependency error case (using -MinimumCommitmentDays without -ScheduleProfileStart). Adding this negative assertion would prevent regressions in the cmdlet-side validation logic.

        # Cleanup
        Clean-ResourceGroup $rgname;
    }
}

• Files reviewed: 5/8 changed files
• Comments generated: 1
• Review effort level: Lite

---

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

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Aditya Pujara (a0x1ab)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[Copilot]

🟡 Changes recommended

The cmdlet currently allows -MinimumCommitmentDays without -ScheduleProfileStart (contradicting the stated behavior) and the new test does not assert the expected dependency error.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 5/8 changed files
• Comments generated: 4
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

Az.Compute CI is failing signature check due to the new plural parameter name (MinimumCommitmentDays) and related call sites/docs need to be aligned with the corrected parameter name.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (3)

src/Compute/Compute/help/New-AzCapacityReservation.md:104

• The parameter header should match the actual cmdlet parameter name after renaming MinimumCommitmentDays to a singular-noun form.

### -MinimumCommitmentDays

src/Compute/Compute.Test/ScenarioTests/VirtualMachineTests.ps1:5568

• The new scenario test uses -MinimumCommitmentDays; update to the renamed singular-noun parameter so the test continues to work after the cmdlet naming fix.

        # Step 3: create a future reservation with both ScheduleProfileStart and MinimumCommitmentDays
        $CRName2 = "cr2" + $rgname;
        $cr2 = New-AzCapacityReservation -ResourceGroupName $rgname -ReservationGroupName $CRGName -Name $CRName2 -Sku $sku2 -CapacityToReserve 4 -Location $loc -Zone $zone -ScheduleProfileStart $start2 -MinimumCommitmentDays 30;
        Assert-AreEqual ([datetime]$start2) ([datetime]$cr2.ScheduleProfile.Start);

src/Compute/Compute/help/New-AzCapacityReservation.md:37

• Example 2 uses -MinimumCommitmentDays; update it to the renamed singular-noun parameter so the example remains copy/pasteable once the CI signature-check issue is fixed.

New-AzCapacityReservation -ResourceGroupName "myRG" -Location "eastus" -ReservationGroupName "myCapacityReservationGroup" -Name "myCapacityReservation" -Sku "Standard_DS1_v2" -CapacityToReserve 10 -Zone "1" -ScheduleProfileStart "2026-12-25" -MinimumCommitmentDays 30

• Files reviewed: 5/8 changed files
• Comments generated: 5
• Review effort level: Lite

[Aditya Pujara (a0x1ab)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[Copilot]

🔵 Needs a closer look

The CI Signature Check is failing due to the plural parameter name MinimumCommitmentDays, which must be corrected to meet enforced cmdlet naming conventions.

Review details

Suppressed comments (2)

Previously missed (1) — in code that hasn't changed since the last review.

src/Compute/Compute/help/Get-AzCapacityReservation.md:42

• CI Help Example Check warnings are still triggered because Example 2 uses $rgname without assigning it. Replace it with a literal (or assign $rgname before the example) so the example is copy/paste friendly and passes validation.

This issue also appears on line 42 of the same file.

src/Compute/Compute/help/Get-AzCapacityReservation.md:42

• CI Help Example Check warnings are still triggered because Example 1 uses $rgname without assigning it. Replace it with a literal (or assign $rgname before the example) so the example is copy/paste friendly and passes validation.

(Get-AzCapacityReservation -ResourceGroupName "myRG" -ReservationGroupName "CRGroup1" -Name "resource1" -InstanceView).InstanceView.ReservationStateInfo.ReservationState

• Files reviewed: 5/8 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Aditya Pujara (a0x1ab)]

/azp run

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).

[Copilot]

🟡 Changes recommended

There are correctness and help-documentation issues (notably DateTimeOffset serialization and help examples) that should be fixed before approval.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 5/8 changed files
• Comments generated: 4
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

CI help example validation still fails due to undefined $rgname in existing examples, and the new schedule start serialization drops offset information (potentially changing request semantics).

Review details

Suppressed comments (3)

src/Compute/Compute/help/Get-AzCapacityReservation.md:45

• Help Example Check warnings: Example 1 uses an undefined variable $rgname for -ResourceGroupName, which causes CI help-example validation to fail. Use a concrete value (as done in Example 3) or define the variable.

### Example 3
```powershell
(Get-AzCapacityReservation -ResourceGroupName "myRG" -ReservationGroupName "CRGroup1" -Name "resource1" -InstanceView).InstanceView.ReservationStateInfo.ReservationState

For a Future Capacity Reservation, this will retrieve the current reservation state from the instance view.

**src/Compute/Compute/help/Get-AzCapacityReservation.md:45**
* Help Example Check warnings: Example 2 uses an undefined variable `$rgname` for `-ResourceGroupName`, which causes CI help-example validation to fail. Use a concrete value (as done in Example 3) or define the variable.

Example 3

(Get-AzCapacityReservation -ResourceGroupName "myRG" -ReservationGroupName "CRGroup1" -Name "resource1" -InstanceView).InstanceView.ReservationStateInfo.ReservationState

For a Future Capacity Reservation, this will retrieve the current reservation state from the instance view.

**src/Compute/Compute/help/New-AzCapacityReservation.md:267**
* The INPUTS section lists `System.DateTime`, but the new `-ScheduleProfileStart` parameter is `System.DateTimeOffset`. This mismatch can confuse users (and tooling that reads these types); update the INPUTS type to `System.DateTimeOffset`.

INPUTS

System.String

System.Int32

System.DateTime

- **Files reviewed:** 5/8 changed files
- **Comments generated:** 0 new
- **Review effort level:** Lite
</details>

[Copilot]

🟡 Changes recommended

It introduces a high-impact NuGet feed change and includes test/changelog updates that are likely to be incorrect or flaky in CI playback.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (2)

src/Compute/Compute.Test/ScenarioTests/VirtualMachineTests.ps1:5573

• Same playback non-determinism issue as above: comparing against $start2 (computed from current date) will not reliably match the recorded response in Playback mode. Guard this date-equality assertion to avoid flaky playback runs.

        $cr2 = New-AzCapacityReservation -ResourceGroupName $rgname -ReservationGroupName $CRGName -Name $CRName2 -Sku $sku2 -CapacityToReserve 4 -Location $loc -Zone $zone -ScheduleProfileStart $start2 -MinimumCommitmentDayCount 30;
        Assert-AreEqual ([datetimeoffset]$start2).Date ([datetimeoffset]$cr2.ScheduleProfile.Start).Date;
        Assert-AreEqual 30 $cr2.ScheduleProfile.MinimumCommitmentDays;

src/Compute/Compute.Test/ScenarioTests/VirtualMachineTests.ps1:5579

• Same playback non-determinism issue as above for the server-side re-read: $cr2 in Playback comes from recordings, so asserting its Start against a newly computed $start2 can fail. Guard this assertion in Playback mode.

        $cr2 = Get-AzCapacityReservation -ResourceGroupName $rgname -ReservationGroupName $CRGName -Name $CRName2;
        Assert-AreEqual ([datetimeoffset]$start2).Date ([datetimeoffset]$cr2.ScheduleProfile.Start).Date;
        Assert-AreEqual 30 $cr2.ScheduleProfile.MinimumCommitmentDays;
        Assert-NotNull $cr2.ScheduleProfile.ModifiableUntil;

• Files reviewed: 7/10 changed files
• Comments generated: 4
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

It includes unrelated repo-wide config changes (NuGet feed and an MCP config file) and a changelog reference that currently points to the wrong issue/PR.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

• Files reviewed: 5/8 changed files
• Comments generated: 1
• Review effort level: Lite

[Aditya Pujara (a0x1ab)]

/azp run

[Copilot]

🔵 Needs a closer look

The new scenario test relies on current-date calculations and offset-sensitive date assertions that can break playback determinism, and the changelog references an unrelated issue number.

Review details

Suppressed comments (5)

Previously missed (2) — in code that hasn't changed since the last review.

src/Compute/Compute.Test/ScenarioTests/VirtualMachineTests.ps1:5565

• The date comparison uses DateTimeOffset.Date, which is sensitive to offsets/time normalization (the service may return midnight UTC expressed in a local offset). Compare expected vs actual in UTC to avoid off-by-one-day failures in some time zones / recordings.

This issue also appears in the following locations of the same file:

• line 5572
• line 5577
  src/Compute/Compute/ChangeLog.md:24

• The changelog reference "[#1570]" links to an unrelated 2016 PR in this repo; also "ComputeRP/DiskRP/GalleryRP" is unclear for end users. Use an explicit repo-qualified reference to the cmdlet design issue and spell out "resource provider (RP)" at first use.

src/Compute/Compute.Test/ScenarioTests/VirtualMachineTests.ps1:5558

• $start1/$start2Date are generated from Get-Date, but the test compares those values to recorded playback responses (and asserts on them). This will become non-deterministic over time and can break playback once the recording date diverges from the current date. Use deterministic values in Playback mode (and only compute relative dates in Record mode).

        # ModifiableUntil is only populated if the start date is 8+ weeks away from today
        $start1 = (Get-Date).AddDays(10).ToString("yyyy-MM-dd");

        # start2 includes an explicit time component and offset, which should also be accepted,
        # though the service will only consider the date when setting the scheduled start
        $start2Date = (Get-Date).AddDays(90).ToString("yyyy-MM-dd");
        $start2 = $start2Date + "T02:30:00+00:00";

src/Compute/Compute.Test/ScenarioTests/VirtualMachineTests.ps1:5572

• For start2, the service may normalize the scheduled start to midnight UTC regardless of the time component in $start2. Use the expected date ($start2Date) and compare against the returned value in UTC to keep the assertion stable.

        Assert-AreEqual ([datetimeoffset]$start2).Date ([datetimeoffset]$cr2.ScheduleProfile.Start).Date;

src/Compute/Compute.Test/ScenarioTests/VirtualMachineTests.ps1:5577

• Same UTC-normalized date comparison issue as above: this assertion can fail if the service returns midnight UTC expressed in a non-UTC offset. Compare using $start2Date and the returned value's UtcDateTime.Date.

        Assert-AreEqual ([datetimeoffset]$start2).Date ([datetimeoffset]$cr2.ScheduleProfile.Start).Date;

• Files reviewed: 5/8 changed files
• Comments generated: 0 new
• Review effort level: Lite

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).