That's something I hadn't thought of. Adding tags when the usage job runs
sounds like a better approach. It will also limit the potential number of
places where changes need to be made. I'm planning to include tags as an
array in a field or possible comma separated values.
On Tue, Mar 6, 2018 at 4:47 AM, Dag Sonstebo <dag.sonst...@shapeblue.com>
> Hi Syed,
> 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.
> Dag Sonstebo
> Cloud Architect
> On 05/03/2018, 20:21, "Syed Ahmed" <sah...@cloudops.com> wrote:
> Hi Guys,
> Currently the usage record in CloudStack doesn't include the resource
> and we are having more and more use cases where we feel like including
> will immensely help with the chargeback logic. Currently, we go back
> query Cloudstack to give us the tags associated with a resource. What
> you guys think about adding tags as a field in the usage record?
> 53 Chandos Place, Covent Garden, London WC2N 4HSUK