chore: Refactoring cloud provider initialization to merge v1 and v2 driver implementations.

[landreasyan]

What type of PR is this?
Currently, v1 and v2 drivers have separate implementation for initializing the cloud provider. This PR is to refactor and merge these differences in order to eliminate any duplicate code.

What this PR does / why we need it:

Which issue(s) this PR fixes:

Fixes #

Requirements:

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

Special notes for your reviewer:

Release note:

none

[k8s-ci-robot]

Hi @landreasyan. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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/test-infra repository.

[andyzhangx]

/ok-to-test

[andyzhangx]

this func is changing the original behavior, any reason why change this?

azuredisk-csi-driver/pkg/azureutils/azure_disk_utils.go

Lines 445 to 461 in 36b2a9a

	func getKubeClient(kubeconfig string) (*kubernetes.Clientset, error) {
	var (
	config *rest.Config
	err error
	)
	if kubeconfig != "" {
	if config, err = clientcmd.BuildConfigFromFlags("", kubeconfig); err != nil {
	return nil, err
	}
	} else {
	if config, err = rest.InClusterConfig(); err != nil {
	return nil, err
	}
	}
	return kubernetes.NewForConfig(config)
	}

[landreasyan]

I am trying to merge the behaviors we had in the v1 and v2 drivers. The recommended approach is to read the in cluster config and then fall back to kubeconfig if it fails. The behavior is essentially the same in the old implementation as well. Was there a reason to prioritize kubeconfig over the in cluster one?

[edreed]

If kubeConfig is not empty, it means that it was specified on the command line. In this case, it should probably take precedence here.

[landreasyan]

But if we are running inside a cluster and our driver runs inside a pod, is there a scenario we where we would prefer the kubeconfig rather than the in-cluster config? From what I understand, the kubeconfig is mostly important for testing when the suite does not actually run inside a pod.

[andyzhangx]

if kubeconfig is set by user, it must be honored first:

azuredisk-csi-driver/pkg/azurediskplugin/main.go

Line 44 in c1e5839

kubeconfig = flag.String("kubeconfig", "", "Absolute path to the kubeconfig file. Required only when running out of cluster.")

[landreasyan]

I have reverted the changes to the getter and kept the old logic.

[andyzhangx]

return GetCloudProviderFromClient(kubeClient, secretName, secretNamespace, userAgent)

[edreed]

/lgtm

[andyzhangx]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andyzhangx, landreasyan

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

The pull request process is described here

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