2023-02-15 Meeting notes

Maccabee Levine is next, followed by Tod Olson 

All

Maccabee Levine / Tod Olson 

Any updates from the PC and/or CC?

Maccabee Levine Community Council discontinued funding for the sole community developer.

• Suggestion that TC discuss technical resourcing priorities to be able to share with CC.
• Jenn Colt AWS costs.  Put additional energy into existing group?
• Craig McNally Most of that subgroup's work has been Kitfox, better visibility into those costs.  Perhaps cost savings could fund a developer.
• Marc Johnson EBSCO is/was funding Amazon costs.  EBSCO supplements funding that CC receives from members.
• Maccabee Levine suggesting future agenda item, or subgroup.  Larger issue than AWS.  If CC allocates funds to priorities, and some of those are technical priorities, then TC should have a voice.
• Tod Olson Resources & hosting costs

Tod Olson Product Council

• SIG Convener updates.
• Definitions document in progress.

All

All

Martin Tran presented the proposed DR for Splitting Database Read / Write Traffic along with an accompanying .

He advised that the FSE team and Core Platform team implemented this work in RMB during the Morning Glory and Nolana releases, during which most RMB storage modules were upgraded to support the proposed mechanism (meaning that this design is already in use in production). 

These changes were performance tested using circulation and data import flows. He advised that CPU use is more evenly split between read and write nodes, reducing the pressure on the write node when under higher loads (25 concurrent use). This also led to a reduction in CPU usage in the ("back up the chain") modules making the database requests. During circulation only testing, whilst there was a slight deduction in response times for check in, responses times for check out increases in some cases. However, once data import and circulation work flows were running concurrently, the read / write split significantly reduced response times over a single node.

There is remaining work to fully support this across FOLIO:

• Use unambiguous (explicitly either read or write) operations in RMB modules, that are already providing support for this. Only one module has been updated to stop using ambiguous operations (where RMB does not know the whether the module intends to perform a read or write).
• Write in-module automated testing for using separate read and write nodes. This work is waiting for tooling support within RMB
• Functionally validate modules using separate read and write nodes (using integration or smoke tests)
• Change other modules to support this mechanism. This will include updating other shared tooling, e.g. folio-spring-base

Craig McNally asked what the next steps are? Maccabee Levine suggested that Martin Tran update the ADR to reflect some of the questions / concerns raised during the conversation. Craig McNally advised that after those changes are made, the TC will reach a conclusion in this DR either via Slack or in a future meeting.

------------

02/08 : Martin Tran made the adjustment. Next step is to take another look. Marc Johnson The details should be in the decision record. Craig McNally Let's look at exactly what has changed. Tod Olson There is an entanglement between data import and updates . A concern could be a race condition between updates. How to approach that with caution ? Craig McNally Not relevant to approve the decision record.   Marc Johnson  If any of these workflows use any of the 48 modules, it is already in production. So, we are effectively applying this retrospectively. How does that fit to what we are trying to decide ? Craig McNally Yes, it is in RMB but it is not necessarily being leveraged to all the modules (which use) RMB. Marc Johnson Any workflow that uses these modules is being affected. Most of this work has been done behind the scenes in RMB. As soon as we turn the module on, it will be affected. Craig McNally The real decision is: Do we want to implement this in another framework viz. Spring Base. Jeremy Huff As it stands right now, as it has been implemented, it seems to be a good thing. This document implies that it should be going forward. Marc Johnson This is not my idea of a decision record. The purpose of the records is to document the architectural decisions. As it is now, it is endorsement of work that has already been done. That would suggest that the TC does not need to be involved. Craig McNally It was about bringing it to the attention of the TC. It was too late to have an RFC. Owen Stephens The decision is if it should be adopted. Craig McNally It is a sanity check in order not to have it unendorsed for another 6 month. Marc Johnson We made it a process, not a document. Now, it would be criticism of the proposal. Jeremy Huff A mismatch between the tools that we have in place and the opportunity to interact. Craig McNally Let us continue the discussion in Slack. Tod Olson We need more time to decide before we make a decision in favor of the Spring architecture. Craig McNally We will address this next week, again.

Jenn Colt 

Craig McNally 

• TC dedicated discussion:  20 Feb 2023 11:00 AM ET
  • Nothing planned - Cancel this week's dedicated discussion

Craig McNally /All

Craig McNally /All

From Craig McNally in #tech-council:

This was brought to my attention earlier today...
https://blog.nlnetlabs.nl/open-source-software-vs-the-cyber-resilience-act/
While it's still just a proposal, I think FOLIO should keep an eye on, and maybe even try to get ahead of in anticipation of this.  I will add it to the agenda for next week's meeting.  This is a short read that does a decent job of laying it all out.  Please take a look prior to next Wednesday.  Thanks! 

• Have folks had a chance to read through any of this?
• What, if anything do we think the TC should do about this?
  • Raise awareness among other councils?
  • Seek legal advice in anticipation of this being passed?
  • Is there anything else we want to do to be more prepared for this in the event it does get passed?

Today: Deferred

All / Ian Walls 

From last week:

• Ease of installing/deploying FOLIO - Ian Walls , Marc Johnson , Jeremy Huff
  •  Primary task the Tc would take on by making FOLIO easier to get up and running. Would also reduce AWS costs so that the money coming from Membership groups can be flowed to other aspects of FOLIO. Tc is the best equipped group to decide on how to make installing and deploying Folio easier and cheaper.
  • Craig McNally - Brainstorming open ended session with Ian Walls and then discuss further before or after WOLFcon depending on the brainstorming session. Ian Walls and Tod Olson to frame the topics of discussion for the brainstorming. 

Today:

• Probably defer, but keep on the agenda so we don't lose track of this...

All / Ian Walls 

Slack discussion:  Revisiting FOLIO Governance 

• • Ian Walls - should be best discussed in cross council meeting possibly at WOLFcon. Idea to was bring this up at a high community level not necessarily the Pc or TC. Doesn't need to be on TC agenda next week. Aspects to be discussed at WOLFcon.
  • See also:  messages to PC and CC council channels