Application Templates
At the last call I mentioned the notion of an Application Template. A first draft is now on Gridforge - https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.ogsa-hpcp... Chris and Bill have provided some comments (in the document) which we can discuss on the list or on Thursday's call. Steven
Steven Newhouse wrote:
At the last call I mentioned the notion of an Application Template. A first draft is now on Gridforge - https://forge.gridforum.org/sf/docman/do/downloadDocument/projects.ogsa-hpcp...
Thanks for doing this. Some comments since I can't make the call: Re the Application URI: What are the correspondences between the APPLICATION and VERSION parts and the general JSDL document? And Glue's ApplicationEnvironment? And the relevant bits of CIM? (OK, I can't be bothered to look up the name of the last part, but I think that corresponding to JSDL and Glue lets you pick up on this stuff for free.) The ORGANIZATION part seems odd; is it the service provider or the software provider that it corresponds to? If the former, does that mean we cannot compare application URIs from different providers? Re Discovery: Should there be a way for users to look up the templates as opposed to just their names? Re Invocation: I can't see how you can match/override arguments in general; there's no mechanism for determining if they "mean overlapping things" and I've seen some deeply odd argument syntaxes. Instead, I think the only thing you can do in the simple case is to append the user-supplied arguments to the template-supplied ones. Quick and dirty, yes, but will do 99% of the trick for 1% of the effort. :-) I'm tempted to say that templates should not specify the Username at all. Rationale: the template author probably won't know which user is using the application when writing it, and specifying a wrong value is likely to lead to much more grief than utility. General comments. It would be nice if templates could support named replacement parts. I've seen this hacked together with environment variables (with the emphasis on "hacked") but it would be nice if something like this could be supported more directly. But maybe not in this profile, since it *requires* a more complex discovery process. If we're publishing the actual templates (as opposed to their URIs), it would also be nice if we could attach extra metadata to the templates which would be for consumption by processing entities other than the BES container. (For example: provenance of the template, usage advice, even an XForms GUI for filling out JSDL to use the template...) Donal.
Re the Application URI: What are the correspondences between the APPLICATION and VERSION parts and the general JSDL document?
Good point. I think we need something more defined than just an application name... hence going down the URI route. The Application name would be one place to the defined URI. The version component of the URI could then be placed in the JSDL version element. Or an ApplicationURI element placed at this level and just the Version element used.
The ORGANIZATION part seems odd; is it the service provider or the software provider that it corresponds to? If the former, does that mean we cannot compare application URIs from different providers?
This is one of the discussion points - is an application template tied to the application in general, or the system that it is deployed on. I feel it's the latter... but then you cannot 'compare' URIs on different systems without analyzing the structure..
Re Discovery: Should there be a way for users to look up the templates as opposed to just their names?
I feel not. Templates are a property of the system. The whole point of going down this route is for users to just say run my Matlab job, or my big CFD simulation. Any user specific details (input files) should be provided by the user - other details filled in by the system.
Re Invocation: I can't see how you can match/override arguments in general; there's no mechanism for determining if they "mean overlapping things" and I've seen some deeply odd argument syntaxes. Instead, I think the only thing you can do in the simple case is to append the user-supplied arguments to the template-supplied ones. Quick and dirty, yes, but will do 99% of the trick for 1% of the effort. :-)
Yeah. I'm probably tempted by 'append' and let the application deal with conflicts - probably badly!
I'm tempted to say that templates should not specify the Username at all. Rationale: the template author probably won't know which user is using the application when writing it, and specifying a wrong value is likely to lead to much more grief than utility.
Disagree - the system manager might want all users to run as a particular user but to keep the record as to who submitted the job.
It would be nice if templates could support named replacement parts.
Not sure what you mean by this?
If we're publishing the actual templates (as opposed to their URIs), it would also be nice if we could attach extra metadata to the templates which would be for consumption by processing entities other than the BES container. (For example: provenance of the template, usage advice, even an XForms GUI for filling out JSDL to use the template...)
I don't see a driving scenario for this at the moment... but if they were published yes. Steven
Steven Newhouse wrote:
Good point. I think we need something more defined than just an application name... hence going down the URI route. The Application name would be one place to the defined URI. The version component of the URI could then be placed in the JSDL version element. Or an ApplicationURI element placed at this level and just the Version element used.
I'd like to see application name and version be things that can be tied through the whole info model. It brings it all together.
This is one of the discussion points - is an application template tied to the application in general, or the system that it is deployed on. I feel it's the latter... but then you cannot 'compare' URIs on different systems without analyzing the structure..
Exactly. I don't have the answer BTW.
I feel not. Templates are a property of the system. The whole point of going down this route is for users to just say run my Matlab job, or my big CFD simulation. Any user specific details (input files) should be provided by the user - other details filled in by the system.
OK, fair enough. So long as we're clear, we're good.
Yeah. I'm probably tempted by 'append' and let the application deal with conflicts - probably badly!
Dealing with bad input is "Not our problem". :-) [re Username]
Disagree - the system manager might want all users to run as a particular user but to keep the record as to who submitted the job.
Default or override? Tricky. Might need to allow for both. (Might also need to extend this idea in other places that have default/override behaviour. Maybe a new attribute in the template specification?)
It would be nice if templates could support named replacement parts.
Not sure what you mean by this?
I used to work on a project which (ab)used JSDL. What they wanted to do was to specify some attributes of an execution by name and not by position (e.g. for a "compress file" application they might have the name of the file and the compression level as named attributes). They did this (much to the surprise of the developers of the BES-analog) by using particular environment variable names and then assuming that the JSDL consumer (which had its own templating mechanism) would substitute the environment variables in the right place. Hopefully I've explained right the scenario.
I don't see a driving scenario for this at the moment... but if they were published yes.
Agreed. If they're not published, there's no need. View it as a conditional comment. :-) Donal.
participants (2)
-
Donal K. Fellows -
Steven Newhouse