<Please fill out the Overview, Design and User Experience sections for an initial review of the proposed feature.>

Overview

<Briefly describe the problem being solved, not how the problem is solved, just focus on the problem. Think about why the feature is needed, and what is the relevant context to understand the problem.>

Currently eventlogs are saved when important node or service

Design

<Describe how the problem is fixed. Include all affected components. Include diagrams for clarity. This should be the longest section in the document. Use the sections below to call out specifics related to each aspect of the overall system, and refer back to this section for context. Provide links to any relevant external information.>


Eventlog entries are saved in the agent database. 2 DELETE APIs should be added at the agent side to delete the eventlog:

  1. DELETE /eventlog?timestamp=<timestamp>&severity=<severity_level>

    1. to delete eventlog entries matching selector strings provided by the caller

    2. the selectors will be the options currently available for choosing eventlogs to be returned by hzn eventlog list -s

      1. the types of selectors are timestamp, severity, message, event_code, source_type, agreement_id, service_url

      2. multiple selectors can be included and they will be "and"ed together so a log must match all selectors to be deleted


  2. DELETE /eventlog/prune: to delete all the eventlog entries for previous registrations


Two CLIs commands will use the above APIs:

  1. hzn eventlog delete -s <selector>

  2. hzn eventlog prune


In the future, this cleanup process could be added to node management policy (NMP) workflow. Instead of executing the delete on each agent, leveraging NMP allows the admin to cleanup eventlog entries for target group of nodes. The following is an example of a subfield to add to the existing NMP structure. 


"agent_data_policy": {

    "eventlog": {

          "prune": false,

          "selectors": ["timestamp < time", 

            "severity_level < 3"]

      }

}


Once a node has downloaded a matching NMP, a subworker will run periodically and delete all eventlogs matching the selectors or from previous registrations if "prune" is set to true.

User Experience

<Describe which user roles are related to the problem AND the solution, e.g. admin, deployer, node owner, etc. If you need to define a new role in your design, make that very clear. Remember this is about what a user is thinking when interacting with the system before and after this design change. This section is not about a UI, it's more abstract than that. This section should explain all the aspects of the proposed feature that will surface to users.>


Command Line Interface

<Describe any changes to the hzn CLI, including before and after command examples for clarity. Include which users will use the changed CLI. This section should flow very naturally from the User Experience section.>


External Components

<Describe any new or changed interactions with components that are not the agent or the management hub.>


Affected Components

<List all of the internal components (agent, MMS, Exchange, etc) which need to be updated to support the proposed feature. Include a link to the github epic for this feature (and the epic should contain the github issues for each component).>


Security

<Describe any related security aspects of the solution. Think about security of components interacting with each other, users interacting with the system, components interacting with external systems, permissions of users or components>


APIs

<Describe and new/changed/deprecated APIs, including before and after snippets for clarity. Include which components or users will use the APIs.>


Build, Install, Packaging

<Describe any changes to the way any component of the system is built (e.g. agent packages, containers, etc), installed (operators, manual install, batch install, SDO), configured, and deployed (consider the hub and edge nodes).>


Documentation Notes

<Describe the aspects of documentation that will be new/changed/updated. Be sure to indicate if this is new or changed doc, the impacted artifacts (e.g. technical doc, website, etc) and links to the related doc issue(s) in github.>


Test

<Summarize new automated tests that need to be added in support of this feature, and describe any special test requirements that you can foresee.>

  • No labels