Re: [Engine-devel] Managing permissions on network
On 11/13/2012 09:57 PM, Charlie wrote: Will any of these groups and/or permissions be drawn from LDAP? Frankly, system admins are not looking for yet another console to manage permissions. all users/groups come from LDAP. you just need to give permissions to these groups/users in ovirt. is that what you meant? --Charlie On Tue, Nov 13, 2012 at 1:19 PM, Itamar Heim wrote: On 11/13/2012 07:18 PM, Livnat Peer wrote: On 13/11/12 15:39, Itamar Heim wrote: On 11/13/2012 03:37 PM, Livnat Peer wrote: On 13/11/12 15:19, Itamar Heim wrote: On 11/13/2012 12:45 PM, Livnat Peer wrote: Interesting point, I think that if a user has permission to create a VM from a specific template we should give him permission to use the template networks on this VM implicitly upon the VM creation. having a permission to a template does not mean a permission to the default network of that VM, especially as we'll use templates more as instance types. Another alternative is to require permission on the network as well as the template. I must say I don't really like it, although I agree with your comment, we require too many operations for enabling a user to create a VM from template (permission on the template, quota on the storage, permissions on the network, next we'll require a PHD ;)). Anyone has a better idea? I assume most networks would be given either to 'everyone' or groups of users, not per user (and if the network is per user/tenant, then it must be done per user. Which reminds that I wanted to propose adding a property on a network which is called public. It's just a UI feature to give a NetworkUser on this network to 'everyone'. It makes making a network public easier for the user. In addition during upgrade we should make all existing networks public networks and not allocate specific permissions for users on networks. In addition it also means a user is given permission on a network and then he can use it for any VM he owns. Isn't that problematic? We can't limit a user to use a network on a specific VM. I think that's fine. don't let user edit that vm if you don't trust them. i may not remember correctly, but i thought when giving quota to user we also give some permissions with it (on cluster and storage)? I am not sure what is the current implementation as it changed a lot, but last I tracked we checked for either quota or permissions we did not give implicit permissions when creating a quota. gilad/doron? ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Proposal to add Allon Mureinik as maintainer to engine core
+1 - Original Message - > From: "Itamar Heim" > To: engine-devel@ovirt.org > Sent: Wednesday, November 14, 2012 6:12:09 AM > Subject: [Engine-devel] Proposal to add Allon Mureinik as maintainer to > engine core > > Allon has worked on oVirt for the past 10 months. > With 534 patches ranging from cleanups, to complex features like user > level api and storage live migration. In addition, Allon has been > instrumental in the number of patch reviews he has done. > > I'd like to propose Allon as a maintainer of engine core. > > Thanks, > Itamar > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Proposal to add Allon Mureinik as maintainer to engine core
Allon has worked on oVirt for the past 10 months. With 534 patches ranging from cleanups, to complex features like user level api and storage live migration. In addition, Allon has been instrumental in the number of patch reviews he has done. I'd like to propose Allon as a maintainer of engine core. Thanks, Itamar ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Unable to view the storage domains - SQL error
Hi Christopher, In general - as a developer at engine project, I would recommend to run the upgrade script on a frequent basis. What troubles me with the query you sent (maybe some problematic copy paste issue?) are the following issues: a. storage domains for search - not sure what this is b. storage domains with hosts view - I guess you have some underline issue at the copy paste. I would appreciate if you attach engine.log (or a part of it that reflects the error you encountered) Kind regards, Yair - Original Message - > From: "Christopher Morrissey" > To: engine-devel@ovirt.org > Sent: Wednesday, November 14, 2012 12:10:14 AM > Subject: [Engine-devel] Unable to view the storage domains - SQL > error > Hi All, > I’m getting an error when trying to view the storage domains using > the REST API: > > > Operation Failed > statementcallback; bad sql grammar [select * from (select * > from storage domains for search where ( id in (select storage > domains with hosts view.id from storage domains with hosts view )) > order by storage name asc ) as t1 offset (1 -1) limit 100]; nested > exception is org.postgresql.util.psqlexception: error: relation > "storage domains for search" does not exist position: 30 > > Also, through the web admin console, when viewing the storage domains > the list never loads. > Did something change in the DB recently such that I would need to > rebuild it? > -Chris > Chris Morrissey > Software Engineer > NetApp Inc. > 919.476.4428 > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Unable to view the storage domains - SQL error
Hi All, I'm getting an error when trying to view the storage domains using the REST API: Operation Failed statementcallback; bad sql grammar [select * from (select * from storage domains for search where ( id in (select storage domains with hosts view.id from storage domains with hosts view )) order by storage name asc ) as t1 offset (1 -1) limit 100]; nested exception is org.postgresql.util.psqlexception: error: relation "storage domains for search" does not exist position: 30 Also, through the web admin console, when viewing the storage domains the list never loads. Did something change in the DB recently such that I would need to rebuild it? -Chris Chris Morrissey Software Engineer NetApp Inc. 919.476.4428 ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Managing permissions on network
Will any of these groups and/or permissions be drawn from LDAP? Frankly, system admins are not looking for yet another console to manage permissions. --Charlie On Tue, Nov 13, 2012 at 1:19 PM, Itamar Heim wrote: > On 11/13/2012 07:18 PM, Livnat Peer wrote: >> >> On 13/11/12 15:39, Itamar Heim wrote: >>> >>> On 11/13/2012 03:37 PM, Livnat Peer wrote: On 13/11/12 15:19, Itamar Heim wrote: > > On 11/13/2012 12:45 PM, Livnat Peer wrote: >> >> Interesting point, I think that if a user has permission to create a >> VM >> from a specific template we should give him permission to use the >> template networks on this VM implicitly upon the VM creation. > > > having a permission to a template does not mean a permission to the > default network of that VM, especially as we'll use templates more as > instance types. Another alternative is to require permission on the network as well as the template. I must say I don't really like it, although I agree with your comment, we require too many operations for enabling a user to create a VM from template (permission on the template, quota on the storage, permissions on the network, next we'll require a PHD ;)). Anyone has a better idea? >>> >>> >>> I assume most networks would be given either to 'everyone' or groups of >>> users, not per user (and if the network is per user/tenant, then it must >>> be done per user. >> >> >> Which reminds that I wanted to propose adding a property on a network >> which is called public. >> It's just a UI feature to give a NetworkUser on this network to >> 'everyone'. It makes making a network public easier for the user. >> >> In addition during upgrade we should make all existing networks public >> networks and not allocate specific permissions for users on networks. >> >> In addition it also means a user is given permission on a network and >> then he can use it for any VM he owns. Isn't that problematic? We can't >> limit a user to use a network on a specific VM. > > > I think that's fine. > don't let user edit that vm if you don't trust them. > > >> >>> i may not remember correctly, but i thought when giving quota to user we >>> also give some permissions with it (on cluster and storage)? >> >> >> I am not sure what is the current implementation as it changed a lot, >> but last I tracked we checked for either quota or permissions we did not >> give implicit permissions when creating a quota. >> > > gilad/doron? > > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Network Wiring
On 11/13/2012 07:58 PM, Simon Grinberg wrote: > From the summary: > "...It supports the following actions without unplugging the Vnic, and it > maintains the device address of the Vnic " > > But in the dialogue section: > "If the Vnic is plugged there should be a message on top of the dialog > "Please notice, changing Type or MAC will cause unplugging and plugging the > Vnic" > > Looking at the detailed design indeed any change indeed goes through > plug/unplug. > Please correct me if I got the above wrong. Changing the network (rewiring network) is done using new API with VDSM, updateVmInteface. Therefore plug/unplug won't be executed for any of: 1. Changing the network to other network or disconnecting/unwiring it). 2. Update the name of the VM (db only). Other changes to VM properties (i.e. MAC address, driver type) will require the plug/unplug. Same goes to any explicit 'unplug' command. > > To support real live rewire == "Move a card from one network to another" > The sequence should be for wired-plugged card: > - Unwire > - Change network > - Rewire > > I would argue that we should actually force the user to perform these steps, > but we can do it in one go. The intention is to use the new API VDSM.libvirtVm.updateVmInteface for performing the network rewire in a single command. > > Any other state may change network freely. > > To change name - it's just DB, so any state goes > > To change type or MAC address (= property), must go through unplug regardless > to the wired state > So: > - Unplug > - Change property > - Plug > > Again should probably ask the user to do these 3 steps so he'll know what he > is doing, but we can do it for him with proper warning. > > I also wander I do we have to drop the PCI address in the persisted table in > this case - loosing the PCI location is redundant and will cause a move to > another eth0 number in the guest. On the other hand changing of MAC may break > network scripts anyhow - so I don't have a strong argument to keep it. > > > Another issue: > If the nic is there to be use by a hook, then you probably want to allow > 'none' network. > This may also be useful when allowing to purge a network while it is > connected to VMs: unwire on all nics and connect to the none network. > > > Overall, looking great, and I like the wired vs unplugged that emulate real > behavior. > > Regards, > Simon > > > > > > > > > > > - Original Message - >> From: "Alona Kaplan" >> To: engine-devel@ovirt.org, "Simon Grinberg" , >> rhevm-qe-netw...@redhat.com >> Sent: Tuesday, November 13, 2012 4:46:52 PM >> Subject: Network Wiring >> >> Hi all, >> >> Please review the wiki and add your comments. >> >> http://wiki.ovirt.org/wiki/Feature/NetworkWiring >> >> >> Thanks, >> Alona. >> > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Managing permissions on network
On 11/13/2012 07:18 PM, Livnat Peer wrote: On 13/11/12 15:39, Itamar Heim wrote: On 11/13/2012 03:37 PM, Livnat Peer wrote: On 13/11/12 15:19, Itamar Heim wrote: On 11/13/2012 12:45 PM, Livnat Peer wrote: Interesting point, I think that if a user has permission to create a VM from a specific template we should give him permission to use the template networks on this VM implicitly upon the VM creation. having a permission to a template does not mean a permission to the default network of that VM, especially as we'll use templates more as instance types. Another alternative is to require permission on the network as well as the template. I must say I don't really like it, although I agree with your comment, we require too many operations for enabling a user to create a VM from template (permission on the template, quota on the storage, permissions on the network, next we'll require a PHD ;)). Anyone has a better idea? I assume most networks would be given either to 'everyone' or groups of users, not per user (and if the network is per user/tenant, then it must be done per user. Which reminds that I wanted to propose adding a property on a network which is called public. It's just a UI feature to give a NetworkUser on this network to 'everyone'. It makes making a network public easier for the user. In addition during upgrade we should make all existing networks public networks and not allocate specific permissions for users on networks. In addition it also means a user is given permission on a network and then he can use it for any VM he owns. Isn't that problematic? We can't limit a user to use a network on a specific VM. I think that's fine. don't let user edit that vm if you don't trust them. i may not remember correctly, but i thought when giving quota to user we also give some permissions with it (on cluster and storage)? I am not sure what is the current implementation as it changed a lot, but last I tracked we checked for either quota or permissions we did not give implicit permissions when creating a quota. gilad/doron? ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Network Wiring
>From the summary: "...It supports the following actions without unplugging the Vnic, and it maintains the device address of the Vnic " But in the dialogue section: "If the Vnic is plugged there should be a message on top of the dialog "Please notice, changing Type or MAC will cause unplugging and plugging the Vnic" Looking at the detailed design indeed any change indeed goes through plug/unplug. Please correct me if I got the above wrong. To support real live rewire == "Move a card from one network to another" The sequence should be for wired-plugged card: - Unwire - Change network - Rewire I would argue that we should actually force the user to perform these steps, but we can do it in one go. Any other state may change network freely. To change name - it's just DB, so any state goes To change type or MAC address (= property), must go through unplug regardless to the wired state So: - Unplug - Change property - Plug Again should probably ask the user to do these 3 steps so he'll know what he is doing, but we can do it for him with proper warning. I also wander I do we have to drop the PCI address in the persisted table in this case - loosing the PCI location is redundant and will cause a move to another eth0 number in the guest. On the other hand changing of MAC may break network scripts anyhow - so I don't have a strong argument to keep it. Another issue: If the nic is there to be use by a hook, then you probably want to allow 'none' network. This may also be useful when allowing to purge a network while it is connected to VMs: unwire on all nics and connect to the none network. Overall, looking great, and I like the wired vs unplugged that emulate real behavior. Regards, Simon - Original Message - > From: "Alona Kaplan" > To: engine-devel@ovirt.org, "Simon Grinberg" , > rhevm-qe-netw...@redhat.com > Sent: Tuesday, November 13, 2012 4:46:52 PM > Subject: Network Wiring > > Hi all, > > Please review the wiki and add your comments. > > http://wiki.ovirt.org/wiki/Feature/NetworkWiring > > > Thanks, > Alona. > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Managing permissions on network
On 13/11/12 15:39, Itamar Heim wrote: > On 11/13/2012 03:37 PM, Livnat Peer wrote: >> On 13/11/12 15:19, Itamar Heim wrote: >>> On 11/13/2012 12:45 PM, Livnat Peer wrote: Interesting point, I think that if a user has permission to create a VM from a specific template we should give him permission to use the template networks on this VM implicitly upon the VM creation. >>> >>> having a permission to a template does not mean a permission to the >>> default network of that VM, especially as we'll use templates more as >>> instance types. >> >> Another alternative is to require permission on the network as well as >> the template. >> I must say I don't really like it, although I agree with your comment, >> we require too many operations for enabling a user to create a VM from >> template (permission on the template, quota on the storage, permissions >> on the network, next we'll require a PHD ;)). >> >> Anyone has a better idea? > > I assume most networks would be given either to 'everyone' or groups of > users, not per user (and if the network is per user/tenant, then it must > be done per user. Which reminds that I wanted to propose adding a property on a network which is called public. It's just a UI feature to give a NetworkUser on this network to 'everyone'. It makes making a network public easier for the user. In addition during upgrade we should make all existing networks public networks and not allocate specific permissions for users on networks. In addition it also means a user is given permission on a network and then he can use it for any VM he owns. Isn't that problematic? We can't limit a user to use a network on a specific VM. > i may not remember correctly, but i thought when giving quota to user we > also give some permissions with it (on cluster and storage)? I am not sure what is the current implementation as it changed a lot, but last I tracked we checked for either quota or permissions we did not give implicit permissions when creating a quota. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Building oVirt from source
Hi all, Have another round to build oVirt from source following; Building Engine Draft http://wiki.ovirt.org/wiki/Building_Engine_Draft OS - Fedora 17 desktop 64bit, fresh and clean installed. Not much problem encountered up to "Installing JBoss AS" except follows: 1) Maven personal settings == $ mkdir $HOME/.m2 $ wget -O $HOME/.m2/settings.xml http://wiki.ovirt.org/w/images/1/18/Settings.xml.png (it should read "http://wiki.ovirt.org/w/images/1/18/Settings.xml.png";) (not www) 2) Check that the application server starts correctly: $ cd $JBOSS_HOME/bin $ ./standalone.sh -b 0.0.0.0 === JBoss Bootstrap Environment JBOSS_HOME: /home/satimis/jboss-as JAVA: java JAVA_OPTS: -server -XX:+UseCompressedOops -XX:+TieredCompilation -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=360 -Dsun.rmi.dgc.server.gcInterval=360 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=tr . 22:14:38,217 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.1.1.Final "Brontes" started in 6662ms - Started 133 of 208 services (74 services are passive or on-demand) It hung here; Press [Ctrl] + c it continued to display: 19:49,653 INFO [org.jboss.as.osgi] (MSC service thread 1-3) JBAS011942: Stopping OSGi Framework 22:19:49,701 INFO [org.jboss.as.logging] JBAS011503: Restored bootstrap log handlers 22:19:49,726 INFO [org.apache.coyote.http11.Http11Protocol] Pausing Coyote HTTP/1.1 on http--0.0.0.0-8080 22:19:49,727 INFO [org.apache.coyote.http11.Http11Protocol] Stopping Coyote HTTP/1.1 on http--0.0.0.0-8080 22:19:49,729 INFO [com.arjuna.ats.jbossatx] ARJUNA032018: Destroying TransactionManagerService 22:19:49,730 INFO [com.arjuna.ats.jbossatx] ARJUNA032014: Stopping transaction recovery manager 22:19:49,753 INFO [org.jboss.as] JBAS015950: JBoss AS 7.1.1.Final "Brontes" stopped in 111ms Is it normal? Without problem? Thanks B.R. Stephen L___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] MOM [DR for 3.2] Host Power Management Proxy Preferences
Hi DR MOM : http://wiki.ovirt.org/wiki/Talk:HostPMProxyPreferences Requirements Page : http://wiki.ovirt.org/wiki/Features/HostPMProxyPreferences DR: http://wiki.ovirt.org/wiki/Features/Design/DetailedHostPMProxyPreferences ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Network Wiring
Hi all, Please review the wiki and add your comments. http://wiki.ovirt.org/wiki/Feature/NetworkWiring Thanks, Alona. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Managing permissions on network
On 11/13/2012 03:42 PM, Itamar Heim wrote: > On 11/13/2012 03:41 PM, Moti Asayag wrote: >> On 11/13/2012 03:19 PM, Itamar Heim wrote: >>> On 11/13/2012 12:45 PM, Livnat Peer wrote: Interesting point, I think that if a user has permission to create a VM from a specific template we should give him permission to use the template networks on this VM implicitly upon the VM creation. >>> >>> having a permission to a template does not mean a permission to the >>> default network of that VM, especially as we'll use templates more as >>> instance types. >> >> If a user is the template's owner he should be capable to modify the its >> nics. I'd expect the user will modify the networks of the template only >> if he has permissions for the required network. > > true. > >> Else, a user can update the template's nics to any of cluster's network >> and to create a VM with a network the user doesn't suppose to use. > > template having a default network doesn't mean user can create a vm with > that network as well, if user doesn't have a permission to that network. > In that case, no permissions will be granted to template's user on upgrade. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Managing permissions on network
On 11/13/2012 03:56 PM, Moti Asayag wrote: On 11/13/2012 03:21 PM, Itamar Heim wrote: On 11/13/2012 03:17 PM, Moti Asayag wrote: On 11/13/2012 12:45 PM, Livnat Peer wrote: On 13/11/12 10:57, Itamar Heim wrote: On 11/06/2012 02: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 High Level Feature Description Admin For creating a network in a DC you need to be SuperUser or DataCenterAdmin or NetworkAdmin on the DC. since there are multiple permissions among the differnet roles, maybe worth specifying the actual permissions (actiongroups), rather than just the roles? you can find this info in the wiki page itself,this is only high level summary. After creating the network you can manipulate the network if you are a DataCenterAdmin or NetworkAdmin on the relevant network (or the whole DC). For attaching the network to cluster user needs to be NetworkAdmin on the network (no requirement to have permission on the cluster) ClusterAdmin cannot 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. I'm not sure above two lines are intuitive to manage (a network admin can manipulate a cluster, but the cluster admin can't change networks in the cluster? this means you must give network permissions, at DC level, so you can't limit an admin to network attach/detach to a specific cluster. That is true but looking on the alternative I think it make sense. The alternative is to require two permissions for attaching a network to a cluster one is networkAdmin (for editing network properties) on a network and the other is networkAttach (a separate Role?) on a cluster or the DC (if you want the user to be able to add the network for all the clusters in the DC). While I think the common use case is that a network administrator will be able to attach the network to all the clusters I find the above cumbersome and rather stick to the approach that you need only a single permission and you can't limit the network manager to specific cluster. I think that if a requirement for limiting the network to specific clusters comes from our users only then we should make the model more strict and require two permissions. The ClusterAdmin can change a network from required to non-required for controlling the impact of the network within the cluster. For setting or manipulating a network on the host you need to be host administrator on the host and you don't need to be network administrator. 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. again, roles are just default roles, please specify the actual permission (actiongroup) take a look in the wiki for exact details (which role is composed out of which action groups) 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). or attached to user VMs. and need to handle case of network attached to template but user has no permission to that network? Interesting point, I think that if a user has permission to create a VM from a specific template we should give him permission to use the template networks on this VM implicitly upon the VM creation. I noticed the wiki page is missing which permission should be given to users on which networks/VMs during upgrade - Moti? Added: * '''VmNetworkUser''' role will be given to the user on each network attached to the VM/Template. * '''AdvancedVmNetworkUser''' role will be given to the user on each network attached to the VM with port-mirroring enabled. Hi Moti, I'm not sure what you mean by 'give to the user'. if the VM has the permission, it doesn't mean the user should get it as well, it only means user should be able to see networks their VM have associated with. can you please elaborate more. The role 'VmNetworkUser' is consist of action group 'CONFIGURE_VM_NETWORK': - AddVmInterface - RemoveVmInterface - UpdateVmInterface - ActivateDeactivateVmNic If the user already have a role that contains 'CONFIGURE_VM_NETWORK' action group, he should be granted with 'VmNetworkUser' role on the networks of that VMs for parity. Else, the actions he was able to perform will not be available to him any more. However, he won't be able to create/update nics wit
Re: [Engine-devel] Managing permissions on network
On 11/13/2012 03:21 PM, Itamar Heim wrote: > On 11/13/2012 03:17 PM, Moti Asayag wrote: >> On 11/13/2012 12:45 PM, Livnat Peer wrote: >>> On 13/11/12 10:57, Itamar Heim wrote: On 11/06/2012 02: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 > > High Level Feature Description > Admin > > For creating a network in a DC you need to be SuperUser or > DataCenterAdmin or NetworkAdmin on the DC. since there are multiple permissions among the differnet roles, maybe worth specifying the actual permissions (actiongroups), rather than just the roles? >>> >>> you can find this info in the wiki page itself,this is only high level >>> summary. >>> > After creating the network you can manipulate the network if you > are a DataCenterAdmin or NetworkAdmin on the relevant network (or the > whole DC). > For attaching the network to cluster user needs to be > NetworkAdmin > on the network (no requirement to have permission on the cluster) > ClusterAdmin cannot 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. I'm not sure above two lines are intuitive to manage (a network admin can manipulate a cluster, but the cluster admin can't change networks in the cluster? this means you must give network permissions, at DC level, so you can't limit an admin to network attach/detach to a specific cluster. >>> >>> That is true but looking on the alternative I think it make sense. >>> The alternative is to require two permissions for attaching a network to >>> a cluster one is networkAdmin (for editing network properties) on a >>> network and the other is networkAttach (a separate Role?) on a cluster >>> or the DC (if you want the user to be able to add the network for all >>> the clusters in the DC). >>> While I think the common use case is that a network administrator will >>> be able to attach the network to all the clusters I find the above >>> cumbersome and rather stick to the approach that you need only a single >>> permission and you can't limit the network manager to specific cluster. >>> >>> I think that if a requirement for limiting the network to specific >>> clusters comes from our users only then we should make the model more >>> strict and require two permissions. >>> >>> > The ClusterAdmin can change a network from required to > non-required for controlling the impact of the network within the > cluster. > For setting or manipulating a network on the host you need to be > host administrator on the host and you don't need to be network > administrator. > > 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. again, roles are just default roles, please specify the actual permission (actiongroup) >>> >>> take a look in the wiki for exact details (which role is composed out of >>> which action groups) > 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). or attached to user VMs. and need to handle case of network attached to template but user has no permission to that network? >>> >>> Interesting point, I think that if a user has permission to create a VM >>> from a specific template we should give him permission to use the >>> template networks on this VM implicitly upon the VM creation. >>> >>> I noticed the wiki page is missing which permission should be given to >>> users on which networks/VMs during upgrade - Moti? >>> >> >> Added: >> >> * '''VmNetworkUser''' role will be given to the user on each network >> attached to the VM/Template. >> * '''AdvancedVmNetworkUser''' role will be given to the user on each >> network attached to the VM with port-mirroring enabled. > > Hi Moti, > > I'm not sure what you mean by 'give to the user'. > if the VM has the permission, it doesn't mean the user should get it as > well, it only means user should be able to see networks their VM have > associated with. > > can you please elaborate m
Re: [Engine-devel] Managing permissions on network
On 11/13/2012 03:41 PM, Moti Asayag wrote: On 11/13/2012 03:19 PM, Itamar Heim wrote: On 11/13/2012 12:45 PM, Livnat Peer wrote: Interesting point, I think that if a user has permission to create a VM from a specific template we should give him permission to use the template networks on this VM implicitly upon the VM creation. having a permission to a template does not mean a permission to the default network of that VM, especially as we'll use templates more as instance types. If a user is the template's owner he should be capable to modify the its nics. I'd expect the user will modify the networks of the template only if he has permissions for the required network. true. Else, a user can update the template's nics to any of cluster's network and to create a VM with a network the user doesn't suppose to use. template having a default network doesn't mean user can create a vm with that network as well, if user doesn't have a permission to that network. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Managing permissions on network
On 11/13/2012 03:19 PM, Itamar Heim wrote: > On 11/13/2012 12:45 PM, Livnat Peer wrote: >> Interesting point, I think that if a user has permission to create a VM >> from a specific template we should give him permission to use the >> template networks on this VM implicitly upon the VM creation. > > having a permission to a template does not mean a permission to the > default network of that VM, especially as we'll use templates more as > instance types. If a user is the template's owner he should be capable to modify the its nics. I'd expect the user will modify the networks of the template only if he has permissions for the required network. Else, a user can update the template's nics to any of cluster's network and to create a VM with a network the user doesn't suppose to use. > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Managing permissions on network
On 11/13/2012 03:37 PM, Livnat Peer wrote: On 13/11/12 15:19, Itamar Heim wrote: On 11/13/2012 12:45 PM, Livnat Peer wrote: Interesting point, I think that if a user has permission to create a VM from a specific template we should give him permission to use the template networks on this VM implicitly upon the VM creation. having a permission to a template does not mean a permission to the default network of that VM, especially as we'll use templates more as instance types. Another alternative is to require permission on the network as well as the template. I must say I don't really like it, although I agree with your comment, we require too many operations for enabling a user to create a VM from template (permission on the template, quota on the storage, permissions on the network, next we'll require a PHD ;)). Anyone has a better idea? I assume most networks would be given either to 'everyone' or groups of users, not per user (and if the network is per user/tenant, then it must be done per user. i may not remember correctly, but i thought when giving quota to user we also give some permissions with it (on cluster and storage)? ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Managing permissions on network
On 13/11/12 15:19, Itamar Heim wrote: > On 11/13/2012 12:45 PM, Livnat Peer wrote: >> Interesting point, I think that if a user has permission to create a VM >> from a specific template we should give him permission to use the >> template networks on this VM implicitly upon the VM creation. > > having a permission to a template does not mean a permission to the > default network of that VM, especially as we'll use templates more as > instance types. Another alternative is to require permission on the network as well as the template. I must say I don't really like it, although I agree with your comment, we require too many operations for enabling a user to create a VM from template (permission on the template, quota on the storage, permissions on the network, next we'll require a PHD ;)). Anyone has a better idea? Livnat ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Managing permissions on network
On 11/13/2012 03:17 PM, Moti Asayag wrote: On 11/13/2012 12:45 PM, Livnat Peer wrote: On 13/11/12 10:57, Itamar Heim wrote: On 11/06/2012 02: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 High Level Feature Description Admin For creating a network in a DC you need to be SuperUser or DataCenterAdmin or NetworkAdmin on the DC. since there are multiple permissions among the differnet roles, maybe worth specifying the actual permissions (actiongroups), rather than just the roles? you can find this info in the wiki page itself,this is only high level summary. After creating the network you can manipulate the network if you are a DataCenterAdmin or NetworkAdmin on the relevant network (or the whole DC). For attaching the network to cluster user needs to be NetworkAdmin on the network (no requirement to have permission on the cluster) ClusterAdmin cannot 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. I'm not sure above two lines are intuitive to manage (a network admin can manipulate a cluster, but the cluster admin can't change networks in the cluster? this means you must give network permissions, at DC level, so you can't limit an admin to network attach/detach to a specific cluster. That is true but looking on the alternative I think it make sense. The alternative is to require two permissions for attaching a network to a cluster one is networkAdmin (for editing network properties) on a network and the other is networkAttach (a separate Role?) on a cluster or the DC (if you want the user to be able to add the network for all the clusters in the DC). While I think the common use case is that a network administrator will be able to attach the network to all the clusters I find the above cumbersome and rather stick to the approach that you need only a single permission and you can't limit the network manager to specific cluster. I think that if a requirement for limiting the network to specific clusters comes from our users only then we should make the model more strict and require two permissions. The ClusterAdmin can change a network from required to non-required for controlling the impact of the network within the cluster. For setting or manipulating a network on the host you need to be host administrator on the host and you don't need to be network administrator. 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. again, roles are just default roles, please specify the actual permission (actiongroup) take a look in the wiki for exact details (which role is composed out of which action groups) 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). or attached to user VMs. and need to handle case of network attached to template but user has no permission to that network? Interesting point, I think that if a user has permission to create a VM from a specific template we should give him permission to use the template networks on this VM implicitly upon the VM creation. I noticed the wiki page is missing which permission should be given to users on which networks/VMs during upgrade - Moti? Added: * '''VmNetworkUser''' role will be given to the user on each network attached to the VM/Template. * '''AdvancedVmNetworkUser''' role will be given to the user on each network attached to the VM with port-mirroring enabled. Hi Moti, I'm not sure what you mean by 'give to the user'. if the VM has the permission, it doesn't mean the user should get it as well, it only means user should be able to see networks their VM have associated with. can you please elaborate more. Thanks, Itamar ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Managing permissions on network
On 11/13/2012 12:45 PM, Livnat Peer wrote: Interesting point, I think that if a user has permission to create a VM from a specific template we should give him permission to use the template networks on this VM implicitly upon the VM creation. having a permission to a template does not mean a permission to the default network of that VM, especially as we'll use templates more as instance types. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Managing permissions on network
On 11/13/2012 12:45 PM, Livnat Peer wrote: > On 13/11/12 10:57, Itamar Heim wrote: >> On 11/06/2012 02: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 >>> >> >> >>> High Level Feature Description >>> Admin >>> >>> For creating a network in a DC you need to be SuperUser or >>> DataCenterAdmin or NetworkAdmin on the DC. >> >> since there are multiple permissions among the differnet roles, maybe >> worth specifying the actual permissions (actiongroups), rather than just >> the roles? >> > > you can find this info in the wiki page itself,this is only high level > summary. > >>> After creating the network you can manipulate the network if you >>> are a DataCenterAdmin or NetworkAdmin on the relevant network (or the >>> whole DC). >>> For attaching the network to cluster user needs to be NetworkAdmin >>> on the network (no requirement to have permission on the cluster) >>> ClusterAdmin cannot 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. >> >> I'm not sure above two lines are intuitive to manage (a network admin >> can manipulate a cluster, but the cluster admin can't change networks in >> the cluster? this means you must give network permissions, at DC level, >> so you can't limit an admin to network attach/detach to a specific cluster. >> > > That is true but looking on the alternative I think it make sense. > The alternative is to require two permissions for attaching a network to > a cluster one is networkAdmin (for editing network properties) on a > network and the other is networkAttach (a separate Role?) on a cluster > or the DC (if you want the user to be able to add the network for all > the clusters in the DC). > While I think the common use case is that a network administrator will > be able to attach the network to all the clusters I find the above > cumbersome and rather stick to the approach that you need only a single > permission and you can't limit the network manager to specific cluster. > > I think that if a requirement for limiting the network to specific > clusters comes from our users only then we should make the model more > strict and require two permissions. > > >>> The ClusterAdmin can change a network from required to >>> non-required for controlling the impact of the network within the >>> cluster. >>> For setting or manipulating a network on the host you need to be >>> host administrator on the host and you don't need to be network >>> administrator. >>> >>> 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. >> >> again, roles are just default roles, please specify the actual >> permission (actiongroup) > > take a look in the wiki for exact details (which role is composed out of > which action groups) >> >>> 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). >> >> or attached to user VMs. >> and need to handle case of network attached to template but user has no >> permission to that network? >> > > Interesting point, I think that if a user has permission to create a VM > from a specific template we should give him permission to use the > template networks on this VM implicitly upon the VM creation. > > I noticed the wiki page is missing which permission should be given to > users on which networks/VMs during upgrade - Moti? > Added: * '''VmNetworkUser''' role will be given to the user on each network attached to the VM/Template. * '''AdvancedVmNetworkUser''' role will be given to the user on each network attached to the VM with port-mirroring enabled. > >> > > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Managing permissions on network
On 13/11/12 10:57, Itamar Heim wrote: > On 11/06/2012 02: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 >> > > >> High Level Feature Description >> Admin >> >> For creating a network in a DC you need to be SuperUser or >> DataCenterAdmin or NetworkAdmin on the DC. > > since there are multiple permissions among the differnet roles, maybe > worth specifying the actual permissions (actiongroups), rather than just > the roles? > you can find this info in the wiki page itself,this is only high level summary. >> After creating the network you can manipulate the network if you >> are a DataCenterAdmin or NetworkAdmin on the relevant network (or the >> whole DC). >> For attaching the network to cluster user needs to be NetworkAdmin >> on the network (no requirement to have permission on the cluster) >> ClusterAdmin cannot 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. > > I'm not sure above two lines are intuitive to manage (a network admin > can manipulate a cluster, but the cluster admin can't change networks in > the cluster? this means you must give network permissions, at DC level, > so you can't limit an admin to network attach/detach to a specific cluster. > That is true but looking on the alternative I think it make sense. The alternative is to require two permissions for attaching a network to a cluster one is networkAdmin (for editing network properties) on a network and the other is networkAttach (a separate Role?) on a cluster or the DC (if you want the user to be able to add the network for all the clusters in the DC). While I think the common use case is that a network administrator will be able to attach the network to all the clusters I find the above cumbersome and rather stick to the approach that you need only a single permission and you can't limit the network manager to specific cluster. I think that if a requirement for limiting the network to specific clusters comes from our users only then we should make the model more strict and require two permissions. >> The ClusterAdmin can change a network from required to >> non-required for controlling the impact of the network within the >> cluster. >> For setting or manipulating a network on the host you need to be >> host administrator on the host and you don't need to be network >> administrator. >> >> 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. > > again, roles are just default roles, please specify the actual > permission (actiongroup) take a look in the wiki for exact details (which role is composed out of which action groups) > >> 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). > > or attached to user VMs. > and need to handle case of network attached to template but user has no > permission to that network? > Interesting point, I think that if a user has permission to create a VM from a specific template we should give him permission to use the template networks on this VM implicitly upon the VM creation. I noticed the wiki page is missing which permission should be given to users on which networks/VMs during upgrade - Moti? > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Managing permissions on network
On 11/06/2012 02: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 High Level Feature Description Admin For creating a network in a DC you need to be SuperUser or DataCenterAdmin or NetworkAdmin on the DC. since there are multiple permissions among the differnet roles, maybe worth specifying the actual permissions (actiongroups), rather than just the roles? After creating the network you can manipulate the network if you are a DataCenterAdmin or NetworkAdmin on the relevant network (or the whole DC). For attaching the network to cluster user needs to be NetworkAdmin on the network (no requirement to have permission on the cluster) ClusterAdmin cannot 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. I'm not sure above two lines are intuitive to manage (a network admin can manipulate a cluster, but the cluster admin can't change networks in the cluster? this means you must give network permissions, at DC level, so you can't limit an admin to network attach/detach to a specific cluster. The ClusterAdmin can change a network from required to non-required for controlling the impact of the network within the cluster. For setting or manipulating a network on the host you need to be host administrator on the host and you don't need to be network administrator. 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. again, roles are just default roles, please specify the actual permission (actiongroup) 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). or attached to user VMs. and need to handle case of network attached to template but user has no permission to that network? ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
