2020-06-03 Meeting notes

Hear presentation, review discussion and recommendations on this page:

Upgrades with Reference data

Discussion:

• Drew potential comparisons to Linux -but that only goes so far 
• Are there dependencies on "labels" as well as (or opposed to) UUIDs for some data (like a status or an identifier type) - we think both are likely
• Need to preserve the idea that some values need to be immutable
• Major point is that the difference between data that can be modified and that which should not is not clear.
• Agreement that there is an architectural challenge
• Definitely user facing challenge as well (it's easy to get conflicts with data that comes with the system).
• Design problem in that data defined in one module is required for operation of another module.
• At practical level, useful to have examples of successful upgrades vs. failed upgrades (ACTION)
  • 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?
• Need further discussion.