Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redesign how series and tests are named. #734

Open
Paul-Ferrell opened this issue Jan 26, 2024 · 1 comment
Open

Redesign how series and tests are named. #734

Paul-Ferrell opened this issue Jan 26, 2024 · 1 comment

Comments

@Paul-Ferrell
Copy link
Collaborator

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
@Paul-Ferrell
Copy link
Collaborator Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant