[Planetlab-devel] status on extensions management
Thierry Parmentelat
thierry.parmentelat at sophia.inria.fr
Thu Jan 17 09:37:10 EST 2008
As discussed last week, I've implemented in bootmanager the ability to
manage node 'extensions'
This is to summarize where I am now on this front
- when installing a node, the bootmanager still downloads the main
tarball
"PlanetLab-Bootstrap.tar.bz2"
- in addition to that, all nodegroups that the node is part of are
considered as potential extensions that need to be installed
- for each extension, the bootmanager first tries to download a file
named
"PlanetLab-Bootstrap-%s.tar.bz2"%extension
if this succeeds, then it is uncompressed/untared as for the main
tarball
- otherwise, the bootmanager attempts to issue the command that reads
"yum groupinstall extension%s"%extension
the return code of this command is simply ignored, as (1) yum's return
code is not well specified (at least it was not last time I checked,
but that's a while back), and (2) in any case we do not want an extra
nodegroup to be responsible for a failure in the node installation I
expect.
===
additional info
* in order to have the tarball created by the build, you basically
need to create a file named
bootstrapfs-<something>.pkgs in config.planetlab
the build script in bootstrapfs should be able to properly create the
associated tarball (only the difference from the main tarball of
course is packed)
* in order to try and use the second install. mechanism, you would
instead create a pkgs file in the same directory but with any other
name so as to speed the build and prevent the creation of the tarball
I suggest we use extension-<something>.pkgs;
in this case the groupname *must* be of course extension<extension> as
per the above description
Of course you can also use the first method and simply erase the
tarball from the download/ area at runtime
===
Status
Most of this logic works, but unfortunately the second method is still
not unusable
What happens is that the hard drive's yum.conf is not yet correct and
still contains what was used at build time and that of course does not
make sense at install-time - will try to get this solved later
More information about the Devel
mailing list