| 5 | Welcome | Ingolf | - Determine note taker
- Review action items – Dev team creating a repository of FOLIO releases. Addressing the issue of needing to build Stripes when needing to specify the OKAPI URL. Building a single server setup guid that eliminates the need to use dev tools such as Maven, yarn, etc. A simple clean setup. This is the starting point. In the future this will become available for multi-server. This is a great starting point. This is WIP for the current sprint.
- As a SysOps, I want a package. I don't want to go to GitHub. Jakub, GitHub can be used for this and it's up for discussion as to what the final solution will be.
- We agree to drop the need to build Stripes for FOLIO for sysops. SysOps wants a prebuilt system.
- They want to avoid boot strapping the database and that will be part of this update as well.
- The guide should not ever refer to checking out or building code. Everyone agrees.
- We need to manage versions that are published and an upgrade path. Jakub, we need to focus on release management based on the dev effort, but going forward an open question is what would be the best way to do release management.
- Need to determine the toolset we want to use.
|
| | Requirements for deployment | | Working towards a deployment example that could be adopted by many libraries. Usecases: - We have a running system and you discover you need to add a new module for new features. How do we do this without a full install and where do we get the knowledge of dependencies? Can we use the package management tools of Linux? Jakub, FOLIO has a dependency model based on that design pattern. Much like "apt-get". The difference is that FOLIO focuses on interfaces. "Apt-get" does not do this. We also have versioning again based on the interface level. There is a tree of dependencies which are interfaces for each of the modules. They must match. Semantic dependency versioning.
- Do we want to treat FOLIO as a unit or granular artifacts? The single unit is traditional for the ILS. Libraries are starting to become more comfortable with the granular update. Are we looking at coherent bundles? Ex. Circulation. Group seems to be in agreement on this. We need a tool/process to repackage a module as needed to create the bundle. This needs to be part of the upgrade process.
- We should use the container approach to eliminate risk for non-UI upgrades. Containers should be common currency of the upgrade process. Due to database upgrades, reversibility is a must have, but containers don't cure this. OKAPI has a hook that can be used to upgrade data. This is based on a lot of trust in the module. We need to consider replicating the data prior to migration. This migration process but always be used in a test environment 1st.
- Need dashboard/reporting on what is happening in a container. Orchestration tools handle this. FOLIO is agnostic to these solutions.
Also find out what are minimum requirements for production deployment. What environment should the common example make use of: (suggestions) - on-premise vs. public cloud
- operating system (Ubuntu/Debian (using Debian packages), RedHat/OpenSuse/SLES (using RPM packages))
- number of servers (3-5 ??)
- orchestration tool (Kubernetes, SaltStack, Swarm, Apache Mesos, ...; AWS, Azure, OpenStack, Google Cloud, ...)
- up-time requirements (99,5 % ? )
- tool for continuous deployment / release management (depending on up-time requirements) (Spinnaker) - Depreciate, mostly for dev organizations.
TAMU: - Leaning to Kuberneties and Rancher front end
- Tod would like to see a write up on how they came to this decision. Docker swarm makes many assumptions which is difficult when they don't have mush control over the environment
- Anton owes a list of Orchestration tools
- TAMU will outline their decision points
- ID will look into aligning the example and directions to this
- Look at minicube as well
|