cloudstack icon indicating copy to clipboard operation
cloudstack copied to clipboard

template visibility in subdomains

Open andre-pf opened this issue 1 year ago • 2 comments

ISSUE TYPE
  • Improvement Request
COMPONENT NAME
UI
CLOUDSTACK VERSION
4.19.0.0
SUMMARY

We are a school and use domains for different groups of classes. It would be good if there was an option for public templates/ISOs to be visible in subdomains as well. We cannot find a way to display templates/ISOs in the parent domain and in the subdomains. With the setting share.public.templates.with.other.domains we can share templates with all domains or only with the current domain. However, there is no way to share the template only in the parent domain and in the subdomain. This would be a good extension function. With shared networks, for example, this is possible. With a parameter such as share.public.templates.with.sub.domains this could be achieved. For example: share.public.templates.with.other.domains=false share.public.templates.with.sub.domains=true

andre-pf avatar Jul 01 '24 10:07 andre-pf

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

boring-cyborg[bot] avatar Jul 01 '24 10:07 boring-cyborg[bot]

@andre-pf , valid request but can you expand on what you want with the share.public.templates.with.other.domains=false , please? it does not seem to add value to you functionality.

DaanHoogland avatar Jul 01 '24 14:07 DaanHoogland

This was an example. If share.public.templates.with.other.domains=false public templates are only visible in the current domain of the template (and not in subdomains). This is how it is implemented now. If the new parameter is e.g. share.public.templates.with.sub.domains=true public templates are also visible in subdomains. This allows us to achieve consistent behavior. For shared networks (or even domain admins) it is already like this. They can be made visible in the subdomains too. But are not visible in other domains. For us this will be very useful because we have many independent domains with subdomains. All parent domains have their own template for educational purposes. These templates are important for the parent domains and subdomains. The other domains do not need to see these public templates.

andre-pf avatar Jul 02 '24 09:07 andre-pf

This was an example. If share.public.templates.with.other.domains=false public templates are only visible in the current domain of the template (and not in subdomains). This is how it is implemented now. If the new parameter is e.g. share.public.templates.with.sub.domains=true public templates are also visible in subdomains. This allows us to achieve consistent behavior. For shared networks (or even domain admins) it is already like this. They can be made visible in the subdomains too. But are not visible in other domains. For us this will be very useful because we have many independent domains with subdomains. All parent domains have their own template for educational purposes. These templates are important for the parent domains and subdomains. The other domains do not need to see these public templates.

ok, it seems you are using two switches for the same functionality, but I get it now.

DaanHoogland avatar Jul 02 '24 12:07 DaanHoogland

@DaanHoogland Hi, I'm a colleague of @andre-pf, we had set up and now manage our cloustack implementation together. It's not two switches for the same functionality, there should be two switches.

First one, already implemented in Cloudstack:
share.public.templates.with.other.domains : If true, template is visible in all other domains. If false, Template is visible only in the current domain.

We would like to have a template visible in the current domain and if the "new" switch is "true", also in subdomains from the current domain.

Wish: Second, not actually implemented Switch would be great: share.public.templates.with.sub.domains: If true, template is visible in current and all subdomains of the current domain. If false, Template is visible just in current domain.

So, two switches for two functionalities.

The actual behavior is not understandable, at least for us. If a Domain Admin today is creating a template and set it visible to all domains, the admin ist sharing the template system wide. Why is this?

Have a great Day and thanks in advance!

tom-osz avatar Jul 08 '24 10:07 tom-osz

@DaanHoogland We are still struggling with this in our implementation. There is a desire for subdomains to be able to provide templates to their respective sub domains.

In our situation, we have the following values: allow.public.user.templates = false (We would like to set this to True, but this scenario prevents us from doing it) share.public.templates.with.other.domains = true

Scenario: Templates/ISO's in Root that are Public. All subdomains can see these as expected. (This is why share.public.templates.with.other.domains is true)

2 Subdomains:

  • Root/Domain1/Sub1
  • Root/Domain2/Sub2

Domain1 uploads a template or iso. This assuming an Admin has made it public in our case. This allows all users in Domain1 and Sub1, but it also allows Domain2 and Sub2 to see it.

This behavior seems to ignore hierarchy. Maybe there are other users with uses cases for this, but if you have instances in Domain1, there is no way to share those instances with Domain2.

I also question if it's actually a bug because in the above scenario users in Domain2 and Sub2 can't actually use the public iso/template that is in Domain1.

scottsignal avatar May 02 '25 18:05 scottsignal

This behavior seems to ignore hierarchy. Maybe there are other users with uses cases for this, but if you have instances in Domain1, there is no way to share those instances with Domain2.

instances are a more private resource so only the owner and admins can set them. No way to make instances public. for templates, users can make them public. However, many years ago, public templates can be viewed by all domains and users. with the setting share.public.templates.with.other.domains, public templates can be limited to the domain of the owner and sub-domains (if share.public.templates.with.other.domains = false), not globally.

I also question if it's actually a bug because in the above scenario users in Domain2 and Sub2 can't actually use the public iso/template that is in Domain1.

do you mean users in Domain2 and Sub2 can see the public template in Domain1, but cannot use it ? if it is confirmed, it is a bug I think

weizhouapache avatar May 02 '25 19:05 weizhouapache

instances are a more private resource so only the owner and admins can set them. No way to make instances public. for templates, users can make them public.

Apologies if I make it sound like this is something we wanted. This isn't something being asked for. I just was using it as an example for hierarchy. Technically, you could adherently make a private template public this way. IE take a volume (containing private data) and turn it into a Template and make it public. Assuming both values are set to true. This is an unlikely scenario, but possible if we are talking about public vs private.

From my viewpoint root/Domain 1 and root/Domain 2 should under no circumstances be able to see any resources under each other (including templates/isos) which matches the behavior of instances/networks/etc in Cloudstack.

do you mean users in Domain2 and Sub2 can see the public template in Domain1, but cannot use it? if it is confirmed, it is a bug I think

I was trying to use this to support why I think uploading an iso/template to Domain1 and it being visible from Domain 2 and Sub 2 is a bug since I have found no way to deploy or attach them as they don't appear in the instance creation wizard or attachable as an ISO to an instance.

In our case we just are not allowing Public Templates in Sub-domains because of the above. The problem in our use case is certain use cases where there are many subdomains under a domain, and you have to upload that ISO/Template to every single subdomain. and this consumes resources.

scottsignal avatar May 02 '25 19:05 scottsignal

Apologies if I make it sound like this is something we wanted. This isn't something being asked for. I just was using it as an example for hierarchy. Technically, you could adherently make a private template public this way. IE take a volume (containing private data) and turn it into a Template and make it public. Assuming both values are set to true. This is an unlikely scenario, but possible if we are talking about public vs private.

From my viewpoint root/Domain 1 and root/Domain 2 should under no circumstances be able to see any resources under each other (including templates/isos) which matches the behavior of instances/networks/etc in Cloudstack.

It is true.

I was trying to use this to support why I think uploading an iso/template to Domain1 and it being visible from Domain 2 and Sub 2 is a bug since I have found no way to deploy or attach them as they don't appear in the instance creation wizard or attachable as an ISO to an instance.

If the template/iso is public, and global setting is true, the template/iso should be visible and usable by other domains. It might be an api or ui issue if the behavior is different.

Need testing.

In our case we just are not allowing Public Templates in Sub-domains because of the above. The problem in our use case is certain use cases where there are many subdomains under a domain, and you have to upload that ISO/Template to every single subdomain. and this consumes resources.

weizhouapache avatar May 03 '25 10:05 weizhouapache

If the template/iso is public, and global setting is true, the template/iso should be visible and usable by other domains.

I still think Templates/ISO's should follow the domain hierarchy no matter what these values are set to.

scottsignal avatar May 15 '25 20:05 scottsignal