The custom configuratoin view should be a simple QWidget instance widget rather than a class or factory. This would be simpler and more intuitive for the user to create. It also allows for factories/methods/classes as the user can just call them.

Sometimes a set of files should be uploaded once only for a number of runs. Support for datasets could be added, such sets would be symlinked on the remote machine would be useful for these cases. (Low priority)

Uploads, job submission etc should be handled in the host, and in a separate thread. The best option for this will be to run the runner itself completely in a separate thread.

Note that config data can be treated as immutable, with the exception of data added by the runner (i.e. to the datastore), which greatly simplifies the implementation.

Files should be downloaded locally and made available to post processing through function calls which provide the local directory.

A common interface for every host should be specified somewhere, probably as a list of kwargs. If a Plugin needs to extend this, it should be possible/reasonable.

host_patterns (i.e. the pattern list to match against kwargs) should be validated when first loaded, i.e. that only valid kwargs are present, that each kwarg is present at least once. Also should validate that identical set of keys should not appear twice.

The error raised at

makes no sense, it should be either removed or replaced with a correct one.

It looks like it doesn't affect anything serious though.

Replace lines at

Fields should have help strings that have some sensible default behaviour.

From a windows machine, remote paths are created as a single directory named 'rynner/plugin_id' rather than a directory rynner containing a directory plugin_id.

This is preventing the discovery of jobs which have been running or have been run on a windows platform.

Currently the interpreter is hard-coded in the jobcard shebang to sh. Should it be possible to modify this on a per-job or per-plugin basis?

A slurm= or pbs= keyword for RunManger.new should allow options specific to a given host to be entered. In this way we can extend for a given scheduler without breaking the interface.

Should call datastore, and datastore should fire a signal when finished

Exceptions in another thread should be handled by signal/slots mechanism and user notified.

There should be a way to open the downloaded results folder in the default/OS file browser.

Would be nice to specify, e.g.:

( '--#FAKE {memory} {cpus}', ('cpus','memory') )

Currently a user has to enter their details into a relatively cryptic YAML file in order to use the cluster, as well as generate an SSH key to use.

Ideally, a user should just supply their cluster username and password on first launch, and Rynner should create an SSH key, upload it to the cluster, and edit the cluster configuration YAML such that on future launches it knows the username and key location.

Double-click on an entry in the index view shows details view of a job

The plugin collection should have a create view which allows the appropriate plugin to be selected and shows the appropriate view. Currently an exception is thrown in PluginCollection.

The calls to connection and datastore should all be done asynchronously. This is expected to be implemented by the Connection object popping work onto a processing queue. All jobs to one host should go to the same queue, ensuring that the order in which transfers and commands are performed is maintained.

RunManager should be able to create a run on multiple hosts or multiple runs on the same host. A good way to mange this is required, e.g. a parent-child relationship between runs and a run container object at the top level. It may make sense to reflect this in the remote file system (i.e. a parent job containing the directory of a child job)

...not implemented yet!

There are some functions with similar if not identical functionality such as data transfer, they can be merged.
I'd also remove nested functions.

Paramiko uses auto-add policy, this could introduce vulnerabilities to MITM attacks.

Network failures/host inaccessible should be shown in the index list by some visual indicator.

Not tested that TextField (etc) gets added to QLayout. The tests only verify that TextField is a child of this parent.

Each plugin should be able to operate easily with any host (default) or should be able to declare in an easy way its supported machines/types. Each plugin should be able to say it only supports specific machines (e.g a known set of clusters), or classes of machine (e.g. SlurmCluster). The eaiest way to achieve this is to provide a function for use with DropDownField, which filters on the global list of available hosts. It is then left to the user to support various hosts.

The problem remains on the best way to identify a cluster, presumably with some identifying string.

Should be able to specify defaults to PatternParser on a per-plugin and per-host level. Each plugin should be able to specify defaults for a given host or host class.

should there be a mechansim for the plugin author to configure the remote path?

sacct should only need to be called for jobs which are known to be completed. In this case we can store/retrieve info from the datastore.

A job list needs to be fetched from the server periodically, this could be just a job listing. Then, squeue (and/or sacct) would only be called if there are uncompleted jobs.

The job list should not be checked every time, ideally there should be a check for new jobs relatively rarely. When running jobs are known to exist, then we should check for updates of existing job progress more frequently.

squeue should potentially be used over sacct if possible.

This is a hold-all issue for better control of host configuration and configuration for a specific host/cluster. Ideally plugin should be able to heavily customise the host behaviour if needed, without needing to re-invent the wheel.

API changes between scheduler versions need to handled, presumably by the same mechanism by which scheduler option_map is selected.

values of RunManager.new kwargs (e.g. walltime etc) should be validated. This could for example involve a given type in a given interval. Errors should be shown before the jobcard is written gets written, so that the errors can be handled before putting the job in the queue.

Script kwarg when creating a new run should be a positional argument, since it is required.

Current jobs cannot be stopped. Stop button should call (on slurm) scancel with job id.

Finish hanging pieces or remove them completely.

Currently, an incomplete job cannot perform actions and has no files available to it. In many cases, it would be desirable to be able to download and post-process a job before it finishes running.

The download option to the runner should result in an automatic download when the job has finished. In addition, there should be a way to explicitly initiate a download in postprocessing/actions.

"All" view should be shown if there is more than one plugin, but hidden in the case of only one plugin.

Review the methods in PatternParser, some could maybe go into Host in the new architecture.

Fetching job details from the cluster hangs the interface. This would be solved by moving all communication to another thread.

There should be some default archive action, and ways to modify this. This would involve adding a QPushButton to the index view.

The config view should use QValidator to validate inputs and give user visible/instant feedback on invalid inputs.

RunConfigView contains a reference to the dialog which contains it. This should be avoided.

Need framework support for testing plugin behaviour without having a cluster etc.

QID should be read from the run on submission, and stored in datastore on first write, this avoids the need for reading a second time (i.e. supurfluous writes when reading job info from datastore)

Implement actions. Actions should be able to get hold of an instance of the parent/main window as arguments to the action function.