...

• configdb_key_history: this script can be used to explore configuration history. It takes hutch, alias and device as arguments (plus authentication information):
  

  python configdb_key_history.py --user tmoopr --password pcds --hutch tmo --alias NOBEAM --device hsd_0

  And returns a list of configurations for the specific hutch/alias/device with date and key. The key can be used to retrieve the specific configuration using the configdb_rollback.py script.
  
  

• configdb_rollback.py: this script can be used to retrieve a specific device configuration, and, optionally, to make it the current configuration for the device. It takes hutch, alias and device (and authentication information) as arguments, plus a key defining a device configuration (see the configdb_key_history.py script above):
  

  python configdb_rollback.py --user tmoopr --password pcds --hutch tmo --alias NOBEAM --device hsd_0 --key 266

  
  By default, the script just shows the configuration. However, when the --write-to-database option is used, the scripts write the retrieved configuration as the current configuration of the same hutch/alias/device.

Configuration History and Keys

DISCLAIMER: The following are just deductions. I (Valerio) have no direct insight on how configuration keys work.

• Keys are like commit in a git repository: they are snapshot of the configuration of all devices in a hutch at a certain point in time. Much like modifying a file generates a new repository state (a "commit") the same does modifying the configuration of a device
• Each new change of the configuration of the device in a hutch (irrespective of the alias, BEAM or NOBEAM), generates a new key (key numbers are integers increasing with each configuration change)
• Continuing with the git metaphor, aliases (BEAM, NOBRAM, etc.) are like branches in a repository