2018-06-22 - System Operations and Management SIG Agenda and Notes

• Determine Note taker
• Review action items

Goal: Getting the project to a point where libraries can build and install a working and up to date version of FOLIO.  Libraries must be able to set up the code themselves, install it and set it up and run it locally (in addition to cloud hosting solutions).

TAMU - We are looking for a clean and repeatable way to stand up a version of FOLIO for testing by the library.

Anton - There was a discussion about containers to get a version runnig. Not ideal.

Wayne - The project cannot take up how you setup iptables for example. But agrees it should be simple to setup. But we can't support all the other different security options out there, etc.

Jakub - The project cannot provide instructions for every environment

Stephen - The basic tenant of how to deploy a folio platform should be the same. That needs to be documented along with the requirements and dependencies for a base system. The current documentation is very sparse. We don't need too much descriptive details. We need a layout for, for example,  "these containers will speak on these particular tcp ports" or "module dependencies for a base folio system".

Jakub - In agreement. But there will be lots of differences. For example, Hazelcast needs to be deployed differently on local network than on Amazon.

Stephen - WE will want to highlight those differences. WE need to document what needs to be configured no matter the installation.

Jakub - WE need a guide with a list of things that must be considered.

Stephen - The AMI images only work for people using Amazon. It's easy, but many of us will not work on that platform.

Jakub - The lowest common denominator is a local install. Barebones. Wayne has made these available.

Brandon - Waynes is the 1st thing they look at. But halfway through, it stopps working. A single server locally is the easiest setup. But that is what we have difficulty with. What versions work with each other to make it dependable.

Wayne - 2 tracks that would make this a lot easier

1. A system architecture guide from the SysOps perspective. Not developers or librarians. Sysops have different focus. Not like the Okapi guide and various documentations that we have from the perspective of developers. Addressing rather "How many boxes do I need ? What ports need to be open in between them ?"
2. A set of released code that does not change. It's a big problem with SysOps because the code is changing to fast.

Harry: Track 2 won't be a one-time thing.

Stephen - For the most part, it's dead on. For the 1st item, who is the most knowledgable of this in development? What person is knowledgeabe on track 1 on the software development side ? What person knows about the overall system architecture ? Not just in broad strokes, but in some of the more specific parts. Who has the architecture in his head ?

Jakub - A number of people have this. It should be in the guide, but from a developer's perspective.

Stephen - Lets have the sysops people with hands-on experience come up with a laundry list of what is needed. We should sit down with the developers who have actually been building to help us build the guide. What do we need to know from Stripes to Okapi all the way down to how the modules work ? Then we will come up with the actual documentation that we feel that we need or with the architectural guide.

Jakub - sounds fair. Maybe could this group build that list? What needs to be provided for the system's administrator guide. What are the details of what is needed?

Wayne - EBSCO has some experience here. System architecture discipline. I am talking about a hyprid layer where you lay your conceptual ideas about how your components talk to each other over your actual hardware. You can take that deployment pattern and apply it to other deployment settings.

Stephen - A best practices guide. Needs to layout the major pieces and how they communicate. Here is what works and here are examples. Doesn't have to be detailed. Want to know, e.g. about the pitfalls that Hazelcast has in each deployment method. Need to make knowledge about pitfalls upfront.

Jakub - Conceptual level. The EA level.

Tries to summarize:

1. We discussed a conceptual list/diagram of components of the system. Possibly missing. 

   What needs to get deployed.

2. Looking at different elements that need to get deployed and run. What are the pitfalls and what seems to work as a starting point.

Jakub - we actually have much of this. The information is clustered. What is missing is getting from that point to the list of things that are needed along with pitfalls and guidelines.

John - start with this at a high level and reference the current detailed documentation. How can we all collaborate in contributing to this?

Jakub - there is certainly a crowd sourcing aspect to this, but there needs to be an initial backbone to this.

Dale: Are all the components in place to have a productional setup of FOLIO run ?

Jakub: There is work to be done on orchestration work for FOLIO. That would be great to hear back from the community. But libraries are not yet ready to share it.

Wayne - There is a cultural barrier to some of this, like a GIT pull. There will be some handholding in some of this.

Todo: John M will take on track 1 initially.

Stephen: Release management is most important right now.

For track 2:

a. The tagged set of source in GIT, We need more discipline around binaries

b. Make sure there is a stable set of artifacts for a build. It won't be the folioci repository. It's more or less available now. Instructions on where the repositories that SysOps should be using.

c. A guide for people that just want to run the system.

d. Vagrant & AMI images. We should provide more granularity so people know what they are actually running.

e. Stripes - Having to rebuild to change a configuration setting is a problem. Needs to be fixed.

Wayne: For the latest tagged released tested Code, don't point at folioci; point at FOLIO for MPM(?) or Docker. We will publish regularly to that repository. At the moment, the only place to get artifacts is the folioci repository.

Jakub - It's wrong that you are forced to deploy a dev build. The guides need to be reviewed from that perspective. Nobody should need to pull from the dev repository.

Jakub: We can't tell people "pull the code from github".

Wayne: The only github repository you have to clone down is the Stripes platform. Everything else is an artifact of some kind.

Jakub: Need to update the artifacts regularly (one quarter or so). AMIs are essentially blackboxes, you don't know what you are running. We should aim for prepared artifacts, binary or not.

Anton: The Vagrant boxes are too slow. Expect a more complex but similar approach.

Harry & Jakub: We try to come up with a list of action items, put it in a document, and circulate them in this group. We are very close to the first thing. We are missing the first thing.

ToDo: Jakub, Harry and John will build a list of tasks to circulate with the group with feedback.

ToDo: This work should be in the folio install repo.

• refinded specifications and basic functionality by Carsten; including a UI draft. See the attached presentation 2018-06-20_FOLIO_Lightweight_Issue_Tracker_Description_04.pptx .

• Discussion of overlaps between the To-Do App (UXPROD-599 ) and a Lightweight Ticketing App (UXPROD-849).