Kepler

Making a little progress on this bug. As a test I've added a temporary jbutton to the WRM that connects to provenance store running on a different machine. Clicking the button redraws the WRM, and shows the runs on the remote store. There's a lot to be done here though. Remote reports don't appear when you click on runs, deleting or tagging remote runs doesn't work. We'll likely want a Refresh button in the WRM so that a user can see remote changes, and there's new error handling to be done for when a user attempt to operate on an old or nonexistent version of a remote run. And of course eventually connecting to a particular remote stores will need to be driven off the user clicking on remote workflows as shown in figure 6.

I've got report layouts and instances displaying now when a workflow run manager is connected to a remote provenance store. Exporting a run kar seems to work as well.

Part of connecting a remote provenance store should be prompting the user for credentials (bug#5049).

An additional task to be done is to automatically filter remote runs show in the WRM gui based on what workflow is selected (bug#5050).

Some of comment#2 is no longer relevant:
-1) automatically filtering runs based on a workflow selection no longer relevant with our new gui designs.
0) we've decided that for the engineering view usecase, the WRM should not connect to a remote server's provenance sql store, but instead to remote kar stores, via ecogrid. I've implemented a drop down to select between sqlV8 and "ecogridV8" stores, and the runs from the kars via ecogrid can be shown.

However most of the important actions on these ecogrid runs need to be made to work:
1) clicking on a run -- to show the ROML and RIO the run-kar must be downloaded, and these items extracted and opened into the GUIs. A local cache area that maintains downloaded run-kars (and possibly their extracted contents) will probably be implemented.
1b) there's at least one queryable interface method that must be changed: getAssociatedDataForExecution works off of execIds, and since ecogrid stores may have run-kars from different systems, this is not unique and execLSIDs must instead be used.
1b1) code must be written to upgrade existing provenance stores to this new schema, updating relevant tables.
2) opening a run -- download and open the run-kar.
3) tagging a run -- download the run-kar, extract and modify the run, create a new kar (contains updated run and has new lsids), upload the new kar, remove the old kar, remove the old local copy of the kar, and refresh the local guis.
4) deletion -- delete the remote and local copy of the run-kar, refresh the local gui

Some additional tasks:
5) decide how to deal with duplicate remote runs -- the same run (execLSID) may reside in multiple remote run-kars. Currently I just don't show duplicates in WRM. Attempting to handle duplicates, likely by adding a karLSID to the run object, seems difficult and prone to cause new bugs. This likely also starts us down the path of storing (and modifying for changes) run-kars in sql provenance stores.
6) there's currently no authentication step when connecting to the remote ecogrid store, so presumably only public run-kars are shown and operated on (bug#5049)
7) a refresh button needs to be implemented (probably disabled when connected to the local store)

Closing, this is basically all done now. Any issues for the WRM wrt remote stores can be opened as new bugs.

changing bugs from REAP to Kepler product

Original Bugzilla ID was 5032