- options (e.g. walltime) don’t have any concept of a type, e.g. 10:0:00 should have some defined type/format (e.g. time delta) and some cluster-specific conversion to the correct data type. There should be some validation on user input here. And some errors thrown if it’s wrong.
- How does a plugin KNOW what interfaces can support it?
- How do we do multi-cluster configurations? a host each? how are they identified? [by name? domain? both?]
- OK FOR NOW: uploads should be handled in the run method of the host rather than in the run? Note: should this be added to the context first, then uploaded when run is called?
- Could make Run a method on Host actually? Since parse and run are all called at once.
- Are there cases where I might want to parse and THEN run?
- starts uploading without creating a base directory! create directories lazily in the connection?
- implement downloads on the host and call them from the Run
- implement sync, host, or maybe something in the action mechanism?
- Rather than parsing script out, it makes sense to make script a positional argument (since it is mandatory)
- Need to work out where the remote base path is computed??
- Double-click an entry in the index to bring up a simulation view
- setting interpreter (#!/bin/bash) not tested
- need to be able to get hols of main window in actions
- Rather than parsing script argument out, does it makes sense to make it script a positional argument (since it is mandatory)? Should I put all the mandatory arguments first?
- In principle, the same run manager could create runs for multiple hosts - how is this handled
- this “knows” about the dialog which contains it - it shouldn’t!
- tidy this up?
- maybe the buttons should be outside here, so it can be overriden in a sensible way?
- there should be an “archive” button, which has some sensible behaviour but also a user-specified behaviour
- some TextFields might have units…? and default value should be settable in a non-string form
- labels should be translated to human-readable form
- an empty/blank QWidget wrapper?
- : validation
- cli
- cli should do something sensible on exception (e.g. loop)
- some reset method to reset the value to default (so it doesn’t maintain previous value)
- Run creates Stop by default
- probably easier if the end user will pass a QWidget rather than a factory
- Plugin collection should have a create_view by default which allows choosing between multiple run types then proxies the selected view…
- PluginCollection.create not implemented (either do this or hide it in the view)
- is plugin.create really a good idea? or better for the framework to do the heavy lifting?
- PluginCollection has no create_view method
- doesn’t really do anything - and not integration tested
- shoud connection be contained entirely within Host (i.e. pass in user and host/domain name)
- update downloads details of all jobs
- should BASEDIR (i.e. id) be passed in when Host initialised?
- how do I specify files for upload/download only once (i.e a dataset)?
- implement download as: download(id, downloads):
- id is passed around a lot here for u/l and d/l, maybe there is another way?
- would be nice if I could specify string as ‘safdf {memory} sdfdsf {cpus}’ - and the variables being out of order, would that mess with when it’s order-based
- pattern_parser.update should be async (calls datastore, datastore fires a signal when done).
- move exceptions to their own file
- should submit command go somewhere else? maybe sub-classing is the way to go?
- pattern_parser should implement default options if they’re passed in
- the interface for a generic host needs to be enforced somehow/somewhere??
- custom options specific to a given host need to be passable
- …and the interface should not break??
- pattern_parser should check that the option map is valid, i.e.:
- all expected mappings are present
- identical keys don’t appear twice
- pattern_parser should check that upload completed before starting run!
- how can I override/subclass this for radiacally different behaviour
- “template” functions can’t currently decide that it will defer keys to a later function,
this could be useful, but could also be a source of errors if users forget to delete keys within the function
- run method should return running state as a boolean (maybe?) (for datastore)
- should I rename ‘script’ to ‘command’ …?
- there is no ‘default configuration’ for a scheduler/cluster implemented
- there should be maybe a ‘slurm’ option or a ‘pbs’ option, implemented as:
(‘{}’, ‘slurm’) or (‘{}’, ‘pbs’)
- Lists of strings should be flattened/joined with newlines before being passed to parser
- the interpreter string in the jobcard should be customisable
- calls to datastore do not appear to be implemented
- QID should be read from stdout and written to datastore, to avoid superfluous read/writes
- lazily creates base directory, but does not create any subdirectories
- make remote paths relative for u/l and d/l? what about local ones? Encoding them with id or pass in a directory name? Or should that be in pattern_parser?
- needs to be shut down when application closes
- AutoAddPolicy used by paramiko for now - change this
- should error when job fails
- what about different version number of SLURM??
- the fact that addWidget adds to layout isn’t tested (only that it’s a child of this parent)
- self.view_keys should be translated to human readable form using labels from run_type
- this means that run_type.labels should be set up even if it isn’t provided
- scheduler data list
- implement more BaseField subclasses
- validation on BaseField
- integration testing with a particular app? integration testing including uploads?
- valid() should return false if not valid
- QValidation => integer, double, regex
- change valid() to check with validator
- setup gitter!
- simulation actions should be able to get hold of the parent window, to do plotting
TextField, OptionField NumericField, Directory, File, HiddenField, GitCommitField, HostSelection