Hi Nitin,
That is correct they would be created as admin/domain admin and then
assigned to the end user account using assignVirtualMachine api which
Jessica looks like she is adding the functionality to the UI in 4.2.1
(CLOUDSTACK-4796).
In order for this use case to be functional through the UI
There was some discussion about a new RBAC framework sometimes back. It should
have some provision to address the below use case.
On 08-Oct-2013, at 10:55 PM, Nitin Mehta wrote:
> Chris - Thanks for putting in the use case.
> As you said suggestion 1 fits in fine for your use case.
> One clarif
Chris - Thanks for putting in the use case.
As you said suggestion 1 fits in fine for your use case.
One clarification though - would you be creating the vms as an admin and
then using assignVirtualMachine to assign the vms to the end user ?
This is preferable for vm usage calculations.
Thanks,
-N
Hi Nitin,
For our use case we would be looking at having a separate "deployment
portal" which would get the user to provide the necessary information
for deploying their instance i.e template, ram, cpu etc and would
create a work order for the administrators to do the deployment. When
the instance
You can change the deployVirtualMachine Api attributes to ROOT admin
only(currently allowed to all). You can change that in
commands.properties.in
There is something else as well which you can leverage and see if it fits
your use case.
In current code base, admin can create vm instances using the
Hi,
Is it possible to prevent users from deploying their own instances but
still have access to cloudstack for creating snapshots and powering on/off
etc? Their instances would be assigned from an admin account. I see the
option on the user account for instance limits, but setting that to 0
preven