[Planetlab-devel] status on extensions management

[Marc E. Fiuczynski]

Hi Thierry,

This sounds good. I have not looked at the code, but is it possible to 
run the "yum" command optionally rather than upon failure of retrieving 
the tarball?  Also, I suppose something should be put in place that 
automatically (daily?) for each extension does a yum update.  Ideally 
this would be something that is automatically generated by the build 
system and handled at run time by the node update subsystem.

Btw., as discussed previously, I am not sure it is a good idea to 
closely couple BootManager with yum.  One thing we should strive for is 
to be distribution agnostic (so that someone has a small chance in the 
future to switch to a debian based distro).  Though I suppose such a 
switch would require a fairly nontrivial makeover of the build system, 
too. Any way, just something to keep in mind.

Cheers,
Marc


Thierry Parmentelat wrote:
> 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
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.planet-lab.org
> https://lists.planet-lab.org/mailman/listinfo/devel