[Planetlab-devel] PLC system discussion (in the hall)

[Stephen Soltesz]

Regarding changes based on this proposal:

In regard to the entire proposal, this sounds like a fine generalized approach. 
  I'd like to be sure that we're all understanding the consequence of this kind 
of organization to secondary support code that uses the API and third-party 
users of the API.

 From my perspective, I see the hard-coded types that exist in the current API 
as logically moving up a level into an intermediate support layer between the 
more flexible/generic API and the applications that interact with it (i.e. the 
GUI, command scripts, etc).  See attached image for a sketch.

The concern is that if we make this change without adding the support library, 
then there is nothing that enforces the new 'type' system across the GUI, 
secondary support scripts, or third-parties, etc.  The concern within our code 
base is that each interaction with the API will do it a little differently. or 
that inconsistencies may develop over time, as one changes how the attributes 
are used while another does not.  The concern for third-parties is that they 
will have no idea what the results of their queries is showing them any more, as 
the number of node types increases or the way we use attributes changes.  This 
is also a challenge for documentation, b/c the type is not implied by the API 
any more, but defined by use cases.

There are two approaches to dealing with this that I see:
   1. Add support libraries that implement this functionality on top of the
generic API.  These would be used instead of the API directly by everyone that 
wanted to interact with the API.

   2. Add support API calls that are part of the 'secondary', or 'special' set of
API functions.  In this way, the published API calls wouldn't necessarily change 
at all.  Instead, there would just be a new, low-level implementation that is 
more flexible wrt supporting different node-types, etc.

The second approach is probably the most backward compatible, and by exposing 
the newly-generic functions we can claim to be more GENI compliant b/c we 
support records for any node types what so ever.

Stephen.


Thierry Parmentelat wrote:
> Just so that everybody knows what we're talking about here
> 
> - we tried to come up with a scheme where the 'nodes' data structure 
> would become more generic
> 
> - so we are trying to remove most of the hard-coded 'fields' in the node 
> data structure, to keep only the ones that seem to belong to *any* kind 
> of node; this basically can be depicted as trying to sketch the notion 
> of a 'generic node', that can then be instantiated into a variety of 
> node 'types'
> 
> - the various types that we are envisioning at this stage would be either
> * plain node (read, current node)
> * dummynet boxes
> * PCU's
> * Wifi Mesh
> * IxP
> 
> - the attribute system is very similar to either
> (SliceAttributeType,SliceAttribute) for slices
> (NodeNetworkSettingType, NodeNetworkSetting) for network interfaces
> and, simply put, allows to dynamically extend the set of fields that 
> would be attached to a given type of nodes
> 
> - it will, also, allow to remove the notion of a nodegroup, that can now 
> in the new system be described as a pair (attribute,value); so e.g. the 
> alpha nodegroup can be seen as the set of nodes whose 'deployment' 
> attribute is 'alpha'; in particular the 'conf_file' object will not 
> refer to a nodegroup anymore, but to a n (attribute,value) pair instead
> 
> - in the process we decided to remove the 'model' node field, that's 
> mostly not up2date; so the few instances where this is used (typically 
> the bootmanager's hardware requirements checking step) would now use 
> atribute(s) instead
> 
> - I'll add to Reid's list an item about database migration, that will 
> need some care in this perspective
> 
> ===
> in terms of impact on the rest of the system, we've identified that
> 
> - node filtering will probably need being improved, so that e.g. 
> filtering on attributes would be feasible and reasonably efficient 
> (efficiency is the one major reason why the node 'type' will be 
> hardcoded as a static field in the database)
> 
> - BootManager will need to use the new attributes for
> * figuring the bootstrapfs to be installed
> * checking hardware requirements
> 
> - The NodeManager, as well as the web GUI, look like they might need 
> some changes as well
> 
> - this also might imply a disruptive change in the API
> 
> ===
> Also, one thing that has been left out of the discussion is:
> for actually eliminating the PCU stuff, I guess we'll need something to 
> create relations between nodes. Like, a PCU is likely to control a 
> handful of plain nodes; same for the dummynet box;
> 
> -- Thierry
> 
> 
> On May 14, 2008, at 4:12 PM, rmoran at CS.Princeton.EDU wrote:
> 
>> basic take aways from the hall meeting:
>>
>> * NodeGroup becomes (node) attribute
>> - map attrib to node
>> * Create node attribute table
>> * Remove model from node table
>> - formalize model options into attributes * Add node TYPE field to 
>> node table
>> * Add id/value pair to conf file table
>> - find node's conf files do a join (N, attrib, conf file, id/val)
>>
>> BootManager:
>> set attributes
>> - bootstrap fs + extensions
>> - requirement checking
>>
>> nodemanager?? GUI???
>>
>> _______________________________________________
>> Devel mailing list
>> Devel at lists.planet-lab.org
>> https://lists.planet-lab.org/mailman/listinfo/devel
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.planet-lab.org
> https://lists.planet-lab.org/mailman/listinfo/devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: old-and-new-api.png
Type: image/png
Size: 12003 bytes
Desc: not available
Url : http://lists.planet-lab.org/pipermail/devel/attachments/20080516/b3b97a17/old-and-new-api-0001.png