You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The `Deploy` classes are coupled to the scheduler and also the flow
objects in a way that is not clear. It's also not clear which of the
public attributes are depended on externally and which are internal
working out.
The intention is to make clear what the interface is that the scheduler
depends on and what the flow object depends on as a result of the job
runs. Initially I tried to refactor the `Deploy` objects themselves to
make the existing objects clear, however this failed due to too many
moving parts and the level of coupling.
This commit introduces a `JobSpec` pydantic data model that gives a fully
typed and runtime validated model containing everything the scheduler
needs to run the job. The scheduler no longer receives `Deploy` objects,
but instead `JobSpec` objects created from `Deploy` objects. Which means
`Deploy` objects become `JobSpec` factories.
In addition, the obvious dependencies on `Deploy` objects within the
flow objects have been replaced with an expanded `CompletedJobStatus`
pydantic model. There may still be dependencies that exist that have
been missed, but the main ones have been removed in the results
processing path.
This opens the way for writing tests for the scheduler, and potentially
the launchers, against clear interfaces using data classes as inputs and
outputs.
There is room for improvement in the data classes, as some attributes can
potentially be removed with some refactoring.
Signed-off-by: James McCorrie <[email protected]>
0 commit comments