[Planetlab-devel] PLC system discussion (in the hall)
Larry Peterson
llp at CS.Princeton.EDU
Sat May 17 23:13:46 EDT 2008
One other point about the API. It is helpful to keep the public
and private interfaces distinct and separate. Inventory control
seems an obvious private interface.
Larry
On Sat, May 17, 2008 at 10:01 PM, Thierry Parmentelat
<thierry.parmentelat at sophia.inria.fr> wrote:
> 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."
>
> _______________________________________________
> Devel mailing list
> Devel at lists.planet-lab.org
> https://lists.planet-lab.org/mailman/listinfo/devel
>
>
More information about the Devel
mailing list