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

[Thierry Parmentelat]

hi, catching up ..

Well, from my perspective one of the culprits here is the implicit  
assumption that the API should somehow match the implementation. Even  
though that has maybe never been formally stated, that's how things  
have been so far.

What we've been talking about is more about implementation; the  
generic model that we've sketched would allow us to reuse more code,  
rather than to have to define a new table and related links for each  
new type of node; I hope this to be particularly useful to people who  
need to deal with various types of nodes without requiring them to  
dive into the details of the DB; similarly this model addresses a lot  
of issues that we've been having so far, and that we've had to work  
around with more or less ad hoc solutions, in particular based on  
nodegroups, that were truly overloaded

this is not to say that all this need be exposed. as Stephen pointed  
out, we're going to end up with differents levels of APIs; the way I  
would put it is that what he calls the support libraries could well be  
the public API to the system; while the GenericNode interface is maybe  
more an implementation 'detail' as Larry puts it

coming back to the PCU's, I have the feeling that the API should be  
more modular, and that we should be able to split the API into more  
autonomous parts; on the one hand, from the GENI abstractions (CM,SM)  
it seems clear to me that we should be able to run these two parts as  
two totally separate entities, otherwise my feeling is that we're  
missing the point. on the other hand, having the default, usual,  
'plain' nodetype available seems required, but the other types of  
nodes should be more easily merged through something that looks like  
plugins.
Finally, the PCU thing is truly an implementation detail; the fact  
that we wish to use the same underlying, generic, implementation  
mechanisms to bring it to life, does not mean, IMHO, that it should be  
part of the API at all. As far as federation goes, we really do not  
care about PCUs.

my 2 cents -- thierry

PS1.
Coming back to nodegroups.
To add to the confusion, I'm going to propose that we actually keep  
nodegroups, that would be defined as
nodegroup = attribute + value
so that, e.g.,
nodegroup_alpha = { n / n['deployment'] = 'alpha' }
This would be a means to reduce the migration mess, we could e.g. keep  
the conf_files thing more or less as-is
The reason why I'd been proposing to kick them off was related to the  
way they are defined right now, which is extensively, like in
nodegroup_alpha = { n1, n2, ... }
Think of it as a smart playlist as opposed to the regular playlists,  
in itunes

PS2.
continuing the same metaphor, I'd propose that these NodeAttributes  
should be called 'tags' instead; this is very similar to the tagging  
system in the mp3 format - and to a lesser extent to the web-2.0  
notion of tags.
So we'd have SliceAttributes, NodeNetworkSettings, and NodeTags. This  
would make it simpler to locate stuff in the code, which was the  
reason why I did call NodeNetworkSettings that, and not  
NodeNetworkAttributes.

PS3.
also dring this meeting we haven't had time to define the links  
mechanism, but I guess everyone understands that this is a requirement  
also. What I mean is is a mechanism for modelling the kind of  
relationship that a dummynet box has with the nodes under its control.  
Or, for handling the relationship between a PCU and its controlled  
nodes.
Not too sure what needs to be attached such a link, so a rough would be
Link = node1, node2, linktype, value   (linktype being declared like a  
sliceattributetype....)
of course the value may in some be cases be more complex than that,  
but as a first stage that could fit I guess.

comments / thoughts ?


On May 16, 2008, at 4:22 PM, Larry Peterson wrote:

> I start to worry when I hear "API changes
> will be necessary."