Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

TimeItemWhoNotes

Find a note taker
Ingolf

What do we want to achieve this year ?


  • This may influence the question of how often we will meet "synchronously" (weekly - bi-weekly - on-demand)

Notes:

tabled until next meeting


Approaching a platform-minimum set of modulesIan & Jeremy

Notes from last week's meeting:

  • encourage modularity and clean dependencies (moving towards independently-installable Apps)
  • reduce dependency on single-server install method
    • build towards docker-compose or helm deployment without manual intervention
    • have a FOLIO that can be deployed on commodity hardware (for developers)
  • not a point to sell to librarians; audiences: vendors, developers, possibly folks outside the library world

This topic was also mentioned in the Data Migration Meeting (January 10th); Notes from that meeting:

  • Dale encourages a discussion on this and to proceed in this direction. Single Server installation is not being supported anymore. An installation of platform-complete is becoming increasingly difficult.
  • Use cases for platform-minimum: test environments, developer environments
  • What is the status of the Terraform solution (→ Anton). Stanislaw is not on the project, anymore. Is the Terraform solution being supported for the current releases (Juniper/Kiwi) ? Anton was interested in promoting that but it didn't go anywhere (question).
  • Dale: A one-Click installation on-premise (Kubernetes based). This is highly desirable to have. Someone package up the system as it and then install it. Then use it as a test system.
  • Ian: Independent Apps approach

Meeting Notes:

Ingolf (question): Stanislaw did a great demo of Terraform deplyoment to us, but Stanislaw left the project. Is the Terrafrom deployment being maintained still for the current releases (Juniper, Kiwi) ? This will be of great interest for the platform-minimum approach, too.
Anton: Terraform is being used in development environments.
Each development team has its own test system.
- open AWS account
- take scripts , deploys
Terraform allows you to deploy anywhere (not only AWS)
TAMU does it with VMWare
Terraform is for heavy lifting to get Rancher set up. Make things to do in Rancher easier.
Brandon: we would like to start with the Helm charts. Terraform is a little platform specific.
Jermey: On Stanford we are using Terraform with AWS, but no Rancher.
Brandon: Terraform is very specific in how you configure: VMWare, AWS
      In dev environment: Sets up Resources in AWS. Sets up Rancher.
      Devs only have to mess with Helm charts.
Ian: We could have a Helm chart.
Anton: Deploy all the prerequisites like Kafka etc. Devs are not supposed to be writing code. Rancher has "projects". Each project is a separate environment, but it shares hardware and AWS resources.
     Instead of deploying snapshot , they deploy branch.
Anton: There is a repo for Helm charts. It should have a documentation.
    I wish it would be more widely adopted. You can use VMWare or bare metal servers.
    As a SysOps SIG we should come to a unified support. EBSCO has a different approach.
Ian : Get a Kubernetes cluster. Is this an exercise left to the reader ?
Anton: You can deploy everything in container, or you can use AWS services. Kafka, ES, ... they can all be container based.
Brandon: You are either talking Docker or Kubernetes. I was looking at Rancher Desktop. You can run moby (the docker demon), or the Kubernetes cluster.
   The management tool is better for Kubernetes. First decision: Docker or Kubernetes.
   Elasticsearch, Kafka, Postgres. At A&M we run Helm charts. Helm charts don't care where they run.
   Then you can install FOLIO. It might be RDS, it might be a Kafka instance
Anton: This will replace the Single Server install.
Ian: We could use Docker Compose, but we will do Kubernetes. We should have a documentation in the Documentation Working Group.
Ingolf: Look at the Demo of Stanislaw and post it. 

Ingolf: We should - as SysOps SIG - write a documentation for deployment with Kubernetes, starting with the Helm charts. This documentation should be placed here: docs/content/en/docs/Getting started/Installation at iris · folio-org/docs (github.com)
Jeremy: My role is the second person in that role.
Anton: I will talk to dev ops; most of them are EPAM dev ops. There are three of them.

Ingolf: How to build your own Docker images for modules ?
Brandon: https://dev.folio.org/faqs/how-to-get-started-with-rancher/
https://github.com/folio-org/folio-install/tree/tamu-r2-2021/alternative-install/kubernetes-rancher/TAMU
https://github.com/folio-org/folio-install/blob/tamu-r2-2021/alternative-install/kubernetes-rancher/TAMU/folio_setup.md
DevOps also use ANSIBLE.
Ian: How can a person off the street get a least users and inventory up. With Helm charts. There will have to be code changes to break up the interconnections.
Anton: It is coming from different directions: There is a subgroup of PC. There should be a more felxible way for FOLIO deployment which does not rely on "3 times a year".
    It needs architectural changes.
Anton: Moved to Webpack 5. This allows each UI module could be deployed separately. You don't need to rebuild the whole thing.


Action items

  •