Add port-forward functionalities to virtctl vmexport

[alromeros]

What this PR does / why we need it:

VirtualMachineExport volumes are only downloadable outside the cluster when proper ingress or routes are configured.

In some cases, it's helpful to force a way to download the volumes without this configuration, so this pull request introduces an option to set port-forwarding using the vmexport service so that we can get the vmexport contents outside the cluster without additional configuration.

Usage examples:

# To download the contents of pvc-test into disk.img.gz through a random available local port
$ virtctl vmexport download vm1-export --pvc=pvc-test --output=disk.img.gz --port-forward

# To download the contents of pvc-test into disk.img.gz through the local port 4342
$ virtctl vmexport download vm1-export --pvc=pvc-test --output=disk.img.gz --port-forward --local-port=4342

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

Special notes for your reviewer:

Release note:

Add port-forward functionalities to vmexport

[alromeros]

/retest-required

[alromeros]

/test pull-kubevirt-e2e-k8s-1.25-sig-compute-migrations

[awels]

looks good, just a few nitpicks

[awels]

/lgtm

[alromeros]

/retest-required

[alromeros]

/retest

[mhenriks]

@alromeros looks good but wondering why user must supply a port number? Can't one be chosen randomly or just listen on "127.0.0.1:0" and check the returned listener address?

[alromeros]

@alromeros looks good but wondering why user must supply a port number? Can't one be chosen randomly or just listen on "127.0.0.1:0" and check the returned listener address?

I assumed it was simply better to allow users to specify the port number. I can change it, but other than being less straightforward the current implementation seems more robust to me. wdyt? If you want I can make the port random.

[mhenriks]

@alromeros looks good but wondering why user must supply a port number? Can't one be chosen randomly or just listen on "127.0.0.1:0" and check the returned listener address?

I assumed it was simply better to allow users to specify the port number. I can change it, but other than being less straightforward the current implementation seems more robust to me. wdyt? If you want I can make the port random.

I think that the user shouldn't have to care about the port since the tunnel is transient and only exists during command execution. I am not against giving the user an option to explicitly specify the port though

[alromeros]

@alromeros looks good but wondering why user must supply a port number? Can't one be chosen randomly or just listen on "127.0.0.1:0" and check the returned listener address?

I assumed it was simply better to allow users to specify the port number. I can change it, but other than being less straightforward the current implementation seems more robust to me. wdyt? If you want I can make the port random.

I think that the user shouldn't have to care about the port since the tunnel is transient and only exists during command execution. I am not against giving the user an option to explicitly specify the port though

Okay, in that case, I will change the port-forward flag to be a bool and add a new one called target-port so users can specify an optional port.

[alromeros]

/test pull-kubevirt-e2e-k8s-1.27-sig-compute-migrations

[alromeros]

/test pull-kubevirt-e2e-k8s-1.27-sig-compute-migrations

[mhenriks]

/lgtm
/approve

Great job! Should update the PR description to reflect new args/usage

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mhenriks

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 [mhenriks]

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