| 20 min | Technical Council Sub Groups Updates | | - 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
|
| 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?
| 10 min | RFCs | All- 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.
|