On Friday 01 July 2005 18:27, Lombard, David N wrote:
> 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.
This is exactly the case I have in mind. Actually I wanted to say: how about
avoiding the "uname" call completely? It can be replaced by something else,
even when querying the local host.
I like the idea of David to run file(1) on some wellknown binary. Then the
image comes in only as additional path. All the rest of uname isn't really
needed, if you detect a Fedora image, you'll know that "os" is "linux".
> > 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.
chroot might work from an x86_64 master into an i386 image, the result would
be wrong.
> Having said all that, I do agree that the cache should not contain the
> OS of the current platform.
Well, you can add a caching layer, but this is not necessary for this
case. I can think of three targets on which I would like to apply OS_Detect:
- local host
- an image (use imagepath for detection)
- an installed node (this is not really needed, a node has an existing
image assigned, therefore same architecture as the
image)
Each time I call the open() method I want to really detect
($distro,$version,$arch,...) and not use cached values. I could use the
database entry in the SIS/ODA image table, if arch is undefined there, it will
be undefined for the image as well. That IS the place where the arch should
be declared for the image. But a file call is good enough for directly
detecting.
Actually OCA is the caching infrastructure, that is what I read in Jeff's
explanation email. It caches the result of the query for the calling program
as a hash.
If you want an additional caching layer for first checking the database, no
problem. But I think that it is additional and independent of having the two
basic targets of OS_Detect (image and self). And, BTW, the self-detection is
not cached in the image table in the database. There is no master-image.
Regards,
Erich
-------------------------------------------------------
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
