pavilion2
pavilion2 copied to clipboard
Redesign how series and tests are named.
In our effort to get rid of filesystem locks, we must change how Pavilion generates test id's and series id's.
I propose the following...
Group ids:
- Start with an uppercase letter.
Series ids:
- Emphasis user-specified names, maybe by requiring it by default.
- Can contain dashes, underscores and numbers, but all lowercase.
- Must be of length or contain characters to differentiate it from a 32 char hex hash.
- In the absence of a user specified name, pick two randomly from a dictionary composed of:
- words of length > 2 and < 5
- All ascii and alpha.
- With problematic words (cursewords, slurs, etc) removed
- That leaves a list of about 4200 words, which when doubled gives us 17.6 million combinations.
- Collisions only matter as a race condition - we can check the existence of a series name before using it.
Test ID's
- Test's should be numbered by series. So given a series 'foo' it would have tests foo.1, foo.2, foo.3.
- Tests would still have a uniq ID, but that wouldn't be presented to the user (much like how you never see the build hash). These would N digit hashes, probably configurable via pavilion.yaml.
- This would do a couple of things:
- Remove the need to tag/name different configuration directories (the link from the series file would get us there).
- Remove the need for locks on test ids, as these numbers would be generated within the same process.
- Like with series, we only need to worry about collisions as a race condition, as we can always regenerate a new hash if a collision exists. Since these are never seen by the user, I'd just go with a hex encoded UUID4.
With the exception of series ID's that look like hashes, these should all be unique in form.
For convenience, when referencing series relative test ID's, the last series run or last series mentioned should be assumed.
# Given that we just started series foo-bar
pav status 1 2 3 baz.1 2 3
# Would be the same as
pav status foo-bar.1 foo-bar.2 foo-bar.3 baz.1 baz.2 baz.3
Test ID's should be able to contain dashes too, to specify a range. pav status 1-3 baz.1-3
None-existent tests should be silently skipped.