Description of problem: Checking Java SDK with automtion test. The test failed since it try to remove disks from VM and gets number of disks with the same alias(name). In order to reperduce this problem i worte Java code that add disk to exsit VM, and also in this case the disks created with the same alias(name). Test results from Jenkins: 11:50:03 ================================================================================ 11:50:03 2014-11-26 11:50:03,229 - MainThread - plmanagement.unittest_loader - INFO - TEST GROUP tearDown: VmDiskJAVA 11:50:03 2014-11-26 11:50:03,230 - MainThread - rhevmtests.virt.reg_vms.reg_vms_test - INFO - Remove all disks from vm disk_vm 11:50:03 2014-11-26 11:50:03,475 - MainThread - art.rhevm_api.tests_lib.high_level.disks - INFO - Wait until disks state is OK 11:50:03 2014-11-26 11:50:03,606 - MainThread - plmanagement.unittest_loader - ERROR - Teardown failed: VmDiskJAVA, the reason: More than one Entities found for disk_vm_Disk1 on url 'https://jenkins-vm-04.scl.lab.tlv.redhat.com/api/disks'. 11:50:03 2014-11-26 11:50:03,606 - MainThread - plmanagement.unittest_loader - INFO - 11:50:03 ================================================================================ http://jenkins.qa.lab.tlv.redhat.com:8080/view/Compute/view/3.5-git/view/Virt/job/3.5-git-compute-virt-reg_vms-nfs/111/consoleFull Version-Release number of selected component (if applicable): RHEV: 3.5 vt11 How reproducible: Attched java code. Actual results: Different disks with the same name. Attached screenshot Expected results: Different disks with different names. Additional info: 1. This case works before in automation, now see it from this build. 2. The reproduce java code don't wait till disk created it continue to next creation.
Created attachment 961673 [details] Disks in VM with the same name
Created attachment 961676 [details] java code
It is completely OK to have different disks with the same alias, the backend doesn't impose any restriction in these regards. Neither do the SDKs. So I think this should be closed as NOTABUG. Am I missing something?
it automation blocker and did not happens is REST API.
also the RFE https://bugzilla.redhat.com/show_bug.cgi?id=1048989 that ask for the same alias denied
Disks with the same aliases can be created using directly the RESTAPI, for example: ---8<--- #!/bin/sh -ex url="https://ovirt.example.com/ovirt-engine/api" user="admin@internal" password="..." vmid="..." for i in {1..5} do echo "${i}" curl \ --insecure \ --request POST \ --user "${user}:${password}" \ --header "Content-Type: application/xml" \ --header "Accept: application/xml" \ --data ' <disk> <size>100000</size> <interface>virtio</interface> <format>raw</format> <active>true</active> </disk> ' \ "${url}/vms/${vmid}/disks" done --->8--- Actually what that RFE requested was to prohibit same alias for two disks, and that is what was rejected, thus the behavior of the RESTAPI and the Java SDK is correct in these regards. Automation tests should not fail on this. Please close as NOTABUG or as a duplicate of the rejected RFE.
Sorry for the change
It also affect REST and SDK apis
The problem is not only in JAVA API. We run vt12 test without java and get the same problem. Case VMdisk in CLI automation test: jenkins.qa.lab.tlv.redhat.com:8080/view/Compute/view/3.5-git/view/Virt/job/3.5-git-compute-virt-reg_vms-nfs/112/
It happens in 3.5-storage_backup_api_sanity as well - on REST . It is true that we support having disks with the same alias. The problem is that when we addDisk without alias the engine suggest a name and make sure it is unique by adding an incremental counter at the end (Disk1,Disk2,...). That was the behavior till VT10. Since VT11, the name suggested by the engine is the same (the counter is not incremented). In engine log, you can see : "Disk alias retrieved from the client is null or empty, the suggested default disk alias to be used is XXXX" We shouldn't have the same suggested alias for 2 disks in the same vm.
Disk aliases are not unique by definition. Any automation that assumes they are is simply wrong. Gal - with regard to the **suggested** aliases (comment 10), this is indeed a bug, but a much less severe one. Please open a specific bug on this, with steps to reproduce and the relevant logs. Thanks!
Allon, if comment #10 is true, this smells like a new regression that was introduced in VT11. Could you help find out why was this behavior changed between VT10 and VT11?
engine.log is at : http://jenkins.qa.lab.tlv.redhat.com:8080/view/Storage/view/3.5/job/Developer-job-gamado/293/artifact/logs/jenkins-Developer-job-gamado-293__11272014_08-11-54.tar.bz2 In there, the same name "backup_api_vm_0_nfs_Disk1" is suggested twice for disks on the same VM, search for: "Disk alias retrieved from the client is null or empty, the suggested default disk alias to be used is backup_api_vm_0_nfs_Disk1" I have a developer job to reproduce : http://jenkins.qa.lab.tlv.redhat.com:8080/view/Storage/view/3.5/job/Developer-job-gamado/293/artifact/logs/jenkins-Developer-job-gamado-293 For VT10, it works fine. At the moment, our Automation relay on this feature, it fails our regression.
Created attachment 961999 [details] test logs
Are you trying to create the disks sequentially or all at the same time? If one disk was not created yet it makes perfect sense that the next suggested alias will be the one suggested to the other disk. The change that introduced what you are experiencing now just took the disk alias suggestion to an earlier phase in the command life cycle. If I understand correctly, the fact that you got different aliases was merely because of timing and in any case you should rely on disk aliases for your automation whatsoever
Tal , This is not the case (#16). It was done sequentially. Please take a look at the engine.log I've attached. in there you can clearly see that it suggested , than created the disk , and some 6 sec after that it suggested the same name again . Keep in mind that it is something that worked fine and broke.
A fix to the specific problem has been posted but in any case and regardless to that - a disk alias is not a primary key, using it as a unique identifier in tests is definitely not that way to go, I'd consider moving the tests to use UUIDs in the future, nothing guarantees you the uniqueness of a disk alias and nothing guarantees you the order of suggestions of a new alias
verified by automation on : Red Hat Enterprise Virtualization Manager Version: 3.5.0-0.23.beta.el6ev Passed both nfs and iscsi jobs : http://jenkins.qa.lab.tlv.redhat.com:8080/view/Storage/view/3.5/job/3.5-storage_backup_api_sanity-iscsi/34/ http://jenkins.qa.lab.tlv.redhat.com:8080/view/Storage/view/3.5/job/3.5-storage_backup_api_sanity-nfs/23/
RHEV-M 3.5.0 has been released, closing this bug.