On 11/16/2012 09:34 AM, Itamar Heim wrote: > On 11/15/2012 07:01 PM, Moti Asayag wrote: >> To recap so far: >> >> 1. User may see only the networks he has a permission on. >> 2. User API: Only permitted networks are shown to the user. A user will >> be capable to view the network element attached to its vnic, only if he >> has permission on that network, else it will see its id (same as storage >> domain id appears under disk element which attached to a vm). > > I think a user should be able to see network for networks associated to > their VMs, regardless of permissions to the attach the network to other > vms. > it doesn't mean they need to see all details (like statistics, which are > not part of the user level api) > I'm pretty sure storage, cluster and dc follow the same concept in user > level api. >
Could you elaborate the importance from user perspective for the network implementation details? why the user should be concerned with MTU, Vlan and other network properties? Wouldn't the cloud-provider prefer to encapsulate this information from the end-user ? >> 3. On upgrade: 'everyone' will get 'VmNetworkUser' role on all of the >> networks on the system. >> 4. On the dialog of creating new network there will be an option to >> grant 'everyone' permissions of the created network with 'VmNetworkUser' >> role (same as on 'make template' dialog). >> 5. Since there is no granularity of permission of network for the scope >> of a specific VM, If a user is 'VmNetworkUser' on a network, he may >> attach it to any VM he has a permission on (permission to edit the VM). >> 6. 'Create a VM from Template' and 'Create a VM from Snapshot/Clone VM' >> requires permissions on the vnics' networks. This will save the need to >> grant an automatic permissions for the vnics' networks. An alternative >> would be the opposite: Leave the current required permissions as is and >> grant permissions to the users for the networks of the created VM. >> >> Once we'll reach into a conclusion, I'll update the wiki accordingly. >> >> Thanks, >> Moti >> >> On 11/06/2012 03:56 PM, Livnat Peer wrote: >>> Hi All, >>> >>> This is a proposal for handling network permissions in oVirt. >>> >>> In this proposal we took the more permissive approach as we find it >>> simple and a good starting point, we also think a more restrict approach >>> makes the configuration of a network cumbersome for ovirt >>> administrators. >>> >>> Inputs are welcomed as always... >>> >>> Here is an overview of the approach, for more detailed description >>> please read the wiki page: >>> http://wiki.ovirt.org/wiki/Feature/NetworkPermissions >>> >>> --------------------------------------------------------------------------- >>> >>> Admin >>> ====== >>> >>> -> For creating a network in a data center you need to be a Superuser or >>> a DCAdmin or a networkAdmin on the DC. >>> >>> -> After creating the network you can manipulate the network if you are >>> a DCAdmin or a networkAdmin on the relevant network (or the whole DC). >>> >>> -> For attaching the network to cluster you need to be a networkAdmin on >>> the network (no requirement to have permission on the cluster) >>> >>> -> Cluster administrator can not attach/detach a network from the >>> cluster, the motivation for this is that as long as the network is not >>> attached to the cluster it is not part of the cluster resources thus can >>> not be managed by the cluster administrator. >>> In addition once a network is attached to a cluster the cluster >>> administrator can change the network from required to non-required for >>> controlling the impact of the network within the cluster. >>> >>> -> For setting a network on the host you need to be host administrator >>> on the host and you don't need to be network administrator. >>> This implies that if you are a host administrator you can add/remove all >>> the cluster networks from your host without the need for network related >>> permissions (this is the permissive approach). >>> >>> User >>> ==== >>> >>> -> For attaching a network to a Vnic in the VM you need to have the role >>> of VmNetworkUser on the network and vmAdmin on the VM. >>> >>> -> In user portal - the list of shown network for a user will include >>> only the list of networks the user is allowed to attach to its vnics >>> (instead of all cluster's networks). >>> >>> Port-mirroring >>> =============== >>> >>> -> For configuring in the VM port mirroring you need to have the role >>> of VmAdvancedNetworkUser on the network and vmAdmin on the VM. >>> VmAdvancedNetworkUser includes the VmNetworkUser actions in addition to >>> port mirroring. >>> >>> >>> >>> >>> For all DB upgrade information and new roles/action groups please review >>> the wiki. >>> >>> Thanks, >>> Livnat & Moti >>> >> > > _______________________________________________ Engine-devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
