buildStep Clone: expose all options of cloneOrDeployVm() method, allow to use namedSnapshot and extraConfigParameters

[jimklimov]

The VSphere.cloneOrDeployVm() method is wrapped by cloneVm() (used for a Clone step) and deployVm() (used for a Deploy step).

These wrappers set up null-ness of namedSnapshot string and extraConfigParameters map, and fiddle with false or true value of useCurrentSnapshot; however the builders/... step classes seem to be more considerably different by logic and purpose.

The "Clone" related classes/methods seem to hard-code use of a snapshot (and "Deploy" classes/methods conversely seem to use the current state of the VM).

This PR extends the exposed "Clone" buildStep class (of vSphere step) with an ability for the caller to optionally provide the namedSnapshot and the other two fields to fully customize the created clone. Caused by a practical need to spawn some VMs from an older snapshot of the template :)

The expectation is that by default it would behave as it did before.

SIDE NOTE: mvn package seems to fail with Java 17 during test initialization, but works with JDK of Java 8. Also happens on master branch, and per https://stackoverflow.com/questions/68974753/unable-to-make-field-private-final-java-util-comparator-java-util-treemap-compar seems to be due to Cucumber evolution.

For "legacy"/freestyle jobs, I did extend jelly markup partially, to include the new fields, but would welcome further iterations from someone more knowledgeable about it to:

• pass the extraConfigParameters map (dynamic table of two columns for adding the key/value pairs?);
• not sure if special effort should be done to juggle linkedClone option vs. presence or absence of EITHER ONE OR NONE of namedSnapshot or useCurrentSnapshot settings (they are still optional, although useCurrentSnapshot is implied for linked clones if a named snapshot is not requested).
• however, for least surprise it would be helpful to pre-set useCurrentSnapshot checkbox especially if linkedClone is not set (default) so the "Clone" step behaves as it did before - unless told otherwise. Is there a tri-state checkbox to facilitate a Boolean null value?

Looking at earlier PR reviews like #103 I am also concerned if it is a good idea to change the Clone class constructor, or to keep it as it was and introduce non-final properties and @DataBoundSetter methods instead? Got no opinion on that. All I can say is nothing blew up in the limited local dev-testing :)

Testing done

Did not test "legacy"/freestyle jobs much - just the appearance of the fields for the interactive build step setup in Web-UI. Could not really test the sanity-checker nor the resulting job, it complained a lot about the "cluster" and "resource pool" to use, something it auto-detects with a pipeline step. Also not sure if it did consider the added field checks at all, did not complain about any combos. The original code seems broken, e.g. asks for a serverName but does not set one in jelly...

For practical purposes, on a fresh Jenkins added this plugin (custom build) and created the credential for vCenter, a cloud, and a scripted pipeline to play with, similar to the following:

pipeline {
    agent any
    stages {
        stage("CloudPlay") {
            steps {
                script {
                    vSphere(
                    	buildStep: [
                    		$class     : 'PowerOff',
                    		vm         : 'kube0',
                    		shutdownGracefully : false,
                    		ignoreIfNotExists : true
                    	], serverName: 'myVcenter'
                    )

                    vSphere(
                    	buildStep: [
                    		$class     : 'Delete',
                    		failOnNoExist : false,
                    		vm         : 'kube0',
                    	], serverName: 'myVcenter'
                    )

                    vSphere(
                    	buildStep: [
                    		$class     : 'Clone',
                    		clone      : 'kube0',
                    		powerOn    : true,
                    		sourceName : 'linux-kube-template',
                    		linkedClone: true,
                    		namedSnapshot : 'before K8s install'
                    	], serverName: 'myVcenter'
                    )
                }
            }
        }
    }
}

...and fiddled with parameters for the latter part.

• When neither namedSnapshot nor useCurrentSnapshot is specified, it uses the newest snapshot (as expected per legacy behavior) for "deep" or "shallow" clones (depending on linkedClone presence/value):

[vSphere] Creating a deep clone of "linux-kube-template" to "kube0"
[vSphere] Clone of VM "linux-kube-template" will be based on current snapshot "VirtualMachineSnapshot:snapshot-527471 @ https://myVcenter/sdk".
[vSphere] Started cloning of VM "linux-kube-template". Please wait ...
[vSphere] Successfully cloned VM "linux-kube-template" to create "kube0".

[vSphere] Creating a shallow clone of "linux-kube-template" to "kube0"
[vSphere] Clone of VM "linux-kube-template" will be based on current snapshot "VirtualMachineSnapshot:snapshot-527471 @ https://myVcenter/sdk".
[vSphere] Started cloning of VM "linux-kube-template". Please wait ...
[vSphere] Successfully cloned VM "linux-kube-template" to create "kube0".
[vSphere] "kube0" successfully cloned !

• When useCurrentSnapshot=false is explicit (and no namedSnapshot is passed), it seems to copy the current state of the (template) source VM (UPDATE: Also tested successfully with a source VM that had no snapshots):

[vSphere] Deploying new vm "kube0" from template "linux-kube-template"
[vSphere] Started cloning of VM "linux-kube-template". Please wait ...
[vSphere] Successfully cloned VM "linux-kube-template" to create "kube0".

• When both useCurrentSnapshot=true is explicit and a namedSnapshot is passed, it fails (as expected):

ERROR: It is not valid to request a clone of VM  "linux-kube-template" based on its snapshot "before K8s install" AND also specify that the latest snapshot should be used.  Either choose to use the latest snapshot, or name a snapshot, or neither, but not both.

• When both useCurrentSnapshot=false and linkedClone=true (and no namedSnapshot is passed), it fails (as expected):

ERROR: vSphere Error: Couldn't clone "linux-kube-template". Clone task ended with status error.
A specified parameter was not correct: spec.snapshot

### Submitter checklist
- [x] Make sure you are opening from a **topic/feature/bugfix branch** (right side) and not your main branch!
- [x] Ensure that the pull request title represents the desired changelog entry
- [x] Please describe what you did
- [ ] Link to relevant issues in GitHub or Jira
- [ ] Link to relevant pull requests, esp. upstream and downstream changes
- [ ] Ensure you have provided tests - that demonstrates feature works or fixes the issue

[jimklimov]

Note: I could not fully check passing extraConfigParameters due to lack of permissions on the hypervisor, I suppose. However, it did try:

                    vSphere(
                    	buildStep: [
                    		$class     : 'Clone',
                    		clone      : 'kube0',
                    		powerOn    : false,
                    		sourceName : 'linux-kube-template',
                    		//useCurrentSnapshot: false,
                    		//namedSnapshot : 'before K8s install'
                    		linkedClone: true,
                    		extraConfigParameters: [
                    		    'guestinfo.Foo': 'BAR'
                    		    ]
                    	], serverName: 'myVcenter'

# OUTPUT:
[vSphere] Clone of VM "linux-kube-template" will be based on current snapshot "VirtualMachineSnapshot:snapshot-527471 @ https://myVcenter/sdk".
[vSphere] Clone of VM "linux-kube-template" will have extra configuration parameters {guestinfo.Foo=BAR}.
ERROR: com.vmware.vim25.NoPermission: Permission to perform this operation was denied.

[pjdarton]

I don't know if there's anyone else (other than me) still on the @jenkinsci/vsphere-cloud-plugin-developers list (specified by the CODEOWNERS file) and thus receiving notifications about review requests.
FYI I stopped maintaining this plugin (and flagged it as "in need of adoption") after I stopping having a VMWare platform to test things on (and my work has mostly stopped using Jenkins too).

I would suggest that you ask more widely for a code review, e.g. on the Jenkins groups.

... but if you're using this plugin enough to want to contribute, I'd suggest you become the new maintainer - it'll give you the freedom to enhance the plugin however you wish.
It'll also mean you'll be able to push out new versions of the plugin, which will then make it easier to get your changes onto your Jenkins instance. It looks like the process is now more streamlined than it used to be too.

FYI that's how I got involved - I wanted a change made (to improve Windows support, mostly), didn't want to have to build and maintain a private copy, so I wrote a PR ... and then another ... and then I got involved in another plugin etc - it's all open-source software, so if you want to, you can make it work exactly how you want it to 😁