[DISCUSS] Changing description field for usages

[Rohit Yadav <ro...@shapeblue.com>]

All,


The current cloudstack usages (obtained via the listUsageRecords API) description is not very useful in most cases. A PR was merged last year [1] that changes the description to use uuids instead of internal IDs, however, this may have broken any external tooling/parser/billing-system that consumes the description text.


To further changes and fix/refactor usage description and responses, please discuss:


-  Is there room for further refactoring and changes to the description string to make them more useful? For example, the network usage records (bytes sent/received) currently has 'Host: id' that is irrelevant for the users/admins as it should not matter in most cases where the network usage was tracked (i.e. which VR).


- Moving forward can we assume that any external tool/parser/consumer of the usage response should only consume the key/value of the json/xml response? Therefore, can we refactor/change the description text to be more useful and meaningful for users/admins/operators, and for backward compatibility all existing keys/value in the API response would be honoured except for the description field more consumable for humans?


Thanks.


[1]  https://github.com/apache/cloudstack/pull/1940


- Rohit

<https://cloudstack.apache.org>



rohit.yadav@shapeblue.com 
www.shapeblue.com
Amadeus House, Floral Street, London  WC2E 9DPUK
@shapeblue
  
 

Re: [DISCUSS] Changing description field for usages

[Nikolaos Dalezios <da...@gmail.com>]

Hi everyone,
A few thoughts about event handling before commenting on Rohit's
message.....
1. Events should never be deleted from CS Management. Only the db admin
should be able to delete them. Deleting events by an admin should make the
invisible not really delete them.
2. Deleting or Archiving one or more events should trigger an Event
(event_deleted, event_archived)

I am currently working on implementing CADF event model (
https://www.dmtf.org/sites/default/files/standards/documents/DSP0262_1.0.0.pdf)on
CloudStack.
I have gone quite a long way with this attempt. Having studied event
creation and handling, and having in mind being forensically friendly (cadf
forensics is my thesis)  I think that the description field is a
concatenation/synthesis of other fields.

3. A "temp" or "buffer" type field should be added to Events table in order
to store all linear or non-linear data that are useful on Events Reporting.
4. From a forensics perspective admins should at least have a record
containing the source and the target of network traffic (e.g to trace a
ddos attack)
5. Although logging information (what to log) is most of the times a
developer's decision, following a specific standard can benefit the project
in many ways.
            a. It really guides the developer on what to log and what not
to log
            b. One can create a parser based on the log standard and not
the project (Cloudstack)

Nikos Dalezios


Στις Τρί, 19 Φεβ 2019 στις 12:41 μ.μ., ο/η Rohit Yadav <
rohit.yadav@shapeblue.com> έγραψε:

> All,
>
>
> The current cloudstack usages (obtained via the listUsageRecords API)
> description is not very useful in most cases. A PR was merged last year [1]
> that changes the description to use uuids instead of internal IDs, however,
> this may have broken any external tooling/parser/billing-system that
> consumes the description text.
>
>
> To further changes and fix/refactor usage description and responses,
> please discuss:
>
>
> -  Is there room for further refactoring and changes to the description
> string to make them more useful? For example, the network usage records
> (bytes sent/received) currently has 'Host: id' that is irrelevant for the
> users/admins as it should not matter in most cases where the network usage
> was tracked (i.e. which VR).
>
>
> - Moving forward can we assume that any external tool/parser/consumer of
> the usage response should only consume the key/value of the json/xml
> response? Therefore, can we refactor/change the description text to be more
> useful and meaningful for users/admins/operators, and for backward
> compatibility all existing keys/value in the API response would be honoured
> except for the description field more consumable for humans?
>
>
> Thanks.
>
>
> [1]  https://github.com/apache/cloudstack/pull/1940
>
>
> - Rohit
>
> <https://cloudstack.apache.org>
>
>
>
> rohit.yadav@shapeblue.com
> www.shapeblue.com
> Amadeus House, Floral Street, London  WC2E 9DPUK
> @shapeblue
>
>
>
>