feat: Expand plugin interface GetSegments()

[engedaam]

What type of PR is this?

/kind feature

This change extends the EBS CSI driver plugin interface to support custom node topology segments that can be propagated to Kubernetes resources.

What is this PR about? / Why do we need it?

• Added GetNodeSegments() method to the EbsCsiPlugin interface, allowing plugins to provide additional topology segments
• Introduced SetNodeSegments() and GetNodeSegments() utility functions to manage plugin-provided segments globally
• Updated controller and node services to merge plugin segments with existing topology information (zone, OS, outpost ARN)
• Modified all relevant tests to account for the new segment merging behavior using lo.Assign()

Dependencies:

• Added github.com/samber/lo for convenient map merging operations

How was this change tested?

• make test

Does this PR introduce a user-facing change?

NONE

[github-actions]

Code Coverage Diff

File	Old Coverage	New Coverage	Delta
github.com/kubernetes-sigs/aws-ebs-csi-driver/pkg/driver/node.go	89.5%	88.3%	-1.2
github.com/kubernetes-sigs/aws-ebs-csi-driver/pkg/util/util.go	56.3%	51.3%	-5.1

[engedaam]

/retest

[k8s-ci-robot]

This PR has multiple commits, and the default merge method is: merge.
You can request commits to be squashed using the label: tide/merge-method-squash

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.

[engedaam]

/retest

[torredil]

Requested changes, also make verify is failing and needs to be fixed before merge.

[torredil]

GetNodeSegments() returns an empty map here since nothing calls SetNodeSegments with actual data, so this test passes whether or not the merge works. Can we add a test that sets some segments and checks they show up in the response?

[engedaam]

This is expected. Once a consumer has loaded the test with a plugin the segments will be updated to the correct value. This is how the remaining of the tests have been configured for the plugin

[torredil]

/assign @ConnorJC3

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from connorjc3. For more information see the Code Review Process.

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

Details

Needs approval from an approver in each of these files:

• OWNERS

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

[ConnorJC3]

SetDriverName is an unfortunate anti-pattern we adopted to get ourselves out of a bad situation with how the driver name was handled in a pre-plugin world, but I'd like to avoid expanding on that anti-pattern as it:

• Makes tracing the code path used harder
• Greatly increases the chance of bugs slipping in, for example this one related to SetDriverName: Initialize name-dependent variables in metadata-labaler node path #2827
• Increases the difficulty of testing changes

Because the same constraints that applied to the name don't apply to topology segments, can we just directly call the plugin in node.go and controller.go?

Something like:

plugin := plugin.GetPlugin()
if plugin != nil {
  maps.Copy(segments, plugin.GetTopologySegments())
}

[ConnorJC3]

If we're also going to reuse this in the controller, can we call it something like GetTopologySegments or otherwise not reference Node?