On Jul 1, 2005, at 8:14 AM, Erich Focht wrote:
Troll through the mail archives to find that prior mail from me.
Found it, was an email from Mai 18. Thanks.
Great -- let me know if there's any additional information that you
need that is not in there.
I saw that the framework is tied to the master. Well, hmmm, it would
me VERY
usefull if one could apply this to an image and find out what distro
it
contains. In the long term I'd expect images to have different
distros
than
the master. Would be nice to have OS_Detect prepared for that.
Sure, that would be a useful extension. Suggestions?
OSCAR::OCA::OS_Detect::open(image => $imagename);
should grab the corresponding path from the image database in ODA,
check the
release files inside. Architecture should come either from the
database or
from a query to some kernel RPM installed in the image. For RPM based
distros. I prefer the database query. If the "image" argument isn't
set, fall
back to querying the machine we run on and use uname.
Thinking about this a little more, it may not be possible to query an
image via the current set of OS_Detect components -- an underlying
assumption to all of them is that they can run an executable to
discover some information (e.g., the underlying architecture). In a
heterogeneous situation, one can easily imagine executables in an image
that are not runnable on the host where the image resides.
So it seems like caching the information is the Right way to go (in a
database, in a file, whatever -- I don't think that I have strong
preferences here, as long as reasonable guarantees can be made about
the accuracy of this file, especially in light of OS updates, etc.).
That was a long way of saying that I agree with Erich. :-)
However, the OS_Detect components were meant to be a small, simple
thing that allowed upper-level layering for other functionality (e.g.,
caching the OS/arch data). So I think that the current OS_Detect
components (and possibly the framework?) should not be involved in
caching of the information. Indeed, detecting and caching the results
are two orthogonal actions (and can even be arbitrarily combined
between different implementations of the two).
So I do agree that this is good functionality to have. I just think
that the implementation of caching of output information from OS_Detect
should be different from the implementation of "detect what the current
node is." There can be a single, top-level interface (which I think,
is the essence of what Erich is proposing) that ties these two
together, but the underlying OS_Detect components should have no
knowledge of this caching behavior. Keep them small and simple.
Likewise, the caching functionality should be small and simple (and
orthogonal), too.
So instead of the OSCAR code base calling OSCAR::OS_Detect::open(),
they'd call some other top-level interface, such as (off the top of my
head):
OSCAR::ZZZ(image => $imagename);
where, if $imagename is empty, it means to return the information about
the current node. This ZZZ function would first check whatever cache
it has to see if the answer has already been determined (e.g., for an
image). For images, the cache should always be able to satisfy the
request (because we ensured to create a cache for every image that is
created). If the cache can't satisfy the request, then this is not an
image, and we can invoke the underlying OS_Detect components to figure
out the answer (and potentially cache that as well).
The OS_Detect framework could be the single, unified interface to both
(i.e., OS_Detect is part of the ZZZ from the above example, probably by
expanding the base of OS_Detect.pm), or another top-level interface
could be provided that does both (thereby a) allowing OS_Detect, in its
entirety, to remain absurdly simple, and b) allowing the
framework/componentization of the caching behavior). I don't have
strong opinions here, but I think that since performance is not an
issue, keeping the different functionalities in completely separate,
layered, tiny little black-box implementations is a Very Good Thing
(i.e., I lean towards a separate framework for the caching, and having
an upper layer interface that unifies the two).
Make sense?
--
{+} Jeff Squyres
{+} [EMAIL PROTECTED]
{+} http://www.lam-mpi.org/
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Oscar-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
