Page History

...

This view shows all of the machines defined as available to the user for installing the RMI service and PTPFlow plugins required to run HPC jobs and return status information to the client. Below you will see a partial specification for what an RMI Service stored as a tupelo bean might look like. This is not a requirement for version 2.0.

RMIService Info Bean (optional)

The information about each service installation will be stored in an RMIServiceBean and will be used to launch and start the service. All of this information is currently used in PTPFlow and is stored in xml files. Bringing in tupelo to the service stack will allow us to store this information in tupelo.

// Service Info
private String name;
private String platform;
private String deployUsingURI;  // e.g. file:/
private String launchUsingURI;
private String installLocation;  // e.g. /home/user_home/ptpflow
private String rmiContactURI;
private int rmiPortLowerBound;
private int rmiPortUpperBound;
private int gridftpPortLowerBound;
private int gridftpPortUpperBound;
private Date installedDate;
private boolean running;
private Set<HostResourceBean> knownHosts;  // all of the known hosts associated with this service

Repository Manager

Repository View

This will be handled by the BardFrame since it will manage which context the user is connected to. Below are some of the views that are anticipated to display some of the information stored by the context.

...

Datasets View

This view will display the datasets that are stored in the tupelo context that the system is connected to. Users should be able to import/export datasets from this view, tag datasets, etc.
Rather than a single repository view, this will be multiple views that are configured to show a particular type of bean(s) coming from a content provider. The content provider would get the data required from the configured tupelo context(s). For example, we will need a "Dataset Repository View" that shows all datasets (e.g. input/output datasets) and a way to manipulate them (e.g. add tags, annotations, etc), "Workflow Repository View" that shows all imported workflows, "Scenario Repository View" that shows all saved scenarios, "Service Repository View" that shows defined RMI service endpoints for launching jobs, and a "Known Rather than a single repository view, this will be multiple views that are configured to show a particular type of bean(s) coming from a content provider. The content provider would get the data required from the configured tupelo context(s). For example, we will need a "Dataset Repository View" that shows all datasets (e.g. input/output datasets) and a way to manipulate them (e.g. add tags, annotations, etc), "Workflow Repository View" that shows all imported workflows, "Scenario Repository View" that shows all saved scenarios, "Service Repository View" that shows defined RMI service endpoints for launching jobs, and a "Known Hosts View" for showing known hosts that can accept jobs. This seems like too much disparate information to display in a single view. All Repository views will descend from BardFrameView since the BardFrame will be required to get the data required for each view.

...

1. Import datasets that will be used as input to HPC workflows such as Mesh files, input files (e.g. mach number, poisson ratio, etc)
2. Store output datasets from workflow runs, some workflows will be parameterized and have multiple outputs
3. Store scenarios
4. Store defined RMI services
Store known-hosts
5. Export datasets
6. Dataset tagging, Annotation, etc
7. Other functionality?

Workflow view

This view will display the workflows that have been run and the parameters they were ran with (possibly for re-running a workflow).

Functional Requirements

1. Store workflow xml files (Ogrescript) with the parameters used
2. Provide delete, tag, annotate, etc
3. Other functionality?

Overview view

This view will provide general information about what is selected (e.g. a scenario, a dataset, etc). It will display things like who the creator was, date created, etc. If possible, it will provide a preview of what is selected (e.g. a dataset).

Tag view

View for working with tags. It will display all tags associated with the current selection and allow users to manage the tagsA critical requirement is that repositories can be both remote and local and users might use more than one simultaneously. Input data for workflows that is managed by Tupelo will need to move from the users machine to a location that the HPC machine can access. Datasets should also be returned to the users scenario or made available to it.

Host Manager

...

Known Host View

This view contains a list of defined HPC hosts that the user can launch jobs on. This view will provide the user with the ability to change/view/add properties such as environment settings, user information for the host (username, user home, etc), host operating system, node properties, new hosts, etc. These changes should be propogated to the defined RMI services so they can be used immediately.

Known Host Bean (optional)

Below is the bean structure that is anticipated:

...