>
How will the new resource register or how will the site level information
provider discover this new
>
resource. Meaning, is the onus on the resource level provider to advertise or
the site level provider to discover.
I think this is rather a
implementation/deplyoment issue than a standartization one. The paragraph
("Recommendations for Standards", 2) wants to express the need for a common
way of exchanging the registry of endpoints information between infrastructures.
It is not intented to standartize a way of how the enpoints are registered
within the infrastructure. However, I'm sure there is a way of best
practice.
> I like the idea of caching. If this is the
route we are taking it needs to be put in the document.
> Then the questions is how frequently the cache
is/should be updated? Where will the cache
> reside? At the host or where the provider is?
This needs to go in too.
I'm not sure what you mean by 'host'
- the resource or the host which requests the information?
In both cases I think the site-level
info-system (provider) should cache the information.
The resource should not cache at
all.
If we rely on the fact that the user
host caches the info, we run against the problem that they will then switch off
the chaching to try to get always the latest information. ( at least this is
what I'll do :-) )
Then, we have the request bombing
scanario again.
But
again, this and the frequency of updating the information should be a
implementation/deployment issue and is therefore not defined in this
document.
>
Finally, how will all this be propagated to Grid level.
The way site
information is made available to the grid is suggested by the common query
interface ("Recommendations for Standards", 1)
.
Felix
---
Felix
Ehm Tel: +41
22 76
74580
CERN
Fax: +41 22 76
68783
IT-GD-ITR
CH 1211, Geneve
------------------------------------------
Felix, Donal, Guru,
> Agreed, that paragraph is confusing. (I
suspect, but do not know, that
> the information you highlighted was the
information produced by the
> "resource-level provider" but that's just my
reading...)
Yes, this
paragraph is intended to explain the purpose of a resource
level
information provider (for performance reasons it may also have a
build-in
caching). I've changed this part in version 3. Please have a look
there.
> Comment #2:
> > Does
this mean even the resource level information provider is not
> >
required??? Or are we saying the service that provides the capability
> > to query
is not required????
> >
> > If the
answer to the first question is yes then, I would say it may
> > still be
required. Instead of site level information registry getting
> >
overloaded with queries about the resources it has, if one has a
> >
visibility of a particular resource he could just query that resource.
>
> I'd say that
while the resource-level provider is not a priori required,
> it has to be
there conceptually. Sites are free to use other mechanisms
> to actually
do the information provision though.
>
> On the other hand, I really disagree with your
second paragraph there.
> One key gain from having a site-level
information system is that this is
> a prime location for carrying out queries for
resource discovery and
> scheduling. If you require everything to ask
the end resources directly,
> then anything that actually needs to look at
many resources will end up
> being dog slow because of the amount of network
traffic needed to take
> any kind of decision (trust me, I've tried
this!) A site-level info
> system is a major optimization, especially if
you do not require all
> information within it to be entirely
timely.
I figured you'd say this. But somehow I feel that this
point should be emphasized in the document. Besides we should also address the
case when a new resource is added to a site (where there is already a site level
information provider). How will the new resource register or how will the site
level information provider discover this new resource. Meaning, is the onus on
the resource level provider to advertise or the site level provider to discover.
Same thing when a resource drops off.
I like the idea of caching.
If this is the route we are taking it needs to be put in the document. Then the
questions is how frequently the cache is/should be updated? Where will the cache
reside? At the host or where the provider is? This needs to go in
too.
Finally, how will all this be propagated to Grid level.
Felix Nikolaus Ehm <felixehm@mail.cern.ch>
wrote:
Hi,
in
case you are referring to version 2 of the document:
> Agreed,
that paragraph is confusing. (I suspect, but do not know, that
> the
information you highlighted was the information produced by the
>
"resource-level provider" but that's just my reading...)
Yes, this
paragraph is intended to explain the purpose of a resource
level
information provider (for performance reasons it may also have a
build-in
caching). I've changed this part in version 3. Please have a look
there.
> > Does this mean even the resource level
information provider is not
> > required??? Or are we saying the
service that provides the capability
> > to query is not
required????
The passage wants to express that if a site information
system is
available and provides a common query interface, the resource
level
information components don't necessarily need to implement the
same
interface.
In my opinion their purpose should then be to populate
information
to the site level and not serving external
requests.
Concerning the question if the resource level info providers
are
essential INSTEAD of a site-level one I agree with Donal. In the past
it
turned out that caching represents latency, but also protects resources
from
being bombed by requests.
Felix
On Tue, 7
Aug 2007, Donal K. Fellows wrote:
> guru prasad wrote:
> >
I have some corrections and questions. I have highlighted those in the
> > attached document. Can someone please help me
understand.
>
> Going through your comments (extracted from the
document)...
>
> Comment #1:
> > What information.
Information about the resource or the fact that the
> > information
provider is on the same host. Too many "This"
>
> Agreed, that
paragraph is confusing. (I suspect, but do not know, that
> the
information you highlighted was the information produced by the
>
"resource-level provider" but that's just my reading...)
>
>
Comment #2:
> > Does this mean even the resource level information
provider is not
> > required??? Or are we saying the service that
provides the capability
> > to query is not required????
> >
> > If the answer to the first question is yes then, I would say it
may
> > still be required. Instead of site level information registry
getting
> > overloaded with queries about the resources it has, if
one has a
> > visibility of a particular resource he could just query
that resource.
>
> I'd say that while the resource-level provider
is not a priori required,
> it has to be there conceptually. Sites are
free to use other mechanisms
> to actually do the information provision
though.
>
> On the other hand, I really disagree with your second
paragraph there.
> One key gain from having a site-level information
system is that this is
> a prime location for carrying out queries for
resource discovery and
> scheduling. If you require everything to ask
the end resources directly,
> then anything that actually needs to look
at many resources will end up
> being dog slow because of the amount of
network traffic needed to take
> any kind of decision (trust me, I've
tried this!) A site-level info
> system is a major optimization,
especially if you do not require all
> information within it to be
entirely timely.
>
> Comment #3:
> > Should it say that
the developer of the resources could be the
> > information provider
???? This is not clear from the sentence.
>
> That sentence is
wildly unclear, but I suspect it's talking about some
> kind of API for
basic info providers to make it easier to write the
> actual information
sources. However, I wonder whether this falls more
> within the remit of
SAGA - do they do server-side APIs? - since OGSA
> (and related groups)
has tended to focus on the wire view of interop.
>
>
Donal.
> --
> ogsa-wg mailing list
> ogsa-wg@ogf.org
>
http://www.ogf.org/mailman/listinfo/ogsa-wg
>
Park yourself in front of a world of choices in alternative vehicles.
Visit
the Yahoo! Auto Green Center.