Description of problem: The test fails with some missing permission issues Version-Release number of selected component (if applicable): Run the tesst on latest rebased 3.6 rhevm How reproducible: Run the tests on latest rebased 3.6 rhevm Steps to Reproduce: 1.Run the tests on latest rebased 3.6 rhevm 2. 3. Actual results: Test fails Expected results: Test passes with the correct permissions check Additional info: http://jenkins-ci.eng.lab.tlv.redhat.com/view/0%20Unstable%203.6/job/rhevm_3.6_el6-engine_el6-host_automation_infra_one_host_restapi_mixed_nfs_rest_factory_vdsm/ The missing permissions are: Permit 'reboot_vm' doesn't appear in permission list Permit 'stop_vm' doesn't appear in permission list Permit 'shut_down_vm' doesn't appear in permission list Permit 'hibernate_vm' doesn't appear in permission list Permit 'run_vm' doesn't appear in permission list Permit 'manipulate_gluster_hook' doesn't appear in permission list Permit 'manipulate_gluster_service' doesn't appear in permission list Permit 'create_mac_pool' doesn't appear in permission list Permit 'edit_mac_pool' doesn't appear in permission list Permit 'delete_mac_pool' doesn't appear in permission list Permit 'configure_mac_pool' doesn't appear in permission list For more detailed info check the job logs
In order to examine issues like that we need to know more about the tests themselves. Opening a bug like that doesn't give us enough information to proceed with. Gil - who can narrow this down into a specific test that is run, and the logic that failed?
(In reply to Oved Ourfali from comment #1) > In order to examine issues like that we need to know more about the tests > themselves. Opening a bug like that doesn't give us enough information to > proceed with. > > Gil - who can narrow this down into a specific test that is run, and the > logic that failed? Looks like this job is owned by the RHEV QE compute team (You can see the jobs owners in the "Job Ownership" box). Ilanit, could you please help pinpoint this issue?
Moving need info to Nelly, as this job should be under RHEV QE infra team.
We send ovirt-engine/api/capabilities and see two issues in this test: 1. we expect to find 'vm_basic_operations' permit, but it doesnt exist there, so the question is why its not there any more 2. looks like there are 12 new permits, so Ill need approval that they should really be there & Ill add them to the test: reboot_vm stop_vm shut_down_vm hibernate_vm run_vm manipulate_gluster_service manipulate_gluster_hook disk_live_storage_migration create_mac_pool edit_mac_pool delete_mac_pool configure_mac_pool
It requires review of different teams. Putting needinfos. (and when you answer please make sure you don't remove all needinfos...).
the VM related perms were changed by bug 1084117: VM_BASIC_OPERATIONS aggregates the following permissions: REBOOT_VM, STOP_VM, SHUT_DOWN_VM, PAUSE_VM, HIBERNATE_VM, RUN_VM. This RFE remove VM_BASIC_OPERATIONS and instead add this new operations.
The 4 MAC pool permissions are indeed new additions as part of the MAC pool per DC feature.
@Michal PAUSE_VM doesnt exist in the permit list
Nelly, if new permissions are added to the application but not yet added to this test - does that break the test?
yes, because we want to be able to track both sides - newly added permits & removed permits and align the test but the correct flow is to get this information in advance, so we will not need to open bugs on such code changes @Michal, please see comment 8
(In reply to Nelly Credi from comment #8) > @Michal PAUSE_VM doesnt exist in the permit list yeah, apparently it's not exposed. Nevermind:)
So if a developer adds a new permission and posts his change - jenkins build will fail? That's kind of problematic from the developers point of view.
From the comments above looks like currently there is no problem with the mentioned permissions. Can the bug be closed?
Im still waiting for an answer about: manipulate_gluster_service manipulate_gluster_hook disk_live_storage_migration once I get OK about these permits, we can close the bug
Are we trying to establish that the permissions which appear in ovirt-engine/api/capabilities but not in the above test were added on purpose? Why suspect otherwise? I think there's a problem with the concept of the test; any new permission added would immediately break it. Anyway, the above three permissions came from: disk_live_storage_migration: https://gerrit.ovirt.org/#/c/37287/ (Maor) manipulate_gluster_hook, manipulate_gluster_service: https://gerrit.ovirt.org/#/c/19280/ (Daniel) - Maor, Daniel, can you validate that they should indeed exist and were added on purpose, and then we can close this bug?
(In reply to Ori Liel from comment #15) > Are we trying to establish that the permissions which appear in > ovirt-engine/api/capabilities but not in the above test were added on > purpose? Why suspect otherwise? I think there's a problem with the concept > of the test; any new permission added would immediately break it. > > Anyway, the above three permissions came from: > > disk_live_storage_migration: > https://gerrit.ovirt.org/#/c/37287/ (Maor) > > manipulate_gluster_hook, manipulate_gluster_service: > https://gerrit.ovirt.org/#/c/19280/ (Daniel) - Not sure about these, they were added by https://gerrit.ovirt.org/#/c/13269/ and https://gerrit.ovirt.org/#/c/14831. @Sahina - I guess those are old enough so should probably be valid? > > Maor, Daniel, can you validate that they should indeed exist and were added > on purpose, and then we can close this bug?
When I tried to see the error in the console output in jenkins, it looked like this test doesn't fail any more. I could only see the error output in earlier builds. I believe this problem was fixed somewhere along the way. Nelly, can we verify this?
Nelli - I'm closing this one, as it is an issue with the test. You should track that internally. If relevant, and infra-related, please reopen.
AFAIK this was not resolved, its just that there were build issues in the past couple of weeks, so the test wasnt executed. Can someone please provide the info for my last question (comment 14), so we can close this issue on my side too?
(In reply to Nelly Credi from comment #19) > AFAIK this was not resolved, its just that there were build issues in the > past couple of weeks, so the test wasnt executed. > Can someone please provide the info for my last question (comment 14), so we > can close this issue on my side too? Anyhow, we saw that it is probably not a bug, so bugzilla isn't the right place to track that.... as we can't open a bug/RFE on automation tests through bugzilla, otherwise I would have moved the bug to another component and whiteboard. I suggest you email the relevant people left, offline, and get your answer there.
Allon, could you please help review the last 3 permissions which seems to be storage related. Please see comment #14 for the exact details.
(In reply to Gil Klein from comment #21) > Allon, could you please help review the last 3 permissions which seems to be > storage related. Please see comment #14 for the exact details. (In reply to Nelly Credi from comment #14) > Im still waiting for an answer about: > > manipulate_gluster_service > manipulate_gluster_hook Can't help you here, sorry - these are gluster permissions. Sahina, could you please assist? > disk_live_storage_migration Yup. Added in 3.5.0 as part of another BZ, expected.
manipulate_gluster_hooks was added as part of the Gluster hooks management feature(http://www.ovirt.org/Features/Gluster_Hooks_Management) introduced in ovirt3.3 manipulate_gluster_service was added as part of the http://www.ovirt.org/Features/Gluster_Swift_Management in oVirt3.3, but is disabled. These are applicable only on clusters with gluster service enabled.