| Summary: | [RFE] - Add event& audit logs so the support/developer/QE can undestand easily what was configured & when | ||
|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Avihai <aefrat> |
| Component: | RFEs | Assignee: | Rob Young <royoung> |
| Status: | CLOSED DEFERRED | QA Contact: | Lukas Svaty <lsvaty> |
| Severity: | low | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.1.0 | CC: | aefrat, bugs |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | Flags: | oourfali:
ovirt-future?
rule-engine: planning_ack? rule-engine: devel_ack? rule-engine: testing_ack? |
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-04-01 14:47:28 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Infra | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Avihai
2016-11-22 16:46:51 UTC
engine.log is good enough for R&D, though it can be improved and will be over time. I'm not sure I understand what is requested here. To clarify : This RFE comes from working with the following 2 logs in IBM storage (XIV/SVC) devices and also in many cisco switches I worked on : 1) audit log : That will contain the exact CLI/REST/webgui commands with relevant time stamp . It was much clearer & easier to know what was configured by the customer/Admin by adding a simple text file that contain all configuration & the status of each configuration action with a time stamp much like its seen in GUI event log . 2) event log : Same as seen in GUI today , just put in a log file . Why do it ? It clarified exactly what was configured &when clear and simple much less time consuming way than using the engine/vdsm log. Yes , we do have the engine.log but trying to understand what was configured and when over a long period of time is not intuitive & much more time consuming working with the engine.log . So why not use GUI event log you will ask ? well .. its much easier to parse & search for events using a simple text file . I hope this clarify this request . please ping me for more details. Also As I noticed via engine/vdsm log DE/QE does not know if the configuration done by the user/admin was done via : - WEBGUI admin - WEBGUI user - REST API - CLI please also add to the event&audit logs another field that shows the source of the initiated configuration . I must admin I still don't follow. I'm putting it on future to examine that when relevant. Hi Oved , I will try to clarify more : This RFE is about have a log file with shows in a clear way table like format with the following columns : 1) what was configured 2) how it was configured meaning via GUI/API/CLI . 3) when it was configured (timestamp) 4) config succeeded/failed That's it , I hope this is more clear . In most products I worked with IBM/cisco this was provided & was a great way to retrace customer issues for dev/QA/support . An example from IBM product(XIV) can be see at : https://www.ibm.com/support/knowledgecenter/STJTAG/com.ibm.help.xiv.doc/Gen3/xiv_mt4_ch03_017.html IMHO the need is real and can make immediate impact improving: 1) Root cause analysis faster and easier . 2) Reproduction by dev/QA shorten times . 3) Shorten Support team effort to understand what happened at a costumer site. In my opinion this RFE should not be deferred to a future unknown time . ratamir / gklein , please escalate this if you feel the same way . For any additional Q's please ping me . We didn't get to this bug for more than 2 years, and it's not being considered for the upcoming 4.4. It's unlikely that it will ever be addressed so I'm suggesting to close it. If you feel this needs to be addressed and want to work on it please remove cond nack and target accordingly. ok, closing. Please reopen if still relevant/you want to work on it. ok, closing. Please reopen if still relevant/you want to work on it. |