[ogsa-wg] Re: [ogsa-bes-wg] Abstract names in BES

[Subramaniam, Ravi]

Hi,

 

I am sorry I missed today's call (combination of a partial conflict and
the old habit of expecting the call at 3:00-5:00 Pacific). I may be
missing something that has already been covered. Apologies for any
redundant discussion.

 

I thought that BES is a focus on the container and not the jobs. It is a
job execution environment but the abstract names (if any) should be
generated before the request reaches the BES container since the job
factory is in the job manager or some such entity. I am not seeing the
connection between abstract names for jobs and BES. An abstract name for
a container makes sense in this context. In this case, a job id may not
be appropriate.

 

I would expect that abstract names have a form that is independent of
the type of resource or entity that is referred to by this abstract
name. The specific aspects that are determined by type would have to be
in the payload. As I was typing this, I saw Mike's email. I would agree
that something like a GUID would be appropriate. Alternatively a URI
that is parameterized in a domain/application manner may also work (this
may accommodate the job id requirement that Chris mentions below while
having a similar form for other resources/entities too). Abstract names
would be unique (as we all know) but I would expect have a validity
lifecycle attached to them (could be as simple as at Time to Live
possibly embedded in the name). I would not expect that these are for
ever persistent and available but may be driven by policy. Expecting
otherwise may put a big burden on the implementation.

 

Is the abstract name an optional or required in all cases (whether
embedded in the EPR or not i.e. resolved)? I would vote for it to be
optional since in some instances generating the name may not be
necessary. An example is an ephemeral job (i.e. < 15 - 30 sec for the
lifetime). We have many of these jobs in our environment and these are
the ones that really stress our schedulers in many of our production
pools. The effort to generate and assign and manage abstract name may
not be worth the overhead here. An EPR is all that we may have
(hopefully the simplest and really necessary parts in the EPR).

 

Thanks!

 

Ravi

________________________________

From: owner-ogsa-wg at ggf.org [mailto:owner-ogsa-wg at ggf.org] On Behalf Of
Christopher Smith
Sent: Wednesday, November 09, 2005 5:38 PM
To: Ian Foster; ogsa-wg at ggf.org; ogsa-naming-wg at ggf.org;
OGSA-BES-wg at ggf.org
Subject: [ogsa-wg] Re: [ogsa-bes-wg] Abstract names in BES

 

For a mapping of BES to LSF, I would put something like a job id in the
abstract name, so that it could be used outside the web services world
(say with a CLI). Sure, it could be put in the payload of messages, or
retrieved via some explicit call, but it seems reasonable to use the
abstract name for this. 

-- Chris



On 9/11/05 17:28, "Ian Foster" <foster at mcs.anl.gov> wrote:

I found the call today very helpful.

One thing that I wanted to get clarification on is the requirement that
motivates a desire for "abstract names" in BES.

I've heard one, which is that some entity may be handed two or more
references (EPRs) to jobs, and want to know which of these are (not)
unique. 

Are there others?

Regards -- Ian.



 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20051109/9948c100/attachment.html