Bug 859225 - [RFE] ovirt-engine-restapi : 3.0 capabilities contains 3.1 related permissions [NEEDINFO]
[RFE] ovirt-engine-restapi : 3.0 capabilities contains 3.1 related permissions
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-restapi (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: Juan Hernández
Oded Ramraz
: FutureFeature
Depends On:
  Show dependency treegraph
Reported: 2012-09-20 16:23 EDT by Oded Ramraz
Modified: 2016-02-10 14:38 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2014-08-03 02:34:03 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mpastern: needinfo? (oliel)
dyasny: Triaged+

Attachments (Terms of Use)

  None (edit)
Description Oded Ramraz 2012-09-20 16:23:28 EDT
Description of problem:

3.0 capabilities contains 3.1 related permissions ( see Additional Information )

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:

Expected results:

Additional info:

## under 3.0 capabilities /permits 

<permit id="900"><name>configure_quota</name><administrative>true</administrative></permit><permit id="901"><name>consume_quota</name><administrative>false</administrative></permit><permit id="1000"><name>create_gluster_volume</name><administrative>true</administrative></permit><permit id="1001"><name>manipulate_gluster_volume</name><administrative>true</administrative></permit><permit id="1002"><name>delete_gluster_volume</name><administrative>true</administrative>


<permit id="1104"><name>port_mirroring</name><administrative>true</administrative></permit>

Comment 1 Oded Ramraz 2012-09-20 16:30:55 EDT
I see capabilities for 3.1 , 3.0 , permits , and scheduling_policies.

<version major="3" minor="1" href="/api/capabilities/332e3133-2e31-332e-3133-2e31332e3133" id="332e3133-2e31-332e-3133-2e31332e3133">
</version><version major="3" minor="0" href="/api/capabilities/332e3033-2e30-332e-3033-2e30332e3033" id="332e3033-2e30-332e-3033-2e30332e3033"></version>

Why do I have separate sections for permits and scheduling_policies? 
Is it related to this issue , or should i file separate bug for this one ?
Comment 2 Itamar Heim 2012-09-20 16:34:41 EDT
i don't see an issue with a 3.1 system allowing to configure these permits in its 3.0 part.
for example, I don't think we limit quota to 3.1 DCs.

same goes for port mirroring - while it is only relevant for 3.1 clusters, one could create a role for a user on both 3.0 and 3.1 clusters - it will be same role, with same set of permits, even if some of the permits are not relevant for 3.0 clusters.
Comment 3 Oded Ramraz 2012-09-20 16:47:54 EDT
I still don't understand why I have the permissions list 3 times in the capabilities :
1 for 3.0 , 1 for 3.1 and 1 without version. 
From initial look theirs content seems similar to me . 

BTW , I found two permissions with same ID:
<permit id="1104"><name>delete_disk</name><administrative>false</administrative></permit>
<permit id="1104"><name>port_mirroring</name><administrative>true</administrative>

I'll open separate bug for this issue ,
Comment 4 Michael Pasternak 2012-09-24 03:31:07 EDT
requires internal enums refactoring for being able distinguish 
member/s peer version
Comment 7 Itamar Heim 2014-08-03 02:34:03 EDT
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.

Note You need to log in before you can comment on or make changes to this bug.