Re: [ptp-dev] Possible addition to PTP 2.0 todo list

[Dave Wootton <dwootton@xxxxxxxxxx>]

Greg
This is ok. In addition, we think a 'delete everything' event would be 
useful, to delete the entire machine, queue, jobs and processes. This 
would be useful in the case where event notifications are suspended then 
resumed, since once resumed, we woiuld need to refresh the complete state 
rather than trying to update the front end with changed state.
Dave



Greg Watson <g.watson@xxxxxxxxxxxx> 
Sent by: ptp-dev-bounces@xxxxxxxxxxx
05/29/2007 01:25 PM
Please respond to
Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>


To
Parallel Tools Platform general developers <ptp-dev@xxxxxxxxxxx>
cc

Subject
Re: [ptp-dev] Possible addition to PTP 2.0 todo list






Dave,

I don't see a problem with what you're asking. The client (Java) side 
already supports remove events for every type of model element. I 
think I had intended to provide a proxy remove event, but just never 
needed it with the ORTE proxy.

As far as the node numbering is concerned, it is totally up to the 
server side to determine the numbering using the nodeNumber 
attribute. This attribute has no intrinsic meaning in the model. The 
only places the node number is used is for the tooltip popup when you 
hover over a node, and the node attributes panel. Both of these will 
display anything you supply. The node number is also used for the 
ruler on the left side of the nodes view, but I think it can deal 
with gaps in the numbering.

While we're on the topic of events, I'd like to propose the following 
changes to the proxy events. Currently, when an error occurs (e.g. 
job submission fails for some reason, or the proxy does not start 
properly), the proxy sends a MESSAGE event back to Eclipse. The event 
has a value that indicates the level of the error (FATAL, ERROR, etc.)

Instead of this general message event, I'd like to have a specific 
event types for errors. Currently they would be:

IProxyRuntimeInitErrorEvent
IProxyRuntimeModelDefErrorEvent
IProxyRuntimeStartEventsErrorEvent
IProxyRuntimeStopEventsErrorEvent
IProxyRuntimeSubmitJobErrorEvent
IProxyRuntimeTerminateJobErrorEvent

In other words, each command would have a corresponding error event. 
As we add more commands, there would need be a corresponding error 
event for the command.

The general message events would still remain, but would be used for 
message logging rather than error indication.

Let me know if anyone has objections to this. Otherwise I'll go ahead 
and add the code.

Greg

On May 29, 2007, at 7:01 AM, Dave Wootton wrote:

> I have a possible addition to the 2.0 todo list. I think that 
> events to
> signal the deletion of model objects are needed, at least for nodes 
> and
> jobs.
>
> With one of my resource managers, new nodes are added to a machine 
> as the
> host list file specifying those nodes is processed, since that is 
> the only
> place I have any information about which nodes exist within the 
> machine
> (cluster). When the job completes, I'd like to remove those nodes 
> from the
> machine view if I have no other jobs using those nodes. Note that this
> could result in gaps in node numbering, since I may have one job 
> running
> using nodes 0-7 and another job using nodes 0-3, and a third using 
> nodes
> 4-7. If the first two jobs complete before the third, then at the time
> just the third job is running, I would have deleted nodes 0-3. 
> Would that
> cause problems with node numbering in the front end? Would it be a 
> problem
> if these node numbers got reused, maybe for different nodes?
>
> With another resource manager, it's possible to either cancel a job 
> before
> it starts, or migrate it to a different machine (cluster) before it
> starts. In those cases, I'd like to delete the job out of the queue 
> for
> the machine the job was initially submitted to rather than laeving 
> it in
> the queue.
>
> The other alternative is to put the affected nodes or jobs into a 
> special
> state (unavailable for nodes, maybe canceled for jobs), but I think 
> that
> may leave the display cluttered.
>
> Dave
> _______________________________________________
> ptp-dev mailing list
> ptp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ptp-dev

_______________________________________________
ptp-dev mailing list
ptp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ptp-dev