Description of problem: The API allows you to create vmimport CRs with duplicated targetVmName. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1.Deploy 2 identical vmimport that has different CR name Actual results: The 2nd vmimport is created successfully The 2nd vmimport CR may receive vm status message that belongs to the 1st vmimport. Expected results: no 2 vmimports with the same namespace and targetVmName should NOT be allowed to be created. Additional info:
Note: It will also be nice if the operator can rejects "targetVmName" if we already have a vm with that name ?
That is the intention to check target vm name conflicts.
This issue is relevant for both sources RHV/VMware Tested with CNV 2.5.0
https://github.com/kubevirt/vm-import-operator/pull/450
*** Bug 1885124 has been marked as a duplicate of this bug. ***
Verified on Tested om OCP-4.6/CNV hco-v2.5.3-64 by running twice same vm import create. On the 2nd run got: "Error from server (AlreadyExists): error when creating "STDIN": virtualmachineimports.v2v.kubevirt.io "vmware-import-1" already exists"
The verification in comment #6 was wrong, because it tested using same vm import CR name, while bug fixes using same targetVmName. Verified on OCP-4.6/CNV hco-v2.5.3-64 using same VM import CR twice, with different CR name. The 2nd VM import did not get the first VM import "successful" status. It failed as expected on: status: conditions: - lastHeartbeatTime: "2021-01-05T10:37:36Z" lastTransitionTime: "2021-01-05T10:36:24Z" message: Virtual machine already exists in target namespace reason: DuplicateTargetVMName status: "False" type: Valid targetVmName: "" warmImport: consecutiveFailures: 0 failures: 0 successes: 0 @Sam, This bug still exists on CNV-2.6.0 - Is this expected please?
The CNV 2.6.0-452 build should have the fix.
Moving bug to Verified since it moved to Assigned in comment #7 by mistake.