RunConfig DB requirements notes

Discussion 15 March 2019 (Bill, Ron, David, Wes, Gennadiy)

Want to separate specific technologies from concrete requirements:

• Downloading/uploading configurations should take nearly negligible time (< order 10 s for even large configurations necessary, < order 1 s goal)
• user-friendly interface for modifying and creating configurations
• need ability to download/upload configurations into/from a set of local fcl files
• historical configurations need to be retrievable forever
• run configurations in database are immutable
• name/version number for configuration defines a unique configuration set, and is immutable once made
• hot failover/or reinstall from backup on order of hour (and would be done by expert that is accessible 24/7)
• if a DB fails and we need to move to a local failover or backup, shouldn't lose more than 10 minutes of information from configuration or run history DB at a normal level of reliability
• should have daily-to-weekly full backups to out of experiment hall (via TIBS?)
• RunHistory DB either must be offline query-able or copied to someplace offline query-able
• online configuration DB must be query-able (e.g. 'give me all configurations that have x parameter set to y value') and it must "pretty darn quick"
• need a utility to compare the difference between configurations
• would be good to make a configuration 'taggable', such that when you ask for a configuration by tag/alias, it gives an expert-identified one (note: while name/versions cannot be modified, aliases can be modified to point to different configuration)
• there should be support for subconfigurations, and subconfigurations follow generally the same needs as configurations (immutable in history and once made, query-able, have names and versions, etc.)