Per Tod Olson:SysOps would like some time on an upcoming agenda. The SIG has been working on a list of Operational and SysOps needs and are looking for help on how to advance these needs. The concerns also overlap somewhat with the values/criteria for accepting external code, so it seems like good timing.
- 2021-09-02 Meeting notes from the PC meeting where Tod presented
- The SysOps SIG would like to address the difficulty getting technical and operational needs met when standing up FOLIO installs. The SIG is reaching out to the TC and the PC to raise these issues and try to get traction on resolving them.
- Ingolf Kuss : There's operational technical debt with all the tight-coupled dependencies among modules. With 3 releases per year, going down to 2 at some point, it's getting more inefficient. It's moving away from an agile microservices approach and seems monolithic. We need to define module boundaries. A smaller core is desirable, not with 50 modules. More optionality in what needs to be installed - like an app store.
- jroot : has a lot of hands-on experiencing installing FOLIO on various versions. Reference to the Operational and SysOps needs wiki doc listing the challenges and needs. The SysOps SIG presented to the PC last week about these issues. There's a lot of technical debt in the way FOLIO has focused more on new features than core functionality. One example of a pain point is sometimes having to back-port modules so a feature works in new releases.
- The major concern is that this will all get worse as new tech platforms are incorporated into FOLIO.
- Zak Burke discussed the longstanding delicate balance between stable Flower release deployments and the ongoing need to satisfy the community's new feature requests. Sometimes there's frustration among module developers about having to wait for a major release rather than just patching their module to fix or improve something.
- Jeremy Huff : Could the number of modules be reduced at some point to address the issue? Are optional "soft" dependencies possible, to reduce the problems in inter-module functionality?
- Tod Olson : If there are errors, how should they report/flow backwards if there's a problem at an end point module?
Likely to require additional discussion as well as a subgroup and/or time slots in coming weeks. How should we move this forward?
Brandon Tharp the TC should decide how to lean on the FOLIO community to resolve the issues, and advocate for architecture change.
Jeremy Huff One restriction is that the TC does not allocate developer time. The most we can do is advocate and lobby for a strategy that the TC would promote. Define goals of how FOLIO should be, where things currently fall short, how to head off future technical debt as well as remove the current debt.
Zak Burke A challenge is that we don't have an "NFR" SIG or library to advocate for non-functional requests. FOLIO is more motivated by SIGs and Libraries who are mostly feature-driven.
James Fuller This feels like a Risk Tolerance situation. If the risk for a module release is very small, I think the folks would be more likely to update more frequently. With the historical risk during an update, currently people are update-adverse.
Ian Walls FOLIO needs to have official 'releases' from a marketing, training and documentation perspective. but that can also exist with the ability to deploy bug fixes in modules without having to re-roll a completely new release.
Owen Stephens The discussion at the PC concluded with 3 next steps:
- Can the TC take this on (in collaboration with the SysOps SIG) and refer items to the PC that need to make their way to the roadmap?
- PC needs to have a view of how FOLIO is deployed and used in a library. Libraries want stability and predictability in the software they are using and the timing of when releases are made. "What is the FOLIO product...as a suite of apps to manage their day-to-day business."
- All this will require some well-written documentation for, which apps are bundled together, and when a platform feature like Kafka is required.
How useful those are right now, I’m not sure - and I think if the technical council needs guidance from the PC or needs to refer issues back to the PC then that would be very reasonable
The SysOps SIG has suggested and advocated for NFR work in the past, but it always gets ranked at the bottom and never prioritized. SysOps also has no PO.