2018-07-27 - System Operations and Management SIG Agenda and Notes

 We've tagged a branch of https://github.com/folio-org/folio-testing-platform as "Q2-2018" and included a `yarn.lock` file and two Okapi install files (one for the backend modules, one for the front end) that are pinned to specific versions. We've also overhauled the single server installation guide in https://github.com/folio-org/folio-install to explain how to build a system based on this release. The goal is to provide a more repeatable build experience, based on a tested configuration.

Let's all try this out on our local installations! See the discussion on Slack in #sys-ops.

Notes:

See https://github.com/folio-org/folio-testing-platform, the Q2-2018 branch contains a set of artifacts for Q2-2108 "release". It is a set of code that passes regression tests. Still a rather informal release process, expect to do this quarterly. This is a Yarn platform that contains a JSON description of the platform with module numbers and similarly for stripes. Contains three files that pin down versions of the artifacts for building: yarn.lock, okapi-install.json, stripes-install.json.

Changes also to https://github.com/folio-org/folio-install to install based on the Q2-2018 tagged branch, locks version of specific version of the apps/artifacts. Builds have become consistent. Have changed deployment method. Instead of using separate deployment descriptors, the procedure takes advantage of the Docker-based launch descriptor including with the module descriptor in the central registry. All backend module descriptors now include a launch descriptor (tells Okapi how to launch the Docker containers).

Also tagged the folio-ansible repo with a Q2-2018 release.

Questions:

What about upgrades? We don't want to drop the database and recreate from scratch? There is scaffolding support in Okapi to initialize a new version of a module, to migrate storage module and apply database upgrades, and alert other modules in the tenant to the new version. Doing this in production will be tricky for database changes. For modules which have no storage it is trivial. We should start getting experience with that scenario (upgrades).

How often can we release tagged versions across modules? Current plan is to do a tagged release quarterly. Some sites may well want to do more frequent updates in production. Chicago expects to put in updated code once a week. Anton: we need to work out a procedure to update an application (a set of modules) on a more frequent schedule. Wayne: it may be possible to do more frequent tagging to make upgrades for testing easier. Dale: we should automate this with integration testing. Wayne wants to bring up the issue of intergration (or integrative ?) testing in the DevOps meeting.

Question from Wayne:

There's a procedure for creating a superuser which is convoluted. One thing the core team is talking about is whether the user management modules (mod-user, mod-login, mod-permission) should (a) create a user for you, so there is always a user there for you, or (b) use other methods to create an initial use, such a providing a script?

There is a preference for not having a default user and password (which some site will neglect to change) but to have a script which we can use and set parameters. Also a thought that it's more clear to make the script be part of the one-time bootstrapping procedure. Makes more sense than having special code embedded in the modules. See issue FOLIO-1336. This is also related to securing Okapi, see also the existing documentation on securing Okapi.