Bug 1695858

Summary:	[RFE] Request VM Folders For Assigning Permissions
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Robert McSwain <rmcswain>
Component:	ovirt-engine	Assignee:	Nobody <nobody>
Status:	CLOSED DEFERRED	QA Contact:	Lukas Svaty <lsvaty>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	2.1.0	CC:	anowak, cnagarka, michal.skrivanek, mperina, mtessun
Target Milestone:	---	Keywords:	FutureFeature, Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-11-23 16:12:09 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Robert McSwain 2019-04-03 19:51:43 UTC

1. Proposed title of this feature request VM Folders

3. What is the nature and description of the request? Allow the creation of folders in RHVM to allow VMs to be grouped together. The VMs can then inherit permissions given at the folder level.

4. Why does the customer need this? (List the business requirements here) Ease of giving a user permissions to multiple VMs without having to grant permissions on a per-VM basis

5. How would the customer like to achieve this? (List the functional requirements here). In the left side panel, have a "folder view". The admin could then create folders for each end user group and apply permissions to the folder for that group. When a VM is placed in that folder, it would then inherit the permissions of the folder. Also, it could serve as a logical grouping of VMs in the "Virtual Machines" view, allowing the administrators an easy way to organize VMs.

6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
Basically move a VM into the folder and see if the permissions have been successfully applied

7. Is there already an existing RFE upstream or in Red Hat Bugzilla? https://bugzilla.redhat.com/show_bug.cgi?id=1004200 for RHEV 3.x and
https://bugzilla.redhat.com/show_bug.cgi?id=1074026
It looks like both were closed out.

8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL5, RHEL6)? As soon as feasible

10. List any affected packages or components. ovirt-engine

11. Would the customer be able to assist in testing this functionality if implemented? Yes

Comment 2 Michal Skrivanek 2020-03-18 15:50:07 UTC

This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly

Comment 3 Michal Skrivanek 2020-03-18 15:52:42 UTC

This bug didn't get any attention for a while, we didn't have the capacity to make any progress. If you deeply care about it or want to work on it please assign/target accordingly

Comment 4 Michal Skrivanek 2020-04-01 14:48:56 UTC

ok, closing. Please reopen if still relevant/you want to work on it.

Comment 5 Michal Skrivanek 2020-04-01 14:51:54 UTC

ok, closing. Please reopen if still relevant/you want to work on it.

Comment 7 Michal Skrivanek 2020-06-23 12:35:16 UTC

This request is not currently committed to 4.4.z, moving it to 4.5

Comment 12 Martin Tessun 2021-11-23 16:12:09 UTC

After looking through this request again, we don't think the amount of work needed is qualified by the functionality. There are several ways to achieve that, depending on the "need".

1. Volatile Users - static VMs
  - Cretae a group for the users and assign the group with appropriate permissions to the VM

2. Volatile VMs - static Users
  - Have no permissions on the VM by default
  - Tag the VMs with the same tag
  - Have a playbook in place that does use that tag to set the permissions

3. Volatile VMs and Volatile Users
  - combine 1 and 2

4. Grouping
  - Just use Tags.

We acknowledge that esp. solution (2) is not the most convenient one, but the convenience here does not outweigh the amount of work needed to implement this feature.

As such closing this request.