[DNM][Conversation Starter] Job Queue and Machine Pool Abstractions #2078
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Create a new abstract base class for job queues. This allows any code implementing this abstraction to provide a teuthology job queue. Signed-off-by: John Mulligan <[email protected]>
Signed-off-by: John Mulligan <[email protected]>
Signed-off-by: John Mulligan <[email protected]>
Signed-off-by: John Mulligan <[email protected]>
Signed-off-by: John Mulligan <[email protected]>
Signed-off-by: John Mulligan <[email protected]>
Signed-off-by: John Mulligan <[email protected]>
The machine pool is an abstraction over some sort of automation that manages "machines" (real or virtual) for test runs. Signed-off-by: John Mulligan <[email protected]>
Signed-off-by: John Mulligan <[email protected]>
Signed-off-by: John Mulligan <[email protected]>
Signed-off-by: John Mulligan <[email protected]>
Signed-off-by: John Mulligan <[email protected]>
Signed-off-by: John Mulligan <[email protected]>
This example pool uses a local sqlite db to record a database of vms suitable for running tests. Script hooks allow teuthology to reset vm snapshots when needed. Signed-off-by: John Mulligan <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
IMPORTANT - I do not expect to merge this PR. It exists to serve as an example for two structural changes I would like to propose for teuthology. Mainly the use of ABCs for components that can be swapped out for other components.
While I have gotten code working locally using a version of these patches I do not expect them to pass tests or work in general. I finally found the time to rebase and clean them up to the point where I'm willing to show them. I want to use this as a discussion point before the lab move and before the CDS for "Umbrella".
If these ideas are good and worthwhile I can see breaking these into smaller PRs and properly testing and merging them.
The first abstraction is one for the job queue. We create a new ABC for the job queue and then convert the existing beanstalk and file queues to this interface. We provide a mechanism for choosing the right class and make use of the abstract job queue in the existing teuthology code. Finally I add an example 3rd backend based on a real WIP sqlite backend I have used on some of my systems.
The second abstraction is a bit bigger. It adds a new ABC for a "machine pool". A machine pool is some mechanism for discovering/reserving/releasing machines to run tests on. The exsiting teuthology code sort of has this concept but it's very squishy and not well defined. The new ABC tries to create a clear and well defined interface for this. It also aims to decouple the code from the current "lock server" that is directly used in some parts of the code base.
A "wrappers" lib is created to help ease the conversation between the new ABC interface to use functions somewhat similar to the existing ones.
The lock_server code is encapsulated in one new class. A demonstration machine pool based on a sqlite db populated with vms (and a hook script) is added to showcase the concept - it is based on patches I have used in practice locally.
Lastly, I do want to note that the ABCs are there to help define and clarify the interface between different parts of the code but the idea is not set things in stone forever. If an interface is found insufficient in the future it can be changed, but we hope that it's done so with the general set of consumers in mind not just a single use case. So while it may raise the bar a bit when something needs to change it should help when considering that change in the general context.