Improvement request: Allow normal users to select pod or cluster while deploying an instance

[jmkleijer]

ISSUE TYPE

• Bug Report

COMPONENT NAME

UI

CLOUDSTACK VERSION

4.19.1.2

CONFIGURATION

We have 2 clusters called CL01 and CL02. Both of these clusters are dedicated to Account A.
Account A has a role of "User".

OS / ENVIRONMENT

Red Hat Enterprise Linux 9.0 using KVM

SUMMARY

User accounts in account A have access to 2 different clusters called CL01 and CL02 which are dedicated to account A.
If a user creates a new instance through the UI, the UI doesn't give the user a choice on which cluster they want their instance created. The UI does this selection for them.

If the user creates the instance via the API (ansible script), they are able to choose the cluster and the instance gets deployed.
This tells me that the user (role) does not limit the user in choosing the cluster on which the new instance should land.

If a Root Admin creates a new instance via the UI, they however are able to choose the POD, cluster and even host so the functionality is there in the UI. It's just not given to someone with a "User" role.

STEPS TO REPRODUCE

Create a new account called A and assign it the "User" role.
Create a cluster and dedicate this cluster to account A.
Create a second cluster and dedicate this cluster to account A.
As a user from account A, login to the UI and create a new instance.
After selecting the zone in which the new instance should be created, try to select the pod, cluster or host. These options will not be given.

Perform the same steps but now as a Root Admin user and you will be given the choice of pod, cluster and/or host upon creation of a new instance.

EXPECTED RESULTS

After logging in with the role "User", I was expecting to be able to select a cluster on which I could deploy my new instance.

ACTUAL RESULTS

While logged in as someone with the role "User", I'm not given the choice of selecting the pod, cluster or host upon which my new instance should land.

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template!

[DaanHoogland]

@jmkleijer , have you tried if 4.20 or older versions work with this scenario?
My guess is that this is not allowed on purpose, making this not a bug. We can still honour the issue as an improvement request though.

[jmkleijer]

@DaanHoogland I haven't tried this yet with 4.20 (or older versions for that matter) I'll see if I can get around to that to see if there's a difference.
If it's not allowed on purpose, what would the purpose be?
Root Admin can see and select the zone, pod, cluster and host on which to deploy the VM on. Why not a regular user? If it's capabilities, then what capabilities would need to be added to make this work?

[DaanHoogland]

@DaanHoogland I haven't tried this yet with 4.20 (or older versions for that matter) I'll see if I can get around to that to see if there's a difference. If it's not allowed on purpose, what would the purpose be? Root Admin can see and select the zone, pod, cluster and host on which to deploy the VM on. Why not a regular user? If it's capabilities, then what capabilities would need to be added to make this work?

@jmkleijer , I am not sure of your use, i.e. enterprise/private cloud/public cloud.. Especially in a public cloud an operator would not want to allow this. That does not mean that it is not a valid use case for you!

[jmkleijer]

@DaanHoogland
It's a big enterprise (basically a private cloud) where we want to give users a bit more control over their resources.
I mean, if we allow it via the API, then why not via the UI? (and if this is indeed something that's missing from the UI then indeed, this could be better marked as an improvement request)

[DaanHoogland]

right, as you say it is only UI I am marking it for 4.19.2 for now (no guarantee it will make it)

[DaanHoogland]

@jmkleijer , I discussed off-line with some people and you might implement this using a custom role assigning all the necessary APIs to the users. I am not sure what the missing APIs for the user are, but they would need all list APIs for zones, pods, clusters and hosts at least.

Does this sound feasible?

[weizhouapache]

@jmkleijer , I discussed off-line with some people and you might implement this using a custom role assigning all the necessary APIs to the users. I am not sure what the missing APIs for the user are, but they would need all list APIs for zones, pods, clusters and hosts at least.

Does this sound feasible?

@DaanHoogland
it looks podId and clusterId are only available for admin, they are in the class

public class DeployVMCmdByAdmin extends DeployVMCmd implements AdminCmd

[DaanHoogland]

it looks podId and clusterId are only available for admin, they are in the class

public class DeployVMCmdByAdmin extends DeployVMCmd implements AdminCmd

ok, but that would mean the API doens't work either. In that case it means a change anyway.

[jmkleijer]

Is there a particular reason why podId and clusterId are only available to the admin? (I understand they're made available through a class that's Admin only but could this be made publicly available?) Kind regards, Jeroen Kleijer

…

On Thu, Dec 12, 2024 at 12:56 PM Wei Zhou ***@***.***> wrote: @jmkleijer <https://github.com/jmkleijer> , I discussed off-line with some people and you might implement this using a custom role assigning all the necessary APIs to the users. I am not sure what the missing APIs for the user are, but they would need all list APIs for zones, pods, clusters and hosts at least. Does this sound feasible? @DaanHoogland <https://github.com/DaanHoogland> it looks podId and clusterId are only available for admin, they are in the class public class DeployVMCmdByAdmin extends DeployVMCmd implements AdminCmd — Reply to this email directly, view it on GitHub <#10069 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABK4Y2HYG2EAJSVAM72AWIT2FF2WFAVCNFSM6AAAAABTI6AFO6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZYGY4TQMJYGQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[DaanHoogland]

not sure @jmkleijer , the initial thought is that these parameters should not be there for normal users, keeping a public cloud in mind. In you case you have a use case to make them available. I think we'll have to think of a way to make this tweakable.

[weizhouapache]

not sure @jmkleijer , the initial thought is that these parameters should not be there for normal users, keeping a public cloud in mind. In you case you have a use case to make them available. I think we'll have to think of a way to make this tweakable.

I think it makes perfect sense for public cloud providers, that the list of pods/clusters/hosts should not be visible for the non-admin users.

[jmkleijer]

I think it does indeed make perfect sense for public cloud providers, but as more and more companies have to renew their licenses for their virtualization environment, you're probably going to find more and more people looking at ACS as an alternative option for this :)

…

On Thu, Dec 12, 2024 at 1:53 PM Wei Zhou ***@***.***> wrote: not sure @jmkleijer <https://github.com/jmkleijer> , the initial thought is that these parameters should not be there for normal users, keeping a public cloud in mind. In you case you have a use case to make them available. I think we'll have to think of a way to make this tweakable. I think it makes perfect sense for public cloud providers, that the list of pods/clusters/hosts should not be visible for the non-admin users. — Reply to this email directly, view it on GitHub <#10069 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABK4Y2AXIPSM6KK7EAFMW3D2FGBL3AVCNFSM6AAAAABTI6AFO6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZYHAZDIMRYGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[weizhouapache]

I think it does indeed make perfect sense for public cloud providers, but as more and more companies have to renew their licenses for their virtualization environment, you're probably going to find more and more people looking at ACS as an alternative option for this :)

@jmkleijer
I changed the title of this issue.
I think this is a valid improvement request, let's see what other members say.