Changes from Version 1 of PlanetLabFederation

Author:

trac (IP: 127.0.0.1)

Timestamp:

03/26/08 18:05:12 (2 years ago)

Comment:

--

PlanetLabFederation

@@ +1 @@
+
+
+(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