2020-05-22 - System Operations and Management SIG Agenda and Notes

Find a recommendation of SysOps to the core platform dev team

See the Discuss post here https://discuss.folio.org/t/reference-data-and-upgrades/2858

Wayne summarized the issues and ideas proposed during last week's discussion in the Discuss post referenced above.

We need to describe what we want to have happen.  Upgrading a module is really replacing it.  When a new module is replaced, Okapi tells the tenant and passes any parameters it has been told to.  

1. We need to define the desired behavior
2. Come to a project wide consensus. 

We need to make a clear distinction between sample and reference data.

We need a change log.

Would like a diff between the previous state and the current state for the reference data.  If we have this, we can give this to the librarians for review.

We also need a log for anything else that might have changed.

Wayne spoke to a developer.  We might actually need 3 classes of data:

1. System data.   You cannot configure this.  You can't delete this. It just gets loaded. We don't necessarily see it in the system.
2. Reference data.  Large vocabularies.  Critical for users.
3. Sample data.  Used to populate a bare bones system for demo purposes.

System data gets loaded either way. Reference data only gets loaded if "loadReference" is set to "true".  Changes and deletions will be done in an "overlay record". A User should be able to overlay but never change. The original record will be preserved as a fallback.

How do we report non-fatal errors?  FOLIO only supports "success" or "failure" today.  We need to add warnings.  More verbose logs are required as well.  We need to see the steps that occurred.  We just don't know what happened.

A proposal must be created and then presented to the TC since this will impact all FOLIO applications in a future release.  Once agreement is reached, this change can be planned for a future release. The upgrades should happen in a consistent and meaningful way across Folio. This is important and critical.

Agreement:

1. Failure to load reference data should not be a fatal error to the upgrade.
2. There needs to be a clear indication in the logs so the operator knows that there was a problem with the reference data

spampell will take this to the TC. Johannes Drexl will write up a longer-term proposal. Jo has created a Wiki page for this: Upgrades with Reference data

Reference data loaded by the system by default should be kept minimal. I.e. there will be only one default location and only one default user group.

SAML: Tod Olson is collecting needed enhancements for SAML authentication. The most obvious needs are to be federation-aware (see UXPROD-556 - Getting issue details... STATUS ) and some awareness of SAML attributes for explicit login authorization and possibly other permissions. Will write a Discuss post to solicit and collect input.

Ingolf: This is more a question for the group now (not just a task for Tod): Do we have use cases for consuming SAML attributes ?