Skip to content. | Skip to navigation

Personal tools

Navigation

You are here: Home / Wiki / Protogeniwideareanodesoftware

Protogeniwideareanodesoftware

Here's the overview of what I plan to do. My overall goal, as I said during the meeting, is to allow protogeni wide area nodes to run the plab client side when we want, or to be dedicated to experiments (and os_loadable, etc).

(In the wiki at ProtogeniWideAreaNodeSoftware.)

  • Setup a linux-based PLC using myplc.
  • Setup a CentOS-based build server so we can build the plab rpms -- plab's software distribution/installation method -- from either plab src or some version of it. Plab uses centos, a linux distro similar to fedora, and that's probably the easiest thing for us to do, rather than getting their setup working on Fedora.

As I said in my mail about plc-on-inner-boss, I extracted the necessary stuff from the current plab nightly rpm builds, or from source, to use for the plc-boss combo, but it would be nice to be able to build our own rpms rather than cobbling stuff together. For instance, building a new NodeManager rpm and then pushing it is the easiest way to install it on a plab node.

This has the potential to be a time sink, so if I can't get it done within a day or two, I'd probably skip ahead.

  • Write "federation" scripts that sync Emulab database "objects" with the PLC via the PLC xmlrpc API. For instance, anytime the Emulab backend adds/modifies/deletes a user, the "syncuser" script would be invoked, and it would gather Emulab user info, and use the PLC xmlrpc api to perform any necessary updates. I already did some of this, on a very lightweight and incomplete scale, for the plc-on-inner-boss case (just users and nodes).

We need this for users (and all other user info, like keys), nodes, projects (which become sites). Experiments will get "mapped" when the plab portal creates a slice for them, just like it happens currently.

Note that Emulab project permissions get mapped into plab user permissions, although extremely unsatisfactorily. In Emulab, permissions are per-project; in plab, they are global (i.e., not per-site). This doesn't matter if we restrict users from making PLC xmlrpc calls that manipulate state on the PLC, which was the consensus in the meeting. If we ever need to allow this, then we would have to consider adding the additional logic to the PLC code to authenticate slice/site operations based on permissions in the site, and change the db schema to accommodate.

  • Make the widearea dongle be able to boot the plab mfs. I already built a combined dongle, but there are still a few problems. If the nodes are going to be able to change "mode" between being pgeni plab nodes and dedicated, os_loadable Emulab widearea nodes, the tbboot sector written to the disk after os_load (tells the initial dongle bootloader which partition to boot) has to be able to boot from another partition on the dongle, which doesn't look possible with the current tbboot struct. Not too hard to fix, I think, although there may be some hard case I'm not seeing yet.

On the plab side, this requires ensuring that the partition layout created during the initial plab node install does not include the sector that the dongle bootloader queries to figure out which partition it should boot, if not the mfs on the dongle. Shouldn't be a problem.

I haven't thought much about what this is going to require for the Emulab side. Presumably, when the node is in the protogeni plab "mode" instead of the protogeni emulab wide area "mode", we can just reserve it to some undeleteable experiment. Maybe there's some better, more generic mechanism that should be added for this, but I can't find a reason to do it for now.