From: Jeff Squyres on Friday, July 01, 2005 7:13 AM > On Jul 1, 2005, at 8:14 AM, Erich Focht wrote: > > > > 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.
Correct. BTW, this is a problem with the current SI process of building the image on the host--it can only be done for compatible host and client image. > 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. :-) Yes it was :-P > 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). Good. > 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. Good. > 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). Hmmm. Presence in cache does not imply the request was for an image; existence of the image key indicates request was for an image. Failure to have info in cache *may* be solvable by immediate query if the image is the same architecture. Image architecture is easily queried by a file(1) on the image kernel or other well-known binary or perhaps more simply by attempting to chroot the image, which will fail on exec of /bin/bash unless the architecture is the same. Having said all that, I do agree that the cache should not contain the OS of the current platform. > 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). I like a generic cache layer, especially as we get more involved with variability of the clients and images. -- dnl My comments represent my opinions, not those of Intel Corporation. ------------------------------------------------------- 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_idt77&alloc_id492&op=click _______________________________________________ Oscar-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oscar-devel
