Design meeting notes:

https://docs.google.com/document/d/1U1032SG_pTK5FyF8vOB-vGtZGCZ0Mq9FnQdRkd2k998/edit#

Problem:

• LSO has 3 goroutines (LV, LVS, deleter), upstream static-provisioner has one goroutine for everything and does not need to solve any races.
• static-provisioner was not designed to be used as a library, LSO code to initialize it is ugly and confusing (we run 2 deleters?!)

We came up with a carry patch for https://bugzilla.redhat.com/show_bug.cgi?id=2032924 in static-provisioner for an urgent customer issue, but this is not a good long term strategy.

Possible options to resolve the differences between LSO and static-provisioner:

1. remove static-provisioner and write our code?
   • our deletion may be simpler, we don’t use Jobs.
   • copy useful chunks of deletion code from the static-provisioner.
   • we diverge from upstream and we won’t get new features / bugfixes.
2. Refactor upstream static-provisioner to a real library and use it?
   • Cut a function that deletes individual PVs.
   • Ownership of the provisioner cache is not clear.
   • Use interface for the provisioner cache
   • Remove periodic reconciliation and use events instead
     • e.g. event that a cleanup finished
3. Serialize diskmaker process to have one goroutine instead of three
   • one Reconcile() gets all events from the work queue
   • Don’t react to events and just sync everything every X seconds (in a single thread)
     • more CPU usage
     • deleter + discovery need to run every X seconds anyway
     • something still needs to update static-provisioner cache based on events (periodic sync may be too late)
       • Can be done by the caller that sets up that loop (rather than loop itself updating the cache).