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.ya...@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.ya...@shapeblue.com > www.shapeblue.com > Amadeus House, Floral Street, London WC2E 9DPUK > @shapeblue > > > >
