2024-01-26 Sys Ops & Management SIG Agenda and Meeting notes

We should be involved in the release retrospective. (→ the relase retrospective has not yet been schedule, to my knowledge)

 Database migrations just should belong to module upgrades. So the module should handle it seamless. If a decision has to be made, in a ideal world, a tenant admin (not a sysadmin) should get notified (via UI), that he has to decide, and until the decision the module may stop to work as usual.

Jason (in Slack chat): "I agree that all of these separate scripts should be the module’s upgrade process responsibility and not a separately managed thing. However, I’m unsure of the avenue to take in order to ensure that will be the case in the development and upgrade release testing cycle."

Shelley Dolljack (in Slack chat): "I agree that those scripts should be part of a database migration when enabling the module. I’m confused why they’re not. I thought doing things like rake db:migrate (rails db migrations) was standard practice."

Status 01/22 : Ingolf briefly touched this topic in the TC meeting today and will elaborate further on the reasons for having these scripts separate to the module upgrade. Will then circle back to Sys Ops meeting.

1. jpnelson on FOLIO & AI : February 23rd is set.
   
2. Florian Kreft & Florian Gleixner ; about alternative Helm charts developed at LRZ.
   1. Jeremy will talk to Joshua Greben if we can set a date → the actual date is flexible. Relatively soon makes sense, so the preliminary date is 09.02.24 at standard SysOps meeting time
      
   2. What will be the scope of this talk? → it would make sense if people who work with the existing folio helm charts  ( https://github.com/folio-org/folio-helm-v2 ) since the general goal is to have more collaboration here. In general we can talk about the structure of the LRZ-Helmcharts and the decisions we made, and then have some kind of workshop or discussion. So at least basic understanding understanding of kubernetes and helm would be helpful.