Hi Jeremy This would be trivial if the request for installation can be executed on the node itself. E.g. have the farm scheduler execute a "pre-job" to make sure all dependencies are met.
This "pre-job" would simply consist of clump install package1-x.y pacage2-a.b ... Cheers Conrad On Wed, 2004-02-18 at 12:33, Jeremy Redburn wrote: > Conrad, > > Thanks for the pointer. Basically, my current system consists of a > number of nodes managed by Condor or PBS that have all the various > programs I'm interested in running installed on them. Going forward, I'd > like to be able to install when needed -- ie. I have 10 nodes or so, and > when a job of type X comes in, we check to see if X is installed on a > free node and if not we install it. There's a lot more to it, but I'm > mostly interested in a system that allows me to create packages for this > "grid" and say something like "install X.rpm on node 4" and have it > handle the various dependencies. > > Jeremy > > Conrad Steenberg wrote: > > > Hi Jeremy > > > > It's not entirely clear what you mean by a grid, but in the academic > > sense of the word we have been using OpenPKG for a while to do manage > > software installation in a Grid-related project. See > > http://clarens.sourceforge.net/index.php?intro+cvs > > > > Basically we use an 'instantiation' of OpenPKG (which is only provided > > in source form) combined with a package installer based on YUM > > (http://www.linux.duke.edu/projects/yum/) called 'clump'. > > > > We make some changes to OpenPKG-provided sources, including enabling > > shared libraries because we don't need to support any brain-dead OSes. > > I don't know what the state of AIX is in that respect. Also, all our > > packages are built to be relocatable, so that they are installable > > independent of what the root of the OpenPKG installation was. > > > > Cheers > > > > Conrad > > > > On Wed, 2004-02-18 at 10:59, Ralf S. Engelschall wrote: > > > >>On Wed, Feb 18, 2004, Jeremy Redburn wrote: > >> > >> > >>>I am exploring possibilities for managed installation and removal of > >>>software on a heterogeneous grid, mostly consisting of Linux and AIX > >>>machines. > >> > >>Just already in advance: because we still do not have any access to any > >>AIX box, the status of OpenPKG on AIX is unknown. Although OpenPKG 2.0 > >>CORE packages could work on it to some extend without having to patch > >>things. If you have a recent AIX version and can afford giving us access > >>(non-privileged access is fine for the major CORE package porting) we > >>are happy to port OpenPKG to AIX. > >> > >> > >>>While I am somewhat interested in what apps are currently > >>>packaged, > >> > >>For this see ftp://ftp.openpkg.org/current/SRC/. We have currently 698 > >>applications in OpenPKG CURRENT packaged from which 473 are released > >>these days in OpenPKG 2.0. > >> > >> > >>>I am more interested in learning about the capabilities of > >>>OpenPKG in general. > >> > >>Well, OpenPKG as of today is mainly about _packaging_ software, not > >>_managing_ it, i.e., although we are very proud of the quality of > >>our packages, the management layer currently mainly conists of RPM > >>itself. And RPM is limited to dealing with single packages, it does no > >>high-level tasks... > >> > >> > >>>For example, is it possible to store all packages on > >>>a central server that manages the packages installed on all the various > >>>nodes? > >> > >>It is possible, but not out-of-the-box with the RPM based functionality > >>we have. There are APT and Synaptic, openpkg-tool and other addons which > >>already provide higher level features. But I think starting with the > >>forthcoming OpenPKG Tool Chain ("openpkg-tools") we the first time will > >>be able to really provide higher level management features. But > >>this requires some more months of development. > >> > >> > >>>How does the dependency resolver work? > >> > >>RPM itself does not dependency resolving, it only knows the directly > >>dependent packages of a package, not the transitive ones. "openpkg-tool" > >>already can calculate the transitive dependencies, including building > >>from source. APT also can calculate the transitive deps, but mainly > >>support binary packages only. > >> > >> > >>>If I uninstall a package, > >>>will OpenPKG notify me of any remaining packages that relied on that > >>>package? > >> > >>Yes, this is already covered by RPM itself. It complains > >>if you want to remove a package on which others depend. > >> > >> > >>>What facilities, if any, are there to package closed-source > >>>software (Oracle, DB2, WebSphere, etc.)? > >> > >>Well, the same as for packaging open-source software. We just treat the > >>vendor binaries of the closed-source software as "sources" and place > >>them into our source RPMs, although during the "build" step there is > >>obviously nothing really to build ;-) But keep in mind that such large > >>applications like Oracle and DB2 are usually not reasonable to package, > >>except for perhaps their client part (see our "oracle-barebone" package > >>for such an example). > >> > >> Ralf S. Engelschall > >> [EMAIL PROTECTED] > >> www.engelschall.com > >> > >>______________________________________________________________________ > >>The OpenPKG Project www.openpkg.org > >>Developer Communication List [EMAIL PROTECTED] > ______________________________________________________________________ > The OpenPKG Project www.openpkg.org > Developer Communication List [EMAIL PROTECTED] -- Conrad Steenberg <[EMAIL PROTECTED]> ______________________________________________________________________ The OpenPKG Project www.openpkg.org Developer Communication List [EMAIL PROTECTED]
