On 11/19/2012 11:22 PM, Livnat Peer wrote:
On 16/11/12 12:06, Itamar Heim wrote:
On 11/16/2012 10:22 AM, Moti Asayag wrote:
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 ?
i do agree not all fields are relevant to user, and iirc, we have a
mechanism to filter out such fields.
is the MTU of the logical network a secret? user will get it from the
vnic anyway, right?
logical network name is also something user may need to know (what is
user going to see in the power user portal when standing on a VM which
has a vnic with a network they don't have a permission for? the uuid
instead of the network name?
tomorrow will let user create virtual networks. you need to decide which
fields they can and cannot set (vlan they cannot set. not sure if we
should or shouldn't hide it. i'm guessing both use cases will have merit
actually).
With the above approach, what will the user see if he go to the network
main collection (/api/networks) in the user API?
Today you don't get any network info in the user API (I think - need to
make sure), with the approach Moti suggested you see all the networks
you have permissions on, but with the approach you suggested it seems
like the user will be able to see all networks, for those he has
permissions on he'll get all the details and for those he has no
permissions he'll get limited amount of info like (name, description,
MTU, usage). Do we want the user to be aware of all the networks defined
in our DC?
user always gets same level of details on entities they see today.
according to the approach i'm suggesting, user will see all networks
they can see either via direct permissions, or because they are used by
entities they have permissions to.
Livnat
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
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
