This task is tracking the test case writing activities to cover the feature request described below.

The goal of this refactor is to allow for composable services to create logical flows without interfering with the logical flow creation/destruction as currently implemented within the en_lflow engine node in ovn-northd.

Currently, the en_lflow node has restrictions that make this difficult. In order to get around these, we must do the following at a minimum:

• Convert lflow-mgr functions not to take ls_datapaths and lr_datapaths as arguments. Most functions in lflow-mgr.c take two ovn_datapaths arguments: the logical routers and logical switches. Internal logic within those functions then determines which of these to use. Composable services will be adding logical flows that are not associated with logical routers or logical switches. Therefore, the arguments need to be revised to allow for non-switch and non-router datapaths to be used.
• Move the ovn_datapath indexing to the datapath sync code. Logical flows keep track of relevant datapaths through a bitmap. This bitmap corresponds to the indexes assigned to ovn_datapaths in en_northd. Using these indexes allows for a lightweight representation of relevant datapaths in the logical flow. However, since this indexing is applied to ovn_datapaths in en_northd, they only exist for logical switches and logical routers. Indexing of datapaths needs to be moved to the datapath syncing code. ovn_datapath and logical flow indexes will refer to these synced datapaths instead.
• Remove all use of ovn_datapath from the lflow-mgr code. Composable services do not use ovn-northd, and therefore will not have the ovn_datapath struct. logical flows really don't need the ovn_datapath anyway, since the only part of the struct they use is the southbound datapath. The lflow-mgr code should be converted to use ovn_synced_datapath objects instead.
• Convert ovn_stage from an enum to a struct. ovn_stage is currently an enum whose bits represent ingress/egress, logical switch/logical router, and the logical table number. This is not conducive to datapath types that are not logical routers or switches.

The above points must be dealt with as part of the refactor. The below points are optional.

• Separate en_lflow into two nodes: one for building lflows and one for syncing lflows. en_lflow is responsible for calculating all logical flows and syncing them to the southbound database within the same incremental engine node. Composable services could calculate their logical flows in en_lflow as well. The composable services could provide lflow_refs so that only their flows are recalculated, not affecting the rest of the flows. The downside to this is that if composable service configuration changes and requires a full recompute of composable service-related nodes (including lflows), then this will also cause a full recompute of en_lflow as well. A solution is to separate lflow building and lflow syncing into separate nodes. en_lflow can build all of the logical flows it is responsible for, and a separate en_lflow_sync node can take logical flows from multiple sources and sync them with the southbound database. This way, the composable service can build its lflows independently from other datapath types.
• Eliminate lflow_ref in favor of smaller lflow_tables. lflow_refs offer a way to track a subset of logical flows within a larger logical flow table. This allows for the subset of logical flows to be recomputed instead of recomputing all logical flows in the table. This works, but it has some major drawbacks.
  • The code within lflow-mgr is complex. If the code dealt solely with logical flow tables, then the code would be smaller and simpler to understand.
  • Parallelization of logical flow creation is handled in some unorthodox ways since all threads are writing to the same hmap in parallel. If all threads are writing to independent lflow_tables, then parallelization becomes trivial.