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!
From:
owner-ogsa-wg@ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf Of Christopher Smith
Sent: Wednesday, November 09, 2005
5:38 PM
To: Ian Foster; ogsa-wg@ggf.org;
ogsa-naming-wg@ggf.org; OGSA-BES-wg@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@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.