Skip to content. | Skip to navigation

Personal tools


You are here: Home / Wiki / Planetlabfederation


(Originally from Main.DavidJohnson's bas:~johnsond/planetlab/peering.notes.)

Here's some stuff on the peering model. The basic model is shared DB state at the XMLRPC API level. All PLC peers share a database schema (well, they don't have to, but I'm sure they will to avoid modifying the API implementation!). Shared state is not transitive. For instance, if you have PLCs A, B, and C, and (A,B) and (B,C) are pairs, B knows nearly everything (i.e., things like user passwords are not shared between peers) about A's and C's users and user keys, slices, and nodes. Thus B can add A's and C's users to B's nodes that are part of slices created on A or C. C knows about A's objects (i.e., persons, keys, slices, nodes) IFF C is peered with A (unless I have missed another place in the code where this is handled (but basically if C and A are not peered, C lacks the information to "resolve" A's objects as it gets them from B -- I think). There are probably a few more restrictions, but I think that captures the important stuff right now. It does not seem at all like user U who created slice S on A can go and add nodes on B's or C's websites; indeed, this would significantly complicate shared state.

It seems to me that based on the current API, only admins and pis can create slices. It does not seem like PIs can grant the PI role to existing users (they can only grant lower roles, such as tech and user) to existing users (and I think this extends to approving new users as well).

-- Main.DavidJohnson - 14 Nov 2007