[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