[Planetlab-devel] whitelists and federation

[Thierry Parmentelat]

Larry

This is great news. I am looking forward to reading more about this 
"engine", even if the changes I am describing are still needed in the 
short term IMO, unless this new approach is ready to get deployed. The 
current model has its known deficiencies, and the road you are showing 
will be invaluable in addressing them, but this is no reason for running 
- rather badly - broken code :-)

As to the question about nodes- vs plc- oriented mechanisms, there 
definitely seems to be a need for both entities to play a role. I do not 
know how much the node-oriented approach owes to the need for 
delegation, since I am not truly familiar with this; but even without 
delegation both sides are clearly involved.
I just have the feeling that, as I already had an opportunity to report, 
we are lacking a concept in the model. I believe there should be a 
notion of what is requested (typically by a slice, or by a plc on behalf 
of a slice) and of what is granted (by another plc, or a node(, or a 
site:)); mostly in the current plc code both things are thought of as 
being similar/identical, and this imho is a flaw in the design.
I expect this has been taken into account in your new model, and again I 
am curious to learn more about it.

Thierry

Larry Peterson wrote:
> Thierry,
>
> This is the tip of the iceburg. We have been working on a "peering policy
> engine" that sites and PLCs can use to specify how their resources are
> allocated, including resources set aside for whitelisted slices. From these
> individual policy statements, we are able to generate node-specific policies.
> Mechanistically, we understand how individual nodes respond to requests,
> but I think we need similar PLC-level mechanisms (since some of the polices
> are enforced there, rather than at the node).
>
> Larry
>
> On 10/4/07, Thierry Parmentelat <thierry.parmentelat at sophia.inria.fr> wrote:
>   
>> Tony has given me the current whitelisted nodes, that turn out to all be
>> in poland
>> so as a conservative method, I have just removed all nodes in *.pl from
>> both
>> inriaonelab_oscar
>> ftlannionple_oscar
>> this should solve the immediate issue - at least in an hour or so the
>> changes should propagate to your db.
>>
>> I will come back to this list in a while when I have other news on the
>> other aspects detailed below
>> -- Thierry
>>
>> Thierry Parmentelat wrote:
>>     
>>> Hi all
>>>
>>> marc just brought to my attention an issue he is having: some of our
>>> slices  are being allocated on the TP nodes that are subject to
>>> whilelisting, which of course is quite wrong (needless to say our
>>> slices were not on the whilelists)
>>>
>>> what happens as far as I can tell at this early stage is that
>>> - first off, whitelists are not at all considered in the current
>>> federation scheme.
>>> That's probably my fault; at the time there was no whitelist in the
>>> system at all, and even if I now have this concept in my API, I
>>> imported it verbatim from your codebase without realizing the impact
>>> it should have had on federation
>>> - as a consequence, our users can see the whilelisted nodes as normal
>>> nodes, and can add them to their slices without restriction
>>> - when plc pulls ple's slices for federation, the slice-node
>>> association gets imported without problem as well, I would think - I
>>> cannot check on your end but again, federation code is not
>>> whitelist-aware
>>> - and then all the rest (nodemanager calls getslivers, and creates the
>>> slice) must work without a glitch too, otherwise the slice would just
>>> not show up
>>>
>>> My first action would then be to manually check our slices and remove
>>> whitelisted nodes from them. the thing is, however, I have no clue
>>> what the whitelisted nodes are, so I'd need this information to do the
>>> job
>>>
>>> Then of course I'll need to fix this more deeply. Federating
>>> whitelists is of course mandatory, and would have two aspects
>>> - exports whitelists of course
>>> - and at slice-import, perform a local check against whitelists, so a
>>> PLC does not blindly on the other end like it currently seems to do
>>>
>>> Of course and as usual, feedback and comments are welcome
>>> -- Thierry
>>>
>>> _______________________________________________
>>> 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
>