I see the use case and yes this could work – couple of things:
- Any resource could have multiple tags – would they all be included as an
array in a single DB field, or would you want to just define one specific tag (
e.g. “owner” or “costcentre”) and include that single field?
- How granular would you make it – do you expect to be able to distinguish that
a VM had “costcentre” tag 100 for the first 10 days of a month and tag 200 for
the remainder? The problem with this would be that tags would potentially
change mid month without there being an event tied to it, so all you would see
is the startVM and stopVM events with different tags and no way to determine
when it changed. You would potentially be better just parsing the tags when the
usage job runs and include them in cloud_usage.cloud_usage only – i.e. possibly
not even in the helper tables.
On 05/03/2018, 20:21, "Syed Ahmed" <sah...@cloudops.com> wrote:
Currently the usage record in CloudStack doesn't include the resource tags
and we are having more and more use cases where we feel like including tags
will immensely help with the chargeback logic. Currently, we go back and
query Cloudstack to give us the tags associated with a resource. What do
you guys think about adding tags as a field in the usage record?
53 Chandos Place, Covent Garden, London WC2N 4HSUK