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: 1. 2. 3. 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> ....
I see capabilities for 3.1 , 3.0 , permits , and scheduling_policies. https://aqua-rhel.qa.lab.tlv.redhat.com/api/capabilities <capabilities> <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> <permits></permits> <scheduling_policies></scheduling_policies> </capabilities> 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 ?
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.
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 ,
requires internal enums refactoring for being able distinguish member/s peer version
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days