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

[Larry Peterson]

It seems strange to fold PCUs into this. A "node" can always have
auxiliary pieces -- special cards, adjacent boxes, and so on. These
seem to be attributes of the node (with node-specific hardware
responsible for dealing with this sub-piece) rather than visible to
PLC (and the API).

Or have I completely misunderstood...

Larry

On Fri, May 16, 2008 at 1:02 PM, Stephen Soltesz
<soltesz at cs.princeton.edu> wrote:
> 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
>
> _______________________________________________
> Devel mailing list
> Devel at lists.planet-lab.org
> https://lists.planet-lab.org/mailman/listinfo/devel
>
>