A couple of goals:

  1. Ensure the DB has been initialized and loaded (with policy types, PdpGroups, etc.) before Policy components that are dependent on them are started
    1. Ensure data is added in appropriate dependency order (e.g., policy types before PdpGroups)
  2. Provide a mechanism to upgrade & downgrade DB tables and data from previous installations
  3. Prevent Policy components from exiting just because the DB pod is not running yet


Currently, OOM is configured to perform some DB initialization before other Policy components are started.  This should satisfy #3 and provides a hook for #1.  However, while this step creates various DB tables, it does not preload any data.  As the data preload is currently done by each component (e.g., API & PAP), that does not satisfy #1a.  One suggestion is to move the data preload out of the Policy components and make it part of this DB initialization step.

Item #2 could also be addressed, potentially via the DB initialization step part of OOM.  That would require some more thought and investigation.

  • No labels

1 Comment

  1. Jorge Hernandez

    Some thoughts:

    #1 - this is more or less supported already, components won't start until db is initialized, further enhancements can be done as long as we define the dependency graph properly between components as we want them to come up.    This should be fairly easy to do.

    #2 - I think the first difficulty to resolve is how to deal with the JPA generated tables that API and PAP uses.    The difficulty is that the Java code and the DB are tightly coupled and the generated schema layout is not that easy to understand or be maintained independently.    The drools-pdp and the discontinued legacy policy/engine had instead an SQL first approach defining the schema , and support downgrade/upgrade scripts maintained on a per-release basis to evolve the schema and data across releases before the component start using them.    The xacml-pdp does also take the sql first approach with the guard table explicitly created on SQL.

    #3 - At least at initialization, issue is more or less covered.   At runtime, I think the components would exit with transient failures.