| Time | Item | Who | Notes |
|---|
| 5 | Welcome | Ingolf | - Find a note taker (might be myself) : Harry
|
| 30 | Q1 Hotfix release | all | The Q1-2020 Fameflower Hotfix release was released May 1st. Anton announced it. Let's discuss our experiences with it so far. - Chris Creswell did a post in #sys-ops today:
- The hotfix application worked smoothly in his development environment, then not so smoothly on his shared local test instance.
A few modules reported errors when enabling, but his script to enable modules actually tries twice for each module, and the second time it worked for each. Okapi reports the expected module versions enabled for his tenant, and everything seems to work as he clicks around in the UI. But he does wonder if the second attempt at enabling the modules did any of the database schema updates or not. He is going to use a check_postgres script that he found to compare the schemas between his development environment and their test instance to see if anything is different.
- Jason reports some failures of the schema update scripts on the TAMU tenants.
- His first run at the migration from Q4 to Q1 Hotfix seems to have been successful for the Diku tenant where he has reference and sample data loaded.
- Updating the TAMU tenant failed.
- Historical circulation migration data is getting difficult. Across FOLIO versions, migrations have not worked. Also, getting history from Voyager is getting more difficult. Important to current and existing libraries.
- A problem for historical open and closed loans data. Needed for historical reporting. Some libraries may decide to not transfer closed loans.
- Developers potentially lack an unerstanding of what is needed.
- Difficult for migration and offline circulation!
- Needed for reporting as well. Might be stored in a separate file.
- No stories written for this.
- It is pretty important to fix this.
- How and when to suppress notices for migrated data? Saving tenant configuration until after migration seems to help. Or set to an invalid server, disabeling the email system.
- ToDo: Discuss with PO team. Need to define requirements. Harry will bring this up in the next PO meeting. It's a long term issue. Planning for Q3.
- Chalmers upgrade plans to Q1 (report from Patty)
- Chalmers does a dry run in the sandbox
- Theo clones and ports the data
- Fameflower for University of Alabama (Patty)
- 2nd week: testing & training
- next week EDS integration, NCIP integration
- iterative go-live within three days in the week of June 6th
|
| 25 | SAML integration | Tod | - SAML integration at Chicago
- Mod-login SAML is not federation aware. No way to get automatic updates. No self registering.
- How can configurations be preserved between instances (certficates change, backend urls change, metadata change)
- Federation support is really needed.
- Want to release SAML attributes for actions in FOLIO.
- We need a gatekeeper for login. Something which says "this identifier is in the set of authorized logins"
- A particular identity can be automatically authorized to login.
- Qulto developed mod-login and mod-login-saml; they are not getting enough attention
- These are real important modules
- mod-SAML isn't actively maintained. Will be very important over the coming year and more. It definitely needs ownership, it's own service provider.
- It would be an advantage to FOLIO to have active dev in this area.
- Apache has modules for being a provider. NGINX has a 3rd party tool for this as well (it probably uses fast-cgi). Could FOLIO rely on these tools for SAML authentication and attribute release. Would eliminate the need to maintain the FOLIO SAML code.
- FOLIO would need to be able to consume the data from both modules.
- ToDo: Need several tickets for this in JIRA. Tod will create the ticket. These will be new requirements which will have deployment consequences.
- There is a ticket for "federation support". "Login authentication atrribute" tickets are needed.
- Need a PO for this. PO will write high level requirements and do priorization.
- It will probably belong to "core platform" (but doesn't have to be)
- Should also look at who owns the patron user loader.
- This group will need to identify use cases. We take this on as a topic for this group.
|
| x-tra time | General; Organization of the group | all | - Need to do a better job of circling back on architecture changes such as searching, data stores, etc.
- We want to get some involvement earlier on; espscially those, who are in a self-hosted environment
- Somebody from SysOps, in addition to Harry, should go to the PO meetings
- Topics like using Elasticsearch or Solr as search engines emerge
- These topics should not always come up as an afterthought.
|
| Ingolf added |
|
|
| Topics for future meetings |
| - reported failures in database schema updates in Hotfix release
- Migrating historical cicrulation data (Harry will discuss this in the PO team). We need stories written for this. It is important to fix this.
- mod-saml and mod-saml-login are not being actively maintained; they need ownership. Federation support is needed. Tod will write up requirements. This will need a PO and several JIRA tickets.
- (group:) Identify use cases for SAML authentification.
"Circling back" on architecture changes; new topics will emerge; we need to get involved earlier (especially for those in self-hosted environments) ==> How are we going to improve on this ? |