Add keys and key management commands to the configuration database
Description
This adds two new tables to the configuration database created in !223 (merged):
-
key
: contains all available keys, intended to bephysics
,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?
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.