[PL #13410] Private Planetlab Broken
Thierry Parmentelat via RT
devel at planet-lab.org
Fri Apr 7 04:54:11 EDT 2006
Email Recipients (see http://www.planet-lab.org/Support)
Requestor: jaffe at cs.huji.ac.il
Ticket Ccs: jaffe at cs.huji.ac.il, kirk at cs.huji.ac.il
I must have missed that one message of yours.. Thanks anyway for making
this clear again
I am preparing for the adventure, so let me try to get this straight,
please correct my assumptions if needed
- starting from a - fresh or not - fc2 install, I can setup my own plc
by rpm-installing the latest nightly built myplc rpm
I still did not get exactly how/when the configuration is done, I've
seen the xml/py/shell stuff in myplc but could not figure whether it's
called by the rpm-install stage. No big deal. I take it the ability to
provide several xml files will let us store our own tunings in a
site-dependent xml, which sounds good.
- At this stage the boot CD and node installs all use the single
PlanetLab tarball. Boot-time node updates will immediately return since
the rpm repository is empty.
- I can start populating this rpm repo with my own stuff (and re-index
repo); next node updates will use them right away. I take it the boot CD
creation method is roughly unchanged as compared with what we have now.
- About hacking the bootmanager, again I assume the methods we've been
using so far (overwriting python source code, refresh and sign
bootmanager.sh) will keep on working..
- If I get you right, what you're saying is that if at that stage I
update the myplc rpm from a more recent one, I will lose the changes I
might have done under /plc/root, while the changes I did under /plc/data
will be preserved. This is not too obvious from reading the code, I'd
like you to confirm or infirm that point if you please.
Mark Huang via RT wrote:
> Email Recipients (see http://www.planet-lab.org/Support)
> Owner: Nobody
> Requestor: jaffe at cs.huji.ac.il
> Ticket Ccs: jaffe at cs.huji.ac.il, kirk at cs.huji.ac.il
> Thierry Parmentelat via RT wrote:
>> - once myplc is setup, how is it updated ? are the rmp-installs supposed
>> to perform smooth update ?
> I asked this question on the list a few weeks ago, and didn't receive
> any opinions. So my idea, which hasn't been totally or safely
> implemented yet, is that everything except /plc/data should be treated
> as a monolithic binary. If you go poking around in /plc/root after it's
> mounted, and upgrade things by hand, or replace binaries, or change the
> scripts, that's your business.
> With that said, I haven't settled on the set of files that should go in
> /plc/data. You will probably have to poke around in /plc/root by hand to
> fix things for at least the foreseeable future.
> There is a place for upgrade paths in the startup sequence; carefully
> writing and testing these paths is the next step in MyPLC development.
>> - did you design a mechanism we can use for 'injecting' home-made rpms
>> into this plc instance ? (basically, I need to (1) be able to use a
>> local mirror of the PLC's rpms, for performance, and (2) manage my own
>> set of custom rpms)
> Nowadays, new nodes are installed from a monolithic tarball
> PlanetLab-Bootstrap.tar.bz2, rather than being installed by yum. The
> Bootstrap tarball is built from the RPMS of every release, so
> maintaining a local mirror of PlanetLab RPMS is not strictly necessary
> Thus, MyPLC does *not* come with a local mirror of PlanetLab RPMS, only
> a pre-built Bootstrap tarball. It does initialize an empty "planetlab"
> repository. If you want to inject additional RPMS, place them in the
> repository, edit the yumgroups.xml file, re-run yum-arch, and both new
> and existing nodes should pick them up.
> Devel-community mailing list
> Devel-community at lists.planet-lab.org
More information about the Devel-community