The PlanetLab 4.2 Upgrade is underway! At the end of the upgrade all machines will be re-installed and include the following new features:

• Reference image changed from Fedora Core 4, to Fedora 8.
• Upgrade kernel from 2.6.12 to 2.6.22.19 and VServer from 2.0 to 2.3
• SMP support!
• Adding Vsys as a replacement for Proper
• Upgraded PlanetFlow
• Allow multiple VServer reference images
• New kernel features (ipv6, fuse, chopstix, kvm) available for the future.

• I pushed the new PCU page and requested that Tech's update their information.  This resulted in a flurry of feedback related to all the bugs I had introduced to the index.php/pcu.php scripts.  A more thorough testing would be nice for this.
• There were several site_admin problems, related to stale or mis-matched information between the PLC db and the node configuration.  
• Why can't PI's assign all roles to less privileged users such as 'user' and 'tech'?  This seems like an unnecessary task for Admins to perform any more.
• An 'operators' mailing list would be nice for this discussion of myplc administration.  This will be especially reelvant as myplc is pushed at more users.
• Feature request for faster notifications of down nodes.

Registration with PI role.

Old netflow log requests. What's in, what's out?  How do we get this information for requests?

This work is in preparation for asking sites to update their PCU information for Monitor.

I've created a better view for sites/index.php. It lists all nodes and allows techs or PIs to associate nodes with a PCU.

Additionally, the organization of the code is split more clearly between a template (standard html with minimal php variables, and loops) and control function.

I believe this will make it easier to integrate with additional ajax code later. I will request OneLab for comments on the code reorganization, using sites/index.php as an example.

I've completed a preliminary service for recording node downtimes throught the web.

While users/techs will have to log in twice, since it will not be hosted on the PlanetLab web server, the authentication mechanism uses the PL session key.

This may be kept for just admins. I'm not sure yet.

There is clearly confusion being caused by users still thinking that they need separate BootCD and plnode.txt/floppy files, when they are using the Custom, all-in-one BootCD.

I have made some changes to the myplc/db-config that sends messages, and I will make a few other changes to the GUI to provide in-line hints about what to do or download. I think there may be other sources of information causing confusion.

 Also, the bootmanager, should look on the BootCD itself first, and ignore any other node configuration files it finds... Or not?

To facilitate a more structured commit, build, deploy model for the PLC WWW files, I'm working on creating an RPM package for new_plc_www. The idea is that it would be possible to have a nightly, or weekly or whatever build of the *branch*, not just HEAD, and for individual packages to be updated within the MyPLC on guarddog.

Currently, new_plc_www is not a separate RPM, it's just dumped in with myplc-*.rpm. To facilitate a more fine-grained upgrade of just the new_plc_www files, I'm trying to create an RPM.spec file for these files.

Monitor has been suspended this week, due to operational setbacks. At the beginning of the week the database server was experiencing extreme load, and resulting in timeouts or failed boots by remote sites, complicating support for Monitor tickets. Rather than generate additional traffic, I postponed running monitor again.

The mis-match of the PlanetLab-branch.tar.gz bundle that's downloaded during a 'rins' was fixed for I2 nodes (of which there are many), so that after a rins 'codemux' is correctly installed. It's not clear how this happened other than just a stale version of PlanetLab-branch.tar.gz that didn't get updated to the 4.1 version.

Faiyaz and I recognized that the ipod.conf.php script was returning the wrong IP/Subnet to nodes, resulting in misconfigured /proc/sys/net/ipv4/icmp_ipod* values, that prevented api.RebootNode() from working with IPOD.

Upon investigation, it turned out that there is a limitation in the plc_config to express the kind of installation we have an PLC, namely two boot servers with independent IP addrs, either of which may send the IPOD to the node.

Faiyaz currently uses cfengine/server to distribute the configuration files to each server, boot, web, etc. This is ok, but the problem remains that plc_config cannot express the general, multi-machine installation we use, thereby complicating Node configurations that must know about the authenticity of these machines by IP.

I've been collecting links relevant to current technologies for building custom bootcds or livecds. The following are those available for building custom fedora cds. It looks very promising and could be very interesting in terms of how the CD is designed. Do we go for dead-simple fetch from PLC bootscript, or Live-CD node that treats disk as soft-state? I think it will be interesting to reflect on both extremes in the design space and the trade-offs over time, in order to get the most valuable features in.

• http://www-128.ibm.com/developerworks/linux/library/l-fedora-livecd/
• http://people.redhat.com/davidz/livecd/i386/
• http://gitweb.freedesktop.org/?p=users/david/livecd-tools.git