Feature: Domain Tagging

[ianc769]

The required feature described as a wish

User Story: As a CloudStack Administrator/Operator, I want to add custom key-value tags to domains so that I can categorize, filter, and organize domains for improved management and accurate chargeback allocation. This feature should support multiple tags per domain, provide filtering capabilities in the UI and API, and enable tag-based reporting for cost allocation and billing purposes.

Core Requirements: Implement CRUD operations for domain tags through both UI and API, support tag-based filtering in domain lists, include tag data in usage/billing reports, and ensure proper role-based access control where domain admins can manage their own domain tags while root admins have full access. Tags should follow a key-value format with reasonable character limits and validation, enabling use cases such as department categorization (e.g., "department:engineering"), cost center allocation (e.g., "cost-center:CC-1001"), and project tracking for streamlined operations and financial reporting.

[DaanHoogland]

@ianc769 this sounds like a good use of comment/annotations, can you use these?

[DaanHoogland]

@ianc769 , I saw @shwstppr ’s implementation and it looks good, but I do not see it as useful. usualy tags are used for matching (hosts to compute offerings, templates to storage, etc) These tags do nothing as of yet. These are also not added to usage data, so for billing you would need outside scripting. Are you sure about the use-case/scenario and how it is helped by the PR #11964 ?

[shwstppr]

@DaanHoogland I don't know about the specific use-case for @ianc769 but ACS does provide key-value tags for several other resources as well and they are not used for deployment mapping purposes so I do not see any harm in extending it for domains. Though such tags may be accessible to all

[ianc769]

@ianc769 , I saw @shwstppr ’s implementation and it looks good, but I do not see it as useful. usually tags are used for matching (hosts to compute offerings, templates to storage, etc) These tags do nothing as of yet. These are also not added to usage data, so for billing you would need outside scripting. Are you sure about the use-case/scenario and how it is helped by the PR #11964 ?

Originally I was thinking something along the lines that AWS has: https://www.hashicorp.com/en/blog/default-tags-in-the-terraform-aws-provider

provider "aws" {
 default_tags {
   tags = {
     Environment = "Test"
     Owner       = "TFProviders"
     Project     = "Test"
   }
 }
}

For our use case this is for cost allocation; If I have product-alpha.my.domain.local as a domain, I can look up metadata about it like

• cost code
• owner
• email

Now instead of tagging every object in the domain, I can just look at the domain itself (and all its resources with other API calls) to find out who owes me money 😂

Annotations would work, but I think this is much cleaner overall. Thoughts?

[DaanHoogland]

I am fine if you can implement your use-case with it @ianc769 , that is what the project is for. Can you test the version from the PR?

[ianc769]

I am fine if you can implement your use-case with it @ianc769 , that is what the project is for. Can you test the version from the PR?

Sorry I've been out of office remote doing some work, I'll try and check next week when I'm back!

[ianc769]

I am fine if you can implement your use-case with it @ianc769 , that is what the project is for. Can you test the version from the PR?

Was able to get some testing in and this looks awesome, This will help us easily allocate cost and assign monitoring 👍

[DaanHoogland]

I am fine if you can implement your use-case with it @ianc769 , that is what the project is for. Can you test the version from the PR?

Was able to get some testing in and this looks awesome, This will help us easily allocate cost and assign monitoring 👍

thanks @ianc769 , we’ll run regression tests and merge. when all well it will be in 4.23 (no guarantee yet)