2020-05-15 - System Operations and Management SIG Agenda & Notes

• New member Chris Rutledge of TAMU - Welcome ! - Chris has been at TAMU since 2005. He is a system administrator. He has been working in the team for 8 and a half years now and will take on leadership in the library systems group. Steve is changing to the division of (campus) IT services. He will remain in the Folio project.
• Review Action Items → deferred
• have a regular update on core dev related developments; architectural changes in planning or development
  • See also Folio Architectural Blueprint Strategic Changes
  • There are columns "champion" and "participants". There is no formal way to communicate this, yet. I you feel you would like to raise your voice on one of these topics, please address one of the persons in "champion" or "participants".

The FOLIO Code of Conduct has been endorsed by the Product Council .

There will be CSVs - Community Service Volunteers - to enforce the regulations of the Conduct.

• upgrading a FOLIO system with loadReference=true as a tenantParameter
• currently causes conflicts
• solution might be to perform upgrades without loadReference=true

Blog post: https://app.slack.com/client/T1EPYQDAQ/C9BBWRCNB

• distinction between reference data and sample data is a gray area
• Italy doesn't use "loadReferences" when they update
• reference data implement RDA vocabularies
• tenant initialization of the module
• some reference data are editable by the user
• when you upgrade with "loadReferences", local changes will be overwritten
• load references first tries POST. If that fails, it will try PUT. It may run into a problem, because the record does not exist. PUT tries an overlay. It will fail, if the record does not exist. The Upgrade stops then.

Let's not discuss the failures. Question is

What behavior do we want ?

(Ingolf)

• Existing (local) data should not be changed.
• Only new reference data shall be loaded when using "loadReference=true" for an upgrade(Jo)
• "loadReference" should load everything anew, ignoring local changes. If you want to keep local changes, don't use "loadReference"

Jason: At A&M, we do "loadReference" = false. Then there is the risk that some (new) reference data are missing and that some functionalities are not working, because of this. But this risk is small. It is an easily correctible risk.

All: We need to define a harder boundary betweem reference data and sample data. The location should be sample data.

We need to safeguard reference data against changes. Reference data = a default set of data which I can overlay.

Wayne: We could work in stages. Put together (reference data in stages). But this will make migration tough.

Tod: We can not solve the whole question in this meeting.

Wayne will open a Discuss Post on migrating reference data.

• Harry signifies that someone from the Sys Ops SIG could join PO meetings and and discuss with the group the impact of certain decisions or lack of decisions  that impact the people that must support FOLIO in the library. There is no need to attend each PO meeting. - Volunteers ?
• E-Mail support / SMTP support - does this work, has this been tested ?

Yes, this has been implemented in Italy (National Library of Florence), at IndexData and at TAMU.

It uses a standard SMTP setup. Needs an SMTP server. Better with SSL support. Italy uses Postman.

At IndexData, they are using Amazon SES, an SMTP Service.

At TAMU, there is a Campus SMTP. One needs to post JSON-Documents to it. Here's documentation about TAMU's E-Mail configuration: https://github.com/folio-org/folio-install/blob/kube-rancher/alternative-install/kubernetes-rancher/TAMU/deploy-jobs/create-email/create-email-config.sh

https://github.com/folio-org/folio-install/blob/kube-rancher/alternative-install/kubernetes-rancher/TAMU/deploy-jobs/create-email/Readme.md

• Delete or edit (e.g. translate) pre-defined settings - for some settings that does not work. E.g. Settings - Inventory - Resource Types (not editable). But Settings - Inventory - ILL Policy: can edit and delete.

These settings are firm, not changeable. The source is RDA. This is by design.

If you want to translate, that's part of Internationalizaton. Knowledgeware has been working on this and gave a presentation in the Product Council just recently, on April 16th. Here is the link to the agenda & meeting notes of that day: https://docs.google.com/document/d/1puq9ySnP1RG583TOLDCh9hPZTBxSp4cJtZu_y-7W5hU/edit

And these are the messages in the chat of that day: https://docs.google.com/document/d/1Q3UQsXFjPhezViQ6UmJaHCihB8ZSf3QF8IpcPWayEeI/edit  

There should also be a recording of that meeting available.

Generally, questions like this are to be addressed to MM SIG, not to SysOps.

• Upgrade path - is there a documentation ?

Report from Support SIG

Report about TC Architectural Blueprint / Strategic  Changes

Phil

Mike

Not before June.