2022-07-20 Meeting notes

1 min

Scribe

All

 @Maccabee Levine is next, followed by @Tod Olson 

 < 5 min

Review outstanding action items

All

None

1 min

TCR Board Review

All

Nothing changed.

20 min

Technical Council Sub Groups Updates

All

• TC Goals/Objectives

  • @Tod Olson : Working through the pain points doc.  To be coherent from the original doc with many contributors.  Some points intertwined so will be bulky.  Some themes emerging, i.e. improving documentation, module boundaries, storage handling, API design.  Determine what items to discuss at WolfCon.  What items can we take action on.

  • @Zak_Burke Microservices theme comes up a lot, but we use FOLIO as a system.  Consider deployment as a whole, instead of pieces being designed narrowly.  Consider the balance when we design.

  • @Tod Olson Agree.  We've designed around user-facing records instead of efficient processes.

  • < pause in discussion to end of meeting >

  • @Marc Johnson Zak's point relates to what community aspired to 6 years ago vs now, how modular the system is.  Need to consider impact.  If we only consider system as a whole, the boundaries get weaker.  But agree with a holistic view.  PC/CC discussions that there is no single definition of FOLIO, currently at least three market-specific ones.  Implications for governance, such as more than one definition of what we call the system, sometimes could be radically different.  Could have a common core, but can we agree on that, at least first two layers.  Argument for making that less modular, if we will never separate that core anymore, to squash it together.

  • @Tod Olson Perspectives ranging from keep separate and change communication model, to having only one grand unified storage.  Starting to wonder if we have boundary-crossing modules, who owns the data, when does an update need to be synchronous, vs. async and eventual consistency.  Be deliberate about that.

  • @Ian Walls One appealing thing about FOLIO was modularity, customization for different libraries/groups.  Pre-pandemic decision to get an MVP out the door, "FOLIO the product", compete with closed-source products.  With that approach, made compromises and incurred technical debt.  Need to differentiate platform (okapi, postgres, kafka) vs. product (that plus library business logic).  Advocates shared storage solution.  Would also benefit from shared workflow concept as part of the platform, how we move data around between logically separate parts.  There will be different products that come out of this, but could have one platform.  PC could say X functions, a Chinese council could come up with separate list of products, etc.  But one platform that supports ReShare and whatever else.

  • @Tod Olson Could examine boundary modules.  Can we enable regions to replace modules better than now.

  • @Craig McNally Understood notion of moving away from microservices to monolith.  There's value to having a composable system.  Would caution against monolith route even though close to being there now with how FOLIO is released/deployed.  I.e. some institutions only interested in ERM.  Some others might only care about print, or both.  Monolith would be wrong direction.

  • @Tod Olson Comment from @VBar that microservices = bounded context, and FOLIO has fallen into microservices = module.  That might not be the right bounded context.  Bundling might not create monolith, but how we combine context.

  • @Craig McNally Agree if we shift focus to apps instead of modules.  But not monolith.  Don't need one single definition of the system.

  • @Marc Johnson Not suggesting one system.  But discussion about a couple of things, most innermost might be technical platform, that are so intertwined and fundamental, that the value in splitting them to be replaceable is low.  People don't want to do that.  We just pay the price of splitting and distributing.  No monolith, no one definition of system.  TC should be conscious that the boundaries are not a technical decision, it's a product decision.  A context might have multiple modules within.  Might or might not = what FOLIO calls an app.  But not a technical decision.  How to help PC make those decisions.  And how can platform make it easy to manifest that.  Technical protocols of how we exchange info are different from the workflows the products model.  Without product folks' help can't align technical stuff with product domain boundaries.  I.e. SIGs don't align with technical artifacts.

  • @Tod Olson Agree TC can't solve in a vacuum.  Might be able to provide leadership to discussion, frame it for community conversation.  Can't completely push off to another group.

  • @Jeremy Huff Different perspective.  Agree that front-end apps are product decisions.  But the way those app boundaries interact with backend services is a technical decision.  No reason PC should be concerned with that as long as performance, functionality expectations met.  Also the potential to swap out modules has served as a security blanket, helps comfort in implementing FOLIO.  Didn't do modular well, but doesn't mean it's not worth doing.  If we didn't get the value originally intended, we should try to get it right.

  • @Tod Olson This conversation has played out in different groups, but not static, seem to be coming to core issues.  So helpful.  But complex.

• Translations

  • @Zak_Burke Set agenda for the group, doodle poll.  Getting it launched, not stuck.  Possible first meeting next week.  An architecture has already happened, are we happy with it, or define an approach in an RFC first.  First meeting will define subgroup goals.

• AWS Costs

  • @VBar No updates, postponed at Peter's request.

• Technical Docs / New Dev

  • @Vijay Gopalakrishnan No updates, couldn't attend last meeting.

10 min

RFCs

All

• #3  RFC localizing  backend  messages

  • @Vijay Gopalakrishnan Final stage, need to merge it.  No GitHub permissions to do so yet.  Craig will be doing a ticket to get the TC write access.

  • @Marc Johnson Just ask on dev-ops channel, less effort than a ticket.

• #1 AES proposal

  • @VBar Can close this, settled a while ago.  Just didn't go through the merge steps.

  • @Marc Johnson Briefly discussed last week but needed more discussion.  It's a historical doc, not really AES anymore (it's pub-sub, which has been superseded).

  • @Craig McNally asked @Vijay Gopalakrishnan if there are guidelines, otherwise to just close it

• @Vijay Gopalakrishnan and @Olamide Kolawole will discuss experience with localization RFC

New Sub- groups

• Check in on where the formation of the Elasticsearch/Opensearch working group...  Do we want to add this to our subgroup page for tracking/update purposes?

  • @Craig McNally Was subgroup formed?  Do we want to track?

  • @Marc Johnson CC did not form a working group.  Discussed a week ago Monday.  Agreed it should be a cross-council group.  Will ask CC at their next meeting on Monday.

  • @Craig McNally Will track on subgroups page.

• Following up on this action item from 7/6:

  • define "breaking change" in a subgroup? adjust definition of done? adjust release cycle to accommodate upgrade testing? Try to get @Oleksii Petrenko 's input on this in the near future?

  • @Craig McNally we had discussed subgroup for breaking change, come up with definitions

  • @Zak_Burke I posted notes to slack, there was a discussion.  Lots of ways to list a module's dependencies.  What should semver respond to.  May be operational concerns (i.e. Java dependency), is that a breaking change affecting major version number.  Wanted to form agreement.  Haven't done that yet.

  • Craig created a subgroup.  @Marc Johnson offered to be involved.  @Jeremy Huff , @Jakub Skoczen @Maccabee Levine @Zak_Burke @Ankita Sen  also.

  • @Zak_Burke Hardest part is to figure out how to enforce constraints.  Merges causing conflicts.  How to surface it so more people are aware.

  • @Jakub Skoczen Should we consider external dependencies infrastructure as part of this?

  • @Zak_Burke Yes, or if not we need a different way to surface those changes.  I.e. when you run the UI in a browser there's technically no dependency, but the libraries that compile modules together has a Node 14 dependency.  Where do we put that info if not part of the module itself.  If not part of semver.  It's less important that we come up with a precise definition of semver, compared to how we let people know of dependencies.  Multiple audiences for whom a change might be considered breaking.  For example, do we want an 'operations' number in addition to the one 'major version' semver number.  Need some way of documenting it so people are informed.

  • @Jakub Skoczen Agree.  Better definition of how to make changes known.  If language is strict then we have less understandings.  Related, we constantly fall behind with infrastructure, don't have a good policy that would encourage it.  Have raised it in meetings.  We make updates for a reason: more functionality or performance.  Don't want to be on Java 8 for the next 10 years.  Should be tracking at least the last LTS.  

  • @Zak_Burke If we had a policy that we should use the last LTS, when that expires, do we reflect that in the semver major version.

  • @Jeremy Huff For goals: do we want to use semver to track those types of changes or not.  If the group decides not, then is group also on the hook for how we disseminate the other changes.  More useful to the project if we answer both.

  • @Zak_Burke They can be answered separately.  As long as we do both.  Ok with several narrow RFCs.

  • @Marc Johnson For semver we're talking about at least two versions.  Recent changes don't care about module implementation version, only interface version.  So have to talk about both.  Agree with concerns about operational.  In scope of this group, even if the group kicks it out later.

  • Craig drafted goals on subgroups page.

  • @Marc Johnson How both operational and breaking changes are communicated.  And how people should operate in order to not break things, maybe as follow-up topic.

  • @Zak_Burke Agree, hoping to define the "what" now and the "how" after.  Can't just commit something, do some communication process.  Also what is part of the API: okapi interfaces, java or node version, etc.  Some operational, some functional.  If two breaking changes are made without a release in between, does the number bump twice.  Define whether version is bumped at release or pre-release.

  • Craig drafted deliverables on the subgroups page.

  • @Jeremy Huff will chair.

Other topics?

All