Versions Compared

Version Old Version 3 New Version Current
Changes made by

Craig McNally

Tod Olson

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Meeting notes, including decision on FQM RFC

Date

Attendees 

Discussion items

TimeItemWhoNotes
1 minScribeAll
Florian Gleixner is next (has volunteered to scribe next Monday), followed by Marc Johnson, then Ingolf Kuss

Reminder:  Please copy/paste the Zoom chat into the notes.  If you miss it, this is saved along with the meeting recording, but having it here has benefits.

5-10 minAlignment Expectations/Goals of this meetingAll

What is the goal of this meeting?  What would a positive/negative outcome mean?

Comments

  • ML:
    • This is a one-off process, we have changed both TCR and RFC processes since this process started in 2023, so what we do here does not set precedent as those processes have already been changed.
    • This process was set up to see what implementation changes might be needed
    • Recomendation: do what we said in 2023, identify what improvements should be made
  • JL: The RFC is not written this way, and this is an architectural change, so text of RFC should be changed if that is what we mean
  • JC: This is not how we normally do an RFC.
  • Discussion continues around process, whether it is too late to make any changes, and 
  • Framing:
    1. Are we working toward active consensus that we like the architecture as-is and accept it
    2. Are we working from the position that the TC effectively accepted FQM and that we would need to have consensus on changes to the architecture
  • Suggestion: skip over this, discuss RFC, then figure out what the discussion means.
*FQM RFC - Final ReviewAll

See 0011-Folio Query Machine (FQM)

Notes:

  • RFC scope - question asking for clarification on what is in- and out of scope
    • Complaint is that the description is too long and that it is unclear what the decision we are being asked to make
      • e.g. architectural decision, like whether this is the only application allowed to access other applications' schemata
    • Response is that this is moot, FQM is currently the only module trying to do this, with one exception of a module making a temporary arrangement until FQM is available.
      • Disagreement about whether this is in-scope or out of scope
      • Core problem is that we have a problem in FOLIO that applications need to access data across storage boundaries, do joins in an efficient way
        • Proposes solution is to offer one application that can handle those joins, this application can act as a broker to read-only cross-schema access and offers some degree of insulation from changes
    • Decision: leave wording as is, FQM is the single application...
  • Question about how schema changes are managed
    • currently a manual process, so far has been manageable. There are discussions about how to automate this somewhat to give notifications and streamline maintanance
  • Question about different ways modules integrate across data boundaries
    • Point was to raise awareness about there is a multitude of ways FOLIO has adopted to deal with coordinating data across data boundaries, not a request for a change.
  • Use cases: why is FQM the only/best solution
    • The use cases are intended to show a range of areas where FQM can be a single solution to address multiple cases
    • Whether to adopt FQM for any use case should be a case-by-case basis
      • Comment suggesting that the whole use case section is out-of-scope
  • Detailed Explaination/Design
    • Suggestion that these details may be out-of-scope and could be left in the GitHub documentation
      • Note (MJ):This and other suggestions seem more about the form and content of the RFC template rather than this application
    • Dependency Impact: ML will draft a sentence to add
    • Data Permissions
      • maintenance has not been an issue so far
      • mod-orders has a one-off additional layer of row-level permissions, not yet accounted for in FQM, discussion design. If there's a concern about data leakage, could not make specific data available until concern is addressed.
  • Risks and Drawbacks
    • Question about how tenant roles and tenant schemas are created, could do some work to give the module database user more limited access
    • Harvesting database tables: first design was to create tables to harvest data but was not considered best option, though may be appropriate in some specific cases
    • Comment that bounded context combined with FQM application could be promising alternative approach
  • Next steps/summary conversation
    • Seems to be some consenus on need for some language
  • Proposal
    • A vote to accept the FQM RFC would be accepting a single hub-and-spoke model for cross database boundary access, and would include the non-controversial language changes discussed.
    • Vote:
      • 10 members present; ayes: 6; nays: 1 
    • Decision: RFC passed
-Zoom Chat


10:14:12 From Maccabee Levine to Everyone:
The history of what was done a year ago is in the slack thread from yesterday. https://open-libr-foundation.slack.com/archives/CAQ7L02PP/p1744735834219119

10:22:59 From Maccabee Levine to Everyone:
From the TCR: "The submitters have agreed to create an RFC on the topic of the module's use of database views for querying data across module boundaries."

10:39:52 From Maccabee Levine to Everyone:
I think the use cases are valuable to support the premise of the RFC and how it could be used. Whether those use cases would actually be done as written is (I agree) out of scope.

10:41:09 From Marc Johnson to Everyone:
Some of these conversations could be useful feedback into the suggested structure of RFCs

It seems that some of the headings encourage details about implementation, rather than architecture / design

10:44:30 From Maccabee Levine to Everyone:
After" On the other hand, FQM provides a centralized opportunity to coordinate all such changes. Effectively, this becomes a shift of the dependency burden from individual application interactions to a more robust centralized dependency management approach."

I suggest adding "Is it not the burden of individual module owners to notify anyone else of schema changes; the FQM architecture will include automated means to become aware of and adapt to module schema changes."

10:47:05 From Day, Kevin to Everyone:
It has just occurred to me that upon approval of this RFC, we will likely need to review and update our TCR process to add commentary regarding access/permissions/security.
Maccabee Levine, Marc Johnson, Ingolf Kuss:👍🏻

10:48:10 From Maccabee Levine to Everyone:
Replying to "It has just occurred to me that upon approval of t...":
We have an existing criteria prohibiting the exact cross-schema access that this RFC will allow. So yes we need to tweak that criterion to except mod-fqm-manager.

10:54:30 From Maccabee Levine to Everyone:
That's fair Marc -- to be clear I said I didn't think we had consensus around concerns, not that we (individuals) didn't have any concerns.

10:58:11 From Jenn Colt to Everyone:
Six passes - a majority of TC members present

10:58:55 From Jason Root to Everyone:
Jakub is out - and he did not announce me as his proxy. Just FYI
Ingolf Kuss:👍

11:00:12 From Maccabee Levine to Everyone:
Thank you to Vince and Matt for all the work done in developing this architecture, and in documenting it.

11:01:26 From Matt Weaver to Everyone:
Thanks everyone for your time an consideration 🙂