Skip to content

Add keys and key management commands to the configuration database

Louis Moureaux requested to merge feature/configuration-keys into main

Description

This adds two new tables to the configuration database created in !223 (merged):

  • key: contains all available keys, intended to be physics, testing, calibration, etc.
  • key_version: contains the history of keys and makes the link to the configuration table.

Both tables could be augmented with more metadata following feedback or in the future; I kept them rather basic in this first iteration.

In addition, this MR adds code to work with keys to gem-configdb. They can be used to produce keys for testing (see the testing section below for examples). It is expected that they will eventually be used to manage keys in production.

Related Issue

I guess #121 is relevant here.

How Has This Been Tested?

Following these steps will modify your database

The following commands assume that you're working from a poetry shell.

Start by migrating your database:

gem-configdb alembic upgrade head

Then, add a few configurations:

gem-configdb create-configuration
gem-configdb create-configuration
gem-configdb create-configuration
gem-configdb create-configuration
gem-configdb create-configuration

The number printed by the command is the unique ID of each configuration.

Next, create a few keys. The description is mandatory, but it's just my personal preference:

gem-configdb create-key cool 'Keep it in the fridge'
gem-configdb create-key warm 'What about a few days off on the beach?'
gem-configdb create-key jump 'Look, a kangaroo!'

Let's check what we've done:

$ gem-configdb list-keys
cool    Keep it in the fridge
warm    What about a few days off on the beach?
jump    Look, a kangaroo!

The keys are still a bit lame though:

$ gem-configdb cool
<No version>

Let's cure this by assigning configuration number 1 to each of them, and making good use of the optional message parameter:

gem-configdb new-version cool 1 -m "Maybe I'll leave this whole thing alone"
gem-configdb new-version warm 1 -m "Another one bites the dust"
gem-configdb new-version jump 1 -m "It's a kind of magic"

The numbers you see are the revision number created for each key. Anyway, it's now much better:

$ gem-configdb history cool
  0 ->    1: Maybe I'll leave this whole thing alone

What do the numbers mean, you'll ask? Let's create more versions to understand better, alternating between configurations 1 and 2 because one of them works in the morning and the other in the evening (you suspect an interference between VFAT numbers and the position of the needles in the OptoHybrid clocks):

gem-configdb new-version cool 2 -m "Three little words to make it all better"
gem-configdb new-version cool 1 -m "I'm gonna get you on a telephone"
gem-configdb new-version cool 2 -m "I'm gonna write you a long letter"
gem-configdb new-version cool 1 -m "And enemies make the most interesting friends"
gem-configdb new-version cool 2 -m "that everything turned out so bad"
gem-configdb new-version cool 1 -m "I think it's stupid and sad"

Now we get something more interesting in the history:

$ gem-configdb history cool
  6 ->    1: I think it's stupid and sad
  5 ->    2: that everything turned out so bad
  4 ->    1: And enemies make the most interesting friends
  3 ->    2: I'm gonna write you a long letter
  2 ->    1: I'm gonna get you on a telephone
  1 ->    2: Three little words to make it all better
  0 ->    1: Maybe I'll leave this whole thing alone

So the first number is the key version and the second is the configuration number.

Oh, and what if we don't specify the optional message?

$ gem-configdb new-version cool 4
$ gem-configdb history cool
  7 ->    4
  6 ->    1: I think it's stupid and sad
  5 ->    2: that everything turned out so bad
  4 ->    1: And enemies make the most interesting friends
  3 ->    2: I'm gonna write you a long letter
  2 ->    1: I'm gonna get you on a telephone
  1 ->    2: Three little words to make it all better
  0 ->    1: Maybe I'll leave this whole thing alone

That's it for today (unless you accumulated too much backlog and already want to test the next MR). To clean up, delete the two tables by downgrading the database to the version from !223 (merged):

gem-configdb alembic downgrade 27bf64fed3c3

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.
Edited by Louis Moureaux

Merge request reports