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.  Outcome would be specific technical funding recommendations / priorities to CC.
• Tod Olson Resources & hosting costs came up as pain points.  Need to reduce hosting costs.  Kafka topic is related to that.

Tod Olson Product Council

• SIG Convener updates.
• Definitions document in progress.

All

Technical Council Goals / Objectives:

• Tod Olson Ready for TC vote to accept document.  Craig McNally will put on next week's agenda.

Breaking Changes

• Jeremy Huff Met yesterday.  Progress made, not ready to submit yet.

TCR Process

• Some PRs merged.

Charter Revisions

• Jenn Colt Had an extra week to review, no activity.

DR Process Improvements

• Radhakrishnan Gopalakrishnan Done, just need TC review / final changes.  Migration complete from old DRs, history is there via cross-referencing.
• Jeremy Huff If any prove problematic in the future, we have processes to iterate/modify/override.
• Craig McNally Some decisions are architectural, some not.  Can be more consistent going forward.
• Tod Olson Set deadline for reviewing legacy items, or they are accepted.
• Marc Johnson If we do that, we should make the deadline short.  We generally don't get much feedback.
• Craig McNally One week.  If people do raise issues, we can extend period.  Migration was done 3-4 weeks ago.

Kafka Partitions

• Olamide Kolawole Ready for TC update next week
• Marc Johnson Progress update next week or agenda item?
• Olamide Kolawole Agenda item.  TC reviewing draft, maybe vote to advance.

Distributed / Central config

• Radhakrishnan Gopalakrishnan Present to the subgroup in the next week.

Just discussed above.

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 

Review revision after adjustments made after receiving additional feedback

• Jenn Colt Incorporated Owen Stephens 's feedback clarifying some of the terms.
  • Also on what "guidance" means.  Turning community input into goals & directions.
• Jenn Colt intentionally did not include some of the original vision statement about microservices, etc.  Was too much.
  • Craig McNally Fine
  • Owen Stephens Could call out that technical goals & directions were informed by the original vision and community development needs.
  • Marc Johnson Fine to add that, but then be prepared for part of the conversation about the charter to be about that stuff – the original vision, etc.  Don't know if we're prepared for those conversations at this point.
  • Jenn Colt Recurring conversations about ties between modules, interdependencies, bring up that original vision on modularity.  Do people still care about that?
  • Marc Johnson Yes, still important.  Some just historical context.  Happy to have those conversations.  There is a legitimate question for the community, not prepared to answer, of where are we in relation to those original goals, and does it matter.  TC should have an answer if community raises the issue.
  • Jeremy Huff Fine to take historical context into account.  Would be nice to point to documentation on the initial ideas.  Shared understanding of what FOLIO was intended to be, as well as our active experience, developer needs, are all factors we should rely on in providing guidance.
  • Owen Stephens Don't want us to be painted into a corner by original vision.  But some decisions like microservices approach have never been questioned by TC, so there is clearly still a guiding vision.
  • Jenn Colt Swayed to add to the list, to include the "original vision, community requests, development needs, and TC expertise".
  • Maccabee Levine Just add "including".
  • Marc Johnson Agree, and "stuff from the community" is a catch-all for anything else.  Everything we discuss comes from somewhere in the community.
• Craig McNally Aside from above changes, can we assume those, can we then proceed with the document.
  • Jeremy Huff Yes!
  • Owen Stephens Whether the TC is there to "ensure that the technical standards are upheld" per 6th and 7th bullet point.  Maybe facilitating that / supporting the dev teams.  Jenn made that change to one of the bullet points.  Not unhappy with the doc as-is, can move forward.  But something missing in saying we're here to support you vs. make sure you do the right thing all the time.  Existing change is sufficient.
  • Marc Johnson After this goes through, we can acknowledge that TC has similar challenge to PC that original charters have tension, talking about our authority to make decisions that affect things, directing development, and emerging reality of what councils do now, but we're not ready to change charters to reflect that.  Other groups figuring that out now, current CC group.
  • Jeremy Huff Agree, TC not ready to make those changes, don't think we need to do that.  We should act on our chartered responsibilities.  If charter says we make decisions, we should make decisions.  Do what we've been asked to do.  If we're summarily ignored, that's something for community to work out.
• Jenn Colt Vote to approve now, but allow Jenn to tweak that list of four?
  • Approved.
• Craig McNally and Jeremy Huff will communicate to CC once Jenn Colt 's edits are done.

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