[WIP] feat: support privateDNSZoneName parameter in storage class

[andyzhangx]

What type of PR is this?
/kind feature

What this PR does / why we need it:
feat: support privateDNSZoneName parameter in storage class

Which issue(s) this PR fixes:

Fixes #2845

Requirements:

• uses conventional commit messages
• includes documentation
• adds unit tests
• tested upgrade from previous version

Special notes for your reviewer:

Release note:

feat: support privateDNSZoneName parameter in storage class

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andyzhangx

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [andyzhangx]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Copilot]

Pull Request Overview

This PR adds support for the privateDNSZoneName parameter in storage class configurations for the Azure File CSI driver. This parameter allows users to specify a custom private DNS zone name when creating storage accounts with private endpoints.

Key Changes

• Added privateDNSZoneName parameter support in storage class with validation that it can only be used with private endpoints
• Default value of "privatelink" is set when private endpoints are enabled but no custom name is provided
• Added unit test for validation logic and updated e2e tests to include the new parameter

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
pkg/azurefile/azurefile.go	Added constant definition for privateDNSZoneNameField
pkg/azurefile/controllerserver.go	Implemented parameter parsing, validation logic, and default value assignment
pkg/azurefile/controllerserver_test.go	Added unit test for validation when privateDNSZoneName is used without private endpoint
test/e2e/dynamic_provisioning_test.go	Added privateDNSZoneName parameter to e2e test cases
pkg/azurefile/azure_test.go	Added duplicate test case and formatting changes

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[k8s-ci-robot]

@andyzhangx: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-azurefile-csi-driver-e2e-capz-windows-2022-hostprocess	535b6c2	link	true	/test pull-azurefile-csi-driver-e2e-capz-windows-2022-hostprocess
pull-azurefile-csi-driver-e2e-capz-windows-2019-hostprocess	535b6c2	link	true	/test pull-azurefile-csi-driver-e2e-capz-windows-2019-hostprocess
pull-azurefile-csi-driver-e2e-capz	535b6c2	link	true	/test pull-azurefile-csi-driver-e2e-capz

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[kmj251]

I'm not sure that this addresses the GitHub Issue. As was noted in the issue, it would be helpful to provide values to a variable or combination of variables that allow us to dictate where a pre-existing private DNS zone (i.e. privatelink.file.core.windows.net) is already created. An easy solution would be to provide a variable like privateDNSZoneResourceID. We would pass in a value like: /subscriptions/<subscription_id>/resourceGroups/<resource_group_name>/providers/Microsoft.Network/privateDnsZones/privatelink.file.core.windows.net for that pre-created/centralized Private DNS Zone. When that variable is specified, the driver should not automatically create the private DNS zone and tie the private endpoint to the pre-existing private DNS zone.

[Sokratis1904]

Any updates on that issue?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all PRs.

This bot triages PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the PR is closed

You can:

• Mark this PR as fresh with /remove-lifecycle stale
• Close this PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-ci-robot]

PR needs rebase.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.