2021-12-03 - Sys Ops & Management SIG Agenda and Notes

There has been much discussion going on in the PC and TC about what should become part of the official FOLIO release.

We want to form our own opinion, the one of System Administrators,  about this and give this opinion a voice in the community.

We should be the people to convey the notion that a system must be easy to install and maintain in order to be accepted and adopted by a wide range of libraries.  And that the latter is the premise for the long-term viability of the system.

What direction should the project go, from a sys ops point of view, to handle the increasing number of interactions between parts of the system and the increasing complexity of these inter-related actions ? 

Meeting Notes

1. Clear guidance on running Kafka. This is critical for the performance of FOLIO.
2. Do we have a decision for Kubernetes as means of deployment ? No. But a decision in favor of container deployment.  
   1. Decsision of how to document it is missing / who will be in charge of keeping the official installation documentations up-to-date over the releases ?
3. What should be part of the community code ? 
   1. Put less modules in platform-minimum
   2. Also, don't inrease the number of modules in platform-complete
   3. Further modules might be community supported (part of testing cylce, community releases), but not part of an official release. Not part of platform-complete. This will be to make the system more manageable and the installation process easier.
   4. New modules shouldn't introduce new dependencies and should be deploy-able outside of the official release. Might be available in some kind of "app-store". This will make the system be more like a true microservices oriented platform. This is what people do expect the system (FOLIO) to be like. 
   5. First step: platform-minimum: Inventory & Users
   6. Anything that is part of a Flower Release will go through testing
4. We have flower releases to get the system to run in the first place. And we have to improve in these ways:
   1. Make upgrading process easier
   2. Adding another module introduces a tree of dependencies – at the moment, it is not just adding one module
   3. Develop a set of standards that new modules have to pass: 
      1. The module needs to be  a "good Okapi citizen"
      2. Add a new module has impact on hosted reference environments; it basically impacts the releases; there are no independent modules. This needs to be improved.

First Step: Have platform mininum

 New modules should be independent (from exsiting modules),  so I don't have to deploy them, if I don't need them. They may not even be part of platform-complete.

Notes Tod & Ingolf (in extra time):

We should illustrate these issues in the following way: Here are the modules I have deployed, here are the modules I have actually enabled, and here are the modules that I only deployed because they are dependent on the others (present a list).

. Rely more on message queues

. Define behavior if a module is not available. If a dependent module is not available should not make the installation process stop or be impossible. Instead, there should be some default behavior (give warning or info messages, that some services are not available).

. Caveat: But then we need to test with and without dependencies.

Tod collects these ideas in a document. For TC & SysOps & Devs. How to smoothe the interactions. Have bigger intefaces ? Rely less on HTTP ? Rely more on the messages that the modules exchange ? This seems to be more the microservices way of approach. Have more message centric or more event centric ?

Postponed to next meeting

Status of this work ?

• The Integrations Pain Points Tab Folio Source Data and Integrations has been presented to the Implementers' Group.