[Planetlab-devel] problem with layering bootstrapfs images one on top of another

[Stephen Soltesz]

Hey, Thierry,

That sounds good.  I understand the intention for the extensions.  And the 
desire to keep the directories separate.

It turns out that the code to do what I wanted already exists; we just didn't 
know about it.  In the future we'll adjust our deployment protocol.

In particular, I looked in PLCWWW/boot/index.php since I imagined that this 
would be the place to have custom bootmanagers for different node groups, with 
each pointing to a distinct 'boot' directory for their default images and 
extensions.  And, the code is already there! :-)

So, the other day when we were trying to deploy alpha nodes with an experimental 
bootmanager script, it would have been possible by naming the new version 
"alpha_bootmanager.sh.sgn"!  And having an boot-alpha directory populated with 
the new bootstrapfs-planetlab-i386.tar.bz2...

This was a good exercise :-)

Thank you,
Stephen.

Thierry Parmentelat wrote:
> The intention is indeed to have a single image installed, plus a 
> possible set of extensions
> extension images are elaborated by the build as part of the bootstrafs 
> package, and basically contain only the files that do not come with the 
> initial image
> 
> one confusing thing is maybe that full images and extension images bare 
> the same kind of name, which can cause problems; for instance in your 
> case alpha should be the name of the initial image and not the name of 
> an extension; if both kinds of images could be told from their name at 
> least the system would refuse to load the alpha image as an extension
> 
> When I wrote that part I was not thinking about alpha as an extension; 
> in my mind an extension is more something like 'wifi' or 'umts';
> [[it must be stressed that the build does not know about alpha; what is 
> named alpha in a given plc is mostly what a daily build has created as 
> its bootstrapfs image.]]
> the thing is, we use nodegroups for too many things apparently;
> 
> What should be done here would be more like this:
> in the same way as alpha nodes have a dedicated rpm repo, they should 
> also have a dedicated boot directory with the initial image and possible 
> exentions; these images should be consistent, i.e. come out of the same 
> build.
> 
> How does that sound ?
> 
> -- thierry
> 
> On Mar 19, 2008, at 8:29 PM, Stephen Soltesz wrote:
> 
>> My understanding of the current bootstrafs image and installation scheme:
>>
>> - a default image exists for all nodes in the system.
>> - secondary images, identified by nodegroup names, may also exist.
>>
>> The BM iterates over all the files that might apply to a node based on 
>> its nodegroup and the default fs image, downloads each one and 
>> incrementally applies each on top of the other.  Let me know if I have 
>> misunderstood the intention.
>>
>> I have observed the following problem on PLC when applying the 
>> bootstrapfs-alpha on top of the current 
>> bootstrapfs-planetlab-i386.tar.bz2.
>>
>> When I prevent the default image from being installed, first the 
>> installation succeeds.  Something is occurring when overwriting the 
>> first filesystem with the alpha filesystem that causes some 
>> corruption.  I'm writing this here in case others have any ideas.
>>
>> In general, this seems to me like a bad idea to just layer one fs on 
>> top of another.  I think it might be valuable to have two different 
>> types of downloads:  1) filesystems and 2) addons to a specific 
>> filesystem.  I find it very easy to imagine cases where layering 
>> filesystems will break the resulting one.
>>
>> My proposal would be that only one filesystem would be downloaded per 
>> node. This could be identified by a specially names nodegroup, 
>> 'alpha-image', and any addons identified by 'alpha-addon-xyz'.  I'm 
>> open to other mechanisms; my main point is just that only one 
>> filesystem should be downloaded for a node.
>>
>> Is there a better way to avoid installing the 'default' image on nodes 
>> that have nodegroup images?  That might be the simplest thing.
>>
>> Thank you,
>> Stephen.
>>
>>
>>   Step: Install: bootstrapfs tarball.
>>   turning on swap space
>>   mounting root file system
>>   mounting vserver partition in root file system
>>   downloading bootstrapfs-planetlab-i386.tar.bz2
>>   Using SSL without pycurl will by default check at least standard certs.
>>   extracting /tmp/mnt/sysimg/bootstrapfs-planetlab-i386.tar.bz2 in 
>> /tmp/mnt/sysimg
>>   Done
>>   downloading bootstrapfs-alpha-i386.tar.bz2
>>   Using SSL without pycurl will by default check at least standard certs.
>>   extracting /tmp/mnt/sysimg/bootstrapfs-alpha-i386.tar.bz2 in 
>> /tmp/mnt/sysimg
>>   Done
>>   Copying resolv.conf to temp dir
>>   Copying boot server certificates and public key
>>
>>
>>   Step: Install: Writing configuration files.
>>   Setting local time to UTC
>>   Enabling ntp at boot
>>   failed to glob pattern /etc/rc0.d/[SK][0-9][0-9]messagebus: Unknown 
>> error 530
>>
>>
>>   Exception while running: Running chroot /tmp/mnt/sysimg chkconfig 
>> ntpd on failed (rc=256)
>>
>>   Step: Updating node boot state at PLC.
>>   Successfully updated boot state for this node at PLC
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.planet-lab.org
>> https://lists.planet-lab.org/mailman/listinfo/devel
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.planet-lab.org
> https://lists.planet-lab.org/mailman/listinfo/devel