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.
Thanks, -Syed On Tue, Mar 6, 2018 at 4:47 AM, Dag Sonstebo <dag.sonst...@shapeblue.com> wrote: > 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. > > Regards, > Dag Sonstebo > Cloud Architect > ShapeBlue > > 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 > 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? > > Thanks, > -Syed > > > > dag.sonst...@shapeblue.com > www.shapeblue.com > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > @shapeblue > > > >
