2023-09-01 Sys Ops & Management SIG Agenda and Meeting notes

Date and time

01 Sep 2023 10-11 EST

Zoom link

https://openlibraryfoundation.zoom.us/j/591934220?pwd=dXhuVFZoSllHU09qamZoZzZiTWhmQT09

Topics

Attendees

- Ingolf Kuss jroot Tod Olson jpnelson Nils Olof Paulsson Tobias Stumpp

Time	Item	Who	Notes
			Meeting Notes: Jason & Ingolf
	Aftermath of SysOps SIG WolfCon Session		Link https://wolfcon2023.sched.com/event/1Olfo/platform-decisions-for-folio-self-deployment-on-kubernetes Memory requirements of clusters/single hosts between 40GB to 160GB depending on database size Community Helm charts of modules vs. Helm charts for whole platform/release Stanford Go-Live went well, multiple iterations of migrating helped fine-tune this process Linköping are using a single server with 160 GB - ran out of memory TAMU: 265 GB - the whole k8s cluster - a lot data imports / a lot workflows - modules scaled out a lot ; scaled to 5 pods (OAI-PMH), 2 pods all the others, okapi 3-4 pods, + monitoing, Grafana, Prometheus,... - probably using slightly less than half of that ; mininum is 87 GB Florian Kreft (via Tobias): 100 GB is a good number; database 25 GB included; not production use Jason: We don't have node auto scaling
	Application Formalization		Application Formalization - Google Docs These ideas have been recently presented on a summit meeting in Chicago. We might think of them as technical proposals right now. They are currently the subject of dedicated discussions of the Technical Council. Several WolfCon sessions will also touch on these topics. It is the intention of the author to share these ideas with a wider audience. I think it makes sense to present and discuss these ideas in SysOps SIG, as well. Many of those technical changes proposed there will induce changes in the deployment and maintenance procedure. Please watch recordings of FOLIO Technical Council's dedicated discussions on Mondays. First Meeting about the Application Formalization was on July 17th, recording is here: https://recordings.openlibraryfoundation.org/folio/tech-council/2023-07-17T11:00/ (Passwort= folio-lsp) Next Meeting about Platform & Application Formalization was on July 31st: https://recordings.openlibraryfoundation.org/folio/tech-council/2023-07-31T11:00/ Next meeting with Vince: "Extending FOLIO's authorization model": https://recordings.openlibraryfoundation.org/folio/tech-council/2023-08-07T11:00/ And you might also want to watch the recording of the regular TC meeting on August 9th. The sections in the 2nd half of the meeting: "Questions from Monday's presentation" and "Process Concerns in the wake of Vince's presentations" : https://recordings.openlibraryfoundation.org/folio/tech-council/2023-08-09T11:00/ ... I know, it's a lot to watch ------------------------------------------------------------------------------------------------------------------------- Meeting Notes Sept 1st Looking at the Application Definition a "platform" might be better called a distribution Application Manager Application Manager: It is deployment dependent. What methods of deployment will it support ? Application manager should control Docker and Kubernetes : yes How does the Application Manager interact with infrastructure? How does a systems operator get a list of modules that make up an application to deploy onto infrastructure? These are concerns especially when not using Okapi to deploy onto infrastructure, but rather some sort of orchestration tool (K8s/Docker Swarm). The idea of Helm charts for applications as groups of modules instead of just modules came up. Jason: There is currently a plugin for Okapi on the Discovery Part The Application Manager would be a part of the API gateway ? the application manager is a backend module that talks to Okapi ? it has to know what it is going to talk to. Does the Application Manager need to talk to the Orchestration tool ? Jason: In my world the Application Manager is Helm. It is the K8s Manager which is Helm. Application Manager take the application descriptions and create Helm charts. You could run Helm charts on straight Docker But you don't need to have it with Helm at all. There are already Helm charts for each individual module. "Helm circulation app" ------------------------------------------------------------------------------------------------------------------------- Meeting Notes (Aug 18) Application Boundaries: Interface Versions need to include a range of versions, must be backwards compatible. Application versioning not much different than modules versioning + flower release bundles ? Ingolf: A concern about the (proposed) changing notion of a Platform. If there will be not just one big platform (platform-complete), as it is now, but several smaller platforms, maybe specialized to ERM, circulation, other specific purposes: All modules which one might possible install must go through thorough buckfest testing (or some QA testing of similar quality). Having just a smaller set of modules undergo the QA testing workflows does not seem acceptable.
	Topics for future meetings:		Big changes from WolfCon Need to pick up topics from the Application Formalization proposal in further sessions: What is a Platform? Application store or marketplace? Microservice boundaries (basically, we have so far only discussed the Folio Applications section)
	Status of Integrations		Overview: List of Integrations - System Operations and Management SIG - FOLIO Wik

Action items

Type your task here, using "@" to assign to a user and "//" to select a due date