Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cloudstack should not allow to create resources with same name #8416

Closed
kiranchavala opened this issue Dec 29, 2023 · 3 comments
Closed

Cloudstack should not allow to create resources with same name #8416

kiranchavala opened this issue Dec 29, 2023 · 3 comments

Comments

@kiranchavala
Copy link
Contributor

ISSUE TYPE

Enhancement/Improvement request

COMPONENT NAME

Component: UI/API/

CLOUDSTACK VERSION

Cloudstack version 4.18

SUMMARY

Cloudstack should not allow to create resources with same name

Currently, Cloudstack doesn't allow to creation of the following resources with the same name

vm name, ssh key pairs, User-data, affinity groups, Instance groups, projects, accounts, Domains , users , Roles , Vpn users.

For example, for vm-name it throws the following exception

same-name

But Cloudstack allows the creation of the following resources with the same name

volume, snapshot, template/Iso, Networks, VPC, Service offerings, Kubernetes cluster

To maintain consistency across we should not allow to create the resources if there are already active resources with the same name

It will help the admin/user to manage the resources better

Expected behaviour

Cloudstack should validate the resource name before creating them.
It should check if any existing active resources are present before creating them.

If they are present , cloudstack should throw a popup

@DaanHoogland
Copy link
Contributor

@kiranchavala I think it shsouldn't be a problem to have resources with the same name. In some cases it is even harmful if we cannot; If users cannot see each others resources they should not get a hint that the other have a resource by a name by refusing it. There can always also be users that see both.
In addition to the security implications of not allowing it, we'll also have a backwards compatability issue if we refuse it.

@DaanHoogland
Copy link
Contributor

@kiranchavala is my explanation to your satisfaction? Can we close this issue?

@kiranchavala
Copy link
Contributor Author

@DaanHoogland thanks for looking into it, I agree it could cause backward compatability issue .

we can close the issue

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants