Re: [ptp-dev] Updated Resource Manager Schema

["Albert L. Rossi" <arossi@xxxxxxxxxxxxx>]

Dave

> On second thought, separate files are probably the only reasonable way to 
> deal with this. With what I was thinking, the job-attribute element would 
> itself contain an element that was some sort of tag identifying the 
> configuration that it was applied to, and then there probably needed to be 
> an element specified previously in the file that specified what the 
> configuration defined in the file was. So you still have a separate file 
> for each permutation of for instance OS, but now with the clutter of 
> job-attribute elements that don't apply to that OS and an additional 
> element keyword used to filter them. 
> 
> Doing this I think also means being able to generically specify in some 
> way system attributes to filter against. I'm not sure how to do that in a 
> generic open-ended way.
> 
> Maybe the filename of the file should be intended to be descriptive, 
> although there is no requirement that the user preserve the name, and 
> comments in the top of the file specifying the configuration it applies 
> to.
> 

This was my orginal thought as well (see the first annotation).  I will go ahead then and remove those added attributes for job-attribute.


> >We can add a "validate" element.  How would you specify it?  Would these 
> two uses 
> ><validate>
> >   <regex>...</regex>
> ></validate>
> 
> ><validate>
> >   <acl>-rwxr-xr-x</acl>
> ></validate>
> 
> I think these forms in addition to what you have work for me.
> 
> Another question here is what sort of error message gets generated when 
> validation fails? Will this generate error messages that name the field 
> and explain what's wrong? Do we need a way to specify an error message 
> text for when a job attribute fails validation? Maybe <message> needs to 
> be an element of a <validate> element.

I'll add an optional <error-message> element, but it would be simple to report field name; I would assume we would want to include the stack trace optionally as well; so maybe <error-message includeTrace="false">...

> 
> I'm concerned about the volume of data that gets sent back to the client 
> for stdout/stderr by a real application. I'm not sure how much data real 
> applications write to either. If an application is writing megabytes of 
> data to stdout, then I'm afraid of saturating the network connection. My 
> view has been that PTP should work well even wih a cable modem/DSL 
> connection of reasonable speed.
> 
> If there's huge amounts of data sent to stdout, then I think the user 
> needs the option to keep the data on the machine where the app is running, 
> by specifying redirection. If I do something like 'ssh remote_node my_app 
> > stdio_file 2>&1' doesn't the data stay on the remote node? Note this 
> breaks the job id notifiacation Greg mentioned.

I agree that the user should be able to turn off the streaming of the stdout if it is voluminous.  Something like tail -f on stdout would be useful, too.  We not only have a scalability issue with network, but if all of stdout is saved in Eclipse we could easily provoke an OutOfMemoryError.

Al