2022-08-10 Meeting notes

Ankita Sen is next followed, by Jakub Skoczen 

All

Nothing to review

All

• Technical  council goals/objectives:
  • Tod Olson - next meeting dates are being decided(tentative date: Monday,15.08.2022) and there has been planning about WOLFCON, VBar and Tod Olson  have been creating on creating an architectural blue print agenda for Wolfcon. Next checkin 24.08.2022 
• Breaking Changes :
  • Jeremy Huff - met this week and discussed about what constitutes as not a breaking change with respect to backend modules and about breaking changes for interfaces. Good progress made on deicing the various breaking changes. Next step is to start producing the deliverables
• Elasticsearch vs Opensearch: 
  • Marc Johnson - not much progress except a few points of discussion in the slack channel.
• Controlling AWS Hosting:
  • Mark Veksler - Met last week and drafted a cost management report that is likely to be received. A spike story was created for the Kitfox team on how to track the AWS resources that can be made into the report. Kitfox team will require a sprint or two to get this Spike started(?) and the subgroup is meeting again onFriday(12.08.2022) to discuss further steps.

Nothing to review 

Raman Auramau 

Previous Notes from presentation last week:

• Presentation (15m-20m) & Q/A (10m): Data sync updates and outcome (TC)
• Looking for solutions that are generally applicable and preserve loose coupling between modules
• Changes in source of truth are to be done atomically, and then notifications sent to consumers
• Details in proposal FOLIO Cross-Application Data Sync Solution
• Proposal is already in use in inventory, changes in mod-inventory-storage  send notifications to be consumed by mod-search 
• Q&A:
  • The message passing via Kafka introduces dependencies between modules. Do we have a mechanism for documenting / declaring the dependencies. Discussed, but intentionally out-of-scope for the group.
  • Are there guidelines on how retention period may change? Trade-offs, retention periods may be different based on use case, no one approach for all cases. Deliberately does not allow for replay.
  • Full-body vs. diff message: there are message sizes, and Kafka works better for small events. 10-100KB cover current known use cases.
  • Regarding outbox pattern, was the Debezium idea evaluated? No, just came up in brainstorming.
    • Debezium is used in LDP/Metadb. Debezium/WAL solutions do generate A LOT of events, which heavily impacts Cloud hosting costs.
  • Are there performance issues with Outbox pattern? Did not do specific testing, existing uses do not have numbers, but also did not state concerns about performance. Outbox will introduce some delay in notifying consumer. Different use cases have their own acceptable delays.
  • Do we need to propose a mechanism for synchronizing data in cases where events get lost.
  • What are next steps? This process pre-dates ADR/RFC process.
    • Action: group will create and ADR and ask for TC approval
    • POC & performance testing? existing work in inventory could be considered POC, but do not use Outbox pattern.
    • Can discuss next steps after TC approval
  • Group was starting from current state of FOLIO and current use cases, was working from a more constrained view than green field.
  • Current reindexing approach undermines some of the is proposal, relies upon consumer knowing the source of truth. 

Today:

• DR-000004 - Cross application data sync proposal
  • Raman Auramau - met up with people from the working group of this particular ADR and they provided some background and pros and cons of sorts. Also spoke regarding PoCs - what are the expectations, when should it be done which team should do it?
  • Craig McNally - the approved date should remain undefined for the ADR and the status should be kept as DRAFT. But defining what exactly our proposal here is. Current scenario is missing the implementation of an outbox pattern in FOLIO. 
  • Marc Johnson - In current scenario ADRs are being used as a process and also as a form of Documentation. For the decision part - the submitter proposes the decision with reasons for it. feedback, rejection, acceptance follows after submitter has made the decision. Ultimate decision is of the TC to approve, change, etc. the ADR.
  • PoC -
    • • Do we need this? What is the scope? Timeline? Who will do this?  
        • It was agreed that the PoC was regarding implementing the outbox pattern. 
        • What is the PoC being used to learn or validate about the outbox pattern? PoC may contain how to implement an outbox pattern(eg. in RMB modules), what impact will the implementation have on  performance of the modules.
        • Timeline - does this have to done now or do we wait till one or two teams implement the approach within their part of FOLIO?
        • currently there is no visibility of the Development process for the TC directly which says to do a PoC or follow an outbox pattern. 
        • What should be the steps to make sure that the folks are complying with the decision that was published?
        • There is not immediate candidate for this but still needs be carried on since teams will be expected to start implementing this soon and there is an urgent need for solving this issue.
        • Decision to be made for whether the information about the outbox pattern is needed before any architectural decisions is made or does it make sense to wait for a feedback from at least one team that has implemented it. 
        • Hold off any decision making till a suitable candidate is found who will implement this and it has to be made sure they follow the outbox pattern. Check-in on TC weekly?
        • Keep this ADR generic and once a candidate for Cross-App data sync the Outbox pattern architecture and POC can be created. The current scope of this ADR doesn't contain outbox pattern defined.
        • The working group formed by the App interaction SIG is being given the responsibility to implement the outbox pattern into their planned feature works

Craig McNally 

Several topics have been raised recently that deserve attention/discussion.  The goal here is to figure out how to best move these forward, without digging into the topics themselves.  Is there a priority here?  Should we spin up working groups for any of these?  etc.

• 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. 
• 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 councils
• How/when to make significant technology changes in coordination with the release schedules of other tools, e.g. keeping in sync with Node LTS releases, or Java 17 or Postgres 14, etc. 
  • May be overlapping with the Tools/dependency versions
  • Marc Johnson - It would be useful to relate the changes to match the release schedules
  • See also:  messages in TC channel
  • On agenda next week along with Tools/Dependency version
• Tools/dependency versions - Radhakrishnan Gopalakrishnan took on this topic as a project. There is also a proposal Managing Tools/Framework Dependencies currently in Draft stage with feedbacks as latest as 02.08.2022. On agenda for next week.
• Jakub Skoczen - Planning about Wolfcon working sessions? How to run the sessions? Put this on the agenda next week.