rajujith commented on PR #10755: URL: https://github.com/apache/cloudstack/pull/10755#issuecomment-2829342277
> > @DaanHoogland This solves the problem for time being. But for the long term we may want to record different usage events like you mentioned here [#10687 (comment)](https://github.com/apache/cloudstack/issues/10687#issuecomment-2804174489) and create two separate usage types like we already have for running and allocated VM. > > @rajujith after looking into and understanding how the network Usage event model works (or was supposed to work), I do not think anymore that it is necessary to add separate events for `IMPLEMENT` and `STOP` (at least in the context of Usage. Maybe it makes sense for the standard events). The network's new state is in included in the `NETWORK.UPDATE` event. This can be used to identify when a network transitioned from allocated to implemented and vice-versa. > > Also, we include the network's state in the usage record during that period. This can be used to distinguish between allocated and implemented usage. > > When the running and allocated virtual machine usage types were introduced, we did not have the state column. I'm not sure why it was introduced that way (two different usage types instead of including the state in the usage record), so genuine question: is there an advantage of having two separate usage types just to distinguish between allocated and implemented? For me, it seems unnecessary. @winterhazel I can only imagine a scenario where the operator would want to bill allocated and Implemented networks at a different rate or as separate products. If these usages can be differentiated in the API response that should be enough. However separate usage type makes a clear distinction in my head, may be its not necessary. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
