Page Comparison

Last week's discussion ended with: 

• ACTION: At practical level, useful to have examples of successful upgrades vs. failed upgrades
  • Help us identify near-term practical actions as distinct from long-term strategy.
• Need distinction between data in a data set that is provided by the system vs added to or modified by tenants
  • Have some examples of crude solutions this in some places, not consistent
  • Possible to store system data in separate place, present unified view, or resolve issues after upgrade process, before opening to users
  • Integrity issue when required value goes away.
  • What happens when you introduce a new required value?
• ACTION: need to catalog the types of reference data so we know what we're working with
  • VBar and Craig McNally will work with implementers
• Need further discussion. 

JIRA FOLIO DevOps sprint ticket to be added here

RE: discussion of immutable data - wondered if we have explicit flags (like isReadOnly) in the UI... don't think that exists.

Problems: 

1) Upgrades can fail and stop for reasons that aren't truly fatal

2) FOLIO Installation/upgrade comes with a data set that may need to differ for a given deployment since they'd customized that data set from a prior deployment - not a good way to understand/deal with this scenario

3) There is no way to flag data that a module requires as "immutable"

4) Upgrade shouldn't leave the system in an unusable state

Note that Craig surveyed FOLIO implementers and there wasn't a clean/consistent list of reference data. Suggestion to consult Anne L. Highsmith at TAMU. Christie Thomas at Chicago may also be a good resource.

Need a concrete list of what operational issues can be solved in the Honeysuckle release - would need a recommendation practically in July.

Need a Tech Council Champion. spampell volunteered.

Jakub Skoczen