[ogsa-wg] OGSA Information Services - Version 3
Felix Ehm
felix.ehm at cern.ch
Mon Sep 24 04:46:17 CDT 2007
Hi Guru,
>Hello Fleix and Donal,
>
>I see we have totally stopped discussions on this thread. I have sent a
reply to this and even a reminder after
>that (which apparently I can't locate in my inbox) but neither do I see any
comments nor do I see an update version.
>My comments were more on the lines of mentioning all the things we have
said here more clearly in the document.
>
>Can you guys please look for that email from me and send it to me. Perhaps,
we could start and end this thread.
>
>
>Others,
>
>If anyone of you can find that email from that will be great too.
>
>Thank you.
>Guru
(please find your mail below)
To conclude the agreement :
We agree on a site level information system which caches data from its
recources.
The resources are not queried directly by any other instances, but its
information is available in the site level information system.
> 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
------------------------------------------
_____
From: guru prasad [mailto:guru_bn at yahoo.com]
Sent: Dienstag, 7. August 2007 19:12
To: Felix Nikolaus Ehm; Donal K. Fellows
Cc: guru prasad; glue-wg at ogf.org; ogsa-wg
Subject: Re: [ogsa-wg] OGSA Information Services - Version 3
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 at 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 at ogf.org
> http://www.ogf.org/mailman/listinfo/ogsa-wg
>
_____
Park yourself in front of a world of choices in alternative vehicles.
Visit
<http://us.rd.yahoo.com/evt=48246/*http://autos.yahoo.com/green_center/;_ylc
=X3oDMTE5cDF2bXZzBF9TAzk3MTA3MDc2BHNlYwNtYWlsdGFncwRzbGsDZ3JlZW4tY2VudGVy>
the Yahoo! Auto Green Center.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20070924/001a3673/attachment-0001.html
More information about the ogsa-wg
mailing list