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

[Fred Kuhns]

Thank you for the details Thierry ... this sounds like a more extensible 
solution. One question, I had been planning to use the node group to 
download a different bootmanager, one that understands a "supercharged" 
node's environment. Will the node type now be used for this purpose? Or 
is this approach deprecated?

fred

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