Uploaded image for project: 'Fast Datapath Product'
  1. Fast Datapath Product
  2. FDP-1396

Log exact change that caused I-P recompute

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Undefined Undefined
    • None
    • None
    • OVN
    • Log exact change that caused I-P recompute
    • False
    • False
    • Hide

      Please mark each item below with ( / ) if completed or ( x ) if incomplete:

      ( ) The acceptance criteria defined below are met.

      ( ) The epics work is available in a downstream build (nightly/async or other)

      ( ) Test coverage is available in downstream CI if applicable

      ( ) All cards under the epic have been moved to Done

      ( ) Failed Test Plans have bugs added as children to the epic/feature.

      Show
      Please mark each item below with ( / ) if completed or ( x ) if incomplete: ( ) The acceptance criteria defined below are met. ( ) The epics work is available in a downstream build (nightly/async or other) ( ) Test coverage is available in downstream CI if applicable ( ) All cards under the epic have been moved to Done ( ) Failed Test Plans have bugs added as children to the epic/feature.
    • In Progress
    • ovn25.09-25.09.0-alpha.187.el9fdp
    • rhel-9
    • rhel-net-ovn
    • 33% To Do, 0% In Progress, 67% Done
    • ssg_networking

      This epic tracks all the effort needed to deliver the solution related to the feature request described below.

      What's the feature?

      We have a lot of handlers in the incremental engine, and we cannot handle all changes incrementally. We would have additional callback for `engine_add_input()` that would dump/format the failure reason. The reason would would be set to object that caused the inc processing to fail e.g. sbrec_datapath. We could have macro for default DB dumps that would print the row with clearly marked if it's new/deleted or columns that were updated.
       

      Why is it needed?

      We could use this info to debug incremental processing more easily. A lot of time it's guess work what caused recompute of certain nodes. With this we could ask customer to enable this extra logging and have the info without DB correlations.
       

      Who will benefit? 

      Developers and to some extent customers as it will be easier for us to debug.

              lorenzobianconi lorenzo bianconi
              amusil@redhat.com Ales Musil
              Aniss Loughlam Aniss Loughlam
              OVN
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: