metomi / rose Goto Github PK

There may be cases when we only want rose suite-run to
perform different actions on specified task hosts. E.g.:

• A file to be installed may be large,
  and we only want to have it on the host requiring it.
• A file of the same name may have host specific contents.
• We want to set up a symbolic link to a file
  which only exists on a particular host.
• (Need to handle host names defined in templates.)
• Different hosts may need different root locations
  for their share/ and/or work/ directories.

We should allow users to specify a different rose config editor built in widget for a variable.

Currently, very long message lines will produce a dialog that extends past the screen limits - this should not happen.

It would be desirable to parallel process file installation.

Array widgets are among the most complex pieces of the configuration editor GUI code, and their behaviour and appearance needs further rationalisation and improvement. We need to make them more intuitive to use.

rosie go should open a suite in view-only mode by default
(unless the suite is already checked out).

In view only mode, we'll svn export the suite to $TMPDIR,
and when rose edit finishes with the suite, it will delete it.

We need to improve the config editor startup and updating times for large configurations or suites.

rose suite-hook to be created to handle possible suite hooks.

rose task-run and rose suite-hook should have test battery.

(The rose rug-brief-tour test battery already test the functionality of rose suite-log implicitly.)

Calls to cylc get-config can kill the server. Need to investigate, and possibly further reduce our reliance on it.

This problem is less urgent now that we have reduced the number of calls of cylc get-config to 1 per task event. If and when we have the database for Cylc task event or status, we should be able to make further improvement to this.

Currently, the main Rosie web page displays extra properties of a suite as a simple hover-over - this could be vastly improved by presenting them in a more sophisticated form, including translating the date property to a human-readable year-month-day-hour-minute-second form.

We can consider adding some auto completion in the address bar. Information for auto completion can come from 2 sources:

• The user's query / search history.
• Query / search history of the server. E.g. we can add a table to the database to store the last 1000? queries / searches.

Potentially, one could also offer autocomplete options based on a mask for query strings e.g. for commonly used query terms such as "and" or "contains"

We should change the tree panel error icon to be something more generic that can also indicate warnings.

We may want to introduce titles for individual value choices (e.g. radiobuttons for '1', '2' and '3') so that we can display it within the config editor.

We should flag optionally overridden application configuration settings in the config editor, probably in the form of a warning.

Now that we can use PyGTK 2.12 and greater for the config editor, we can make use of built-in tab detaching instead of our own implementation. This will allow dragging and dropping, and re-attaching detached tabs.

We should give the option to include the option name together with the option title in the config editor and rearrange the option name in the description.

We need an advanced search dialog for the config editor that can drive searches by metadata and combinations of fields - e.g. find all integers with 'radiation' in their descriptions.

It would also be useful for large suites to have the option to only search a single configuration.

We should also consider whether to make the default search case sensitive or not.

We have introduced the ability to set thresholds via the command line. We need to also allow these thresholds to be configured in rose.conf.

We should prevent any hanging of the main rosie go process while results are being fetched or processed. This can easily be done by farming out the result requesting to a separate thread or process.

This means that the basic thread model is similar to the way cylc gui operates.

We should support the ability to run another suite using a modified version of the rose-suite.conf file. (One possible use is for running rose stem suites which are stored with the source code.)

The idea is that you would define a suite containing a rose-suite.conf file (+ maybe a rose-suite.info file) which would contain an entry to install another suite, e.g:

[file:.]
source=/my/path/to/rose-stem

This doesn't work at present (because the top level suite dir contains other directories?). Another problem is that the suite you want to install may contain rose-suite.conf & rose-suite.info files which clash with the local versions.

We need to agree a strategy for a common environment and utilities to:

1. 'Install' files retrieved from the archive, or elsewhere (ie. files not put in place by the suite install mechanism, such as those required on a cycle-by-cycle basis or for a cold-start).
2. 'Archive' and 'housekeep' items generated by suites. This should include:
   • distributing files elsewhere on the system, or to a remote file system.
   • housekeeping on a 'cycle directory' basis, or on a 'pattern match' basis, when files are no longer required.

rose mpi-launch should accept standard CLI options of most Rose utilities, e.g. --verbose, --quiet, --debug. It should also generate a log file with a verbosity level equivalent to the -v -v mode.

It would be relatively simple to implement a drag and drop of a tree panel node, as its configuration text, into an outside programs such as text editor or terminal. This would increase the transparency of information within the GUI.

It would be more useful to drag and drop configurations between 2 suites.

We need to provide tools to identify changes to files in parent suites and allow these changes to be merged.

We need to improve rose suite-run to handle quick restart, etc.

It would be useful to have a saved searches or bookmarks toolbar within rosie go to allow users to quickly run searches they regularly use.

It would be desirable for rose suite-run to create an automatic jinja2 variable for Cylc's suite.rc to contain the value of the host name of the originating host (normally the user's desktop).

It would be very useful to have saved sessions for rose config-edit, along with any other Rose GUIs we may develop.

We should give people a better idea of what the full id of their suite is - definitely in the idx column.

We have also agreed that the database entry will have to store the prefix.

We need to make sure our fixed strings (e.g. the menu title 'View' in config-edit) are all easily configurable. We should look into support for Unicode.

In the config editor, if a new variable is added, not given a name, and then the application is saved, the config editor will crash and the application will contain a line that looks like "null1348096126_56=". We should warn people that they should either delete the variable or give it a name before they can save.

We should make the icons in the rose config edit tree panel clickable so that a click on an error icon takes the user to the first variable with an error.

We should decrease the overloading of the 'gear' icon in the config editor by using flags for indicators like fixed and ignored.

We need to sit back and write down a detailed specification of Rose and Rosie functionalities.

rose suite-run should have test battery.

(The rose rug-brief-tour test battery already test the functionality of rose suite-run implicitly.)

rose mpi-launch needs to be enhanced to handle coupled models with multiple MPI executables.

An application configuration metadata will normally live with the repository of the individual system who owns the application.

How does Rose search for them?

We'll introduce a Rose site configuration:

• etc/rose-meta-search.conf?

It can do one of the following:

1. Point to a set of paths in the file system.
2. Point to a set of repository locations.
   Rose post-commit hook to install them to live with
   our installation of Rose.

Who should edit the file?

• Rose team only (like FCM site location keywords)?
• System managers to do it themselves?
  (A bit like GHUI, but version controlled!)

Upgrade macros will be discussed in a separate ticket.

It would be useful for introducing users to the concept of cycling suites.

We should have better integration of event handling in Rose/Rosie utilities - for example the config editor uses different code to rosie.vc.

We should remember to use reporter for the rose macro output as well.

It may be useful to have an optional status panel at the bottom of the config editor window to display macro output, actions undertaken by the config editor, and any interface with external programs. It could also be configured to automatically display help information for pages or variables (as in gconf-editor), and so on.

We should allow users to pass arguments to transformation macros.

Very long variable values produce unusably-wide info dialogs - this should be changed.

At present, when a filter is deleted/removed from the GUI an entry remains in a master list. As a result of the history browser a lot of filter adding and deleting will occur. This will result in unnecessary (and possibly problematic?) memory overheads when using rosie go.

rose.config_processors.file supports installing files from file system locations and Subversion (FCM) locations.
It may need to support other location types,
e.g. git, moose, rsync, www, etc.

rose suite-run should support alternate Cylc installations.
To do:

1. Introduce an option or configuration to specify the
   location of an alternate installation.
2. Ensure that the correct Cylc installation is used to launch
   cylc run, especially for a remote cylc run.
3. Pass a Rose jinja2 constant to suite.rc
   to allow users to design their suite for tasks
   to use the correct Cylc installation.
4. Write the Cylc installation location in a file that
   can later be used by rose suite-gcontrol.

We may want a check configurations then save button and menuitem. This would invoke fail-if, warn-if, and any custom validator macros. This might need an advanced mode to choose which checkers to use.

We need some checking functionality for the syntaxes of the metadata properties.

We need to demonstrate a prototype STASH interface as a custom widget within the config editor.

The config editor code has been developed relatively rapidly and in parallel with evolving specifications and user requirements.

When time becomes available, the code needs to be rationalised, restructured, and improved in style and documentation.