[Planetlab-devel] cache-based federation and slice attributes

[Thierry Parmentelat]

Hello Larry

This proposal is fine with me.

I don't know what you were meaning by 'immediate future', but for the 
next couple months I do not expect to have big needs for defining new 
SliceAttributeTypes - using the code names to avoid confusion.

As I said I've set the proper-related SliceAttributes for 
princeton_comon and princeton_slicestat.
I can deal with the three other slices that you quote as soon as I can 
locate a fresh slices.xml (another story - I am dealing with faiyaz 
about that). I'll just need to be informed whenever a change occur, I 
have no experience on how often that can be.

Now about what comes after that immediate future, is there any comment 
on my proposal below ? This workflow-like idea of separating requests 
from actual allocation has similarities with site or user registration. 
It's not necessarily a big deal in terms of implementation.

-- Thierry

Larry Peterson wrote:
> Thierry,
>
> We just discussed how to deal with attributes (for the
> immediate future). Here's the proposal.
>
> We declare a universal (and flat) set of attributes, and
> their default values. All peers agree to this set; it's
> the set we have in place today. We discuss (and agree to)
> any future changes we want to introduce. When this becomes
> too painful, we'll figure out the right way to contextualize
> the attribute name space. (Even with context, we expect
> there to be a subset of "universal" attributes.)
>
> We declare a set of "preferred slices," such that each peer
> copies all attribute values for slices in this set (rather
> than effectively set to the default values). For starters,
> this set includes slices that require Proper privileges:
> arizona_stork, princeton_comon, princeton_slicestat, nyu_d,
> and princeton_codeen. As with the attribute set, we
> discuss/agree what goes in this set over time.
>
> Larry
>
>
> On Jul 17, 2007, at 11:30 AM, Larry Peterson wrote:
>
>> How do we go about selecting attributes, on an as-needed basis, that
>> we need to translate across federation boundaries. I agree that parsing
>> slices.xml by hand sucks.
>>
>> Larry
>>
>> On Jul 17, 2007, at 11:27 AM, Thierry Parmentelat wrote:
>>
>>> Hello everyone
>>>
>>> I'd like to come back on an issue that I'm having with the 
>>> federation code
>>> I've tried to make that point already but am not sure I did, so just 
>>> so everyone is on the same page:
>>>
>>> To summarize the issue:
>>> * some/most slices, like comon, need slice attributes to operate 
>>> correctly (e.g. proper privileges)
>>> * the federation code does *not* cache this at the moment, the 
>>> rationale being that granting such privileges should be an explicit 
>>> decision on the foreign plc end (e.g. for comon, we at planet-lab.eu 
>>> should set those slice attributes for the nodes that we run)
>>> * but since the slice attributes are not cached *at all*, that 
>>> foreign plc has no clue what is actually needed.
>>>
>>>
>>> As a quick and dirty workaround, so we can run planet-lab.eu 
>>> smoothly, I went into a gory parsing of slices.xml and eventually 
>>> digged my way;  I hope to have comon show up shortly; other slices 
>>> may need to ask us to set this sort of things.
>>>
>>>
>>> However this of course sucks. The point I tried to make is that the 
>>> current data model in myplc needs to be altered.
>>> IMO there should be a clear distinction between, on the one hand 
>>> what a slice requested, and on the other hand what the hosting myplc 
>>> has granted. The former being, if I got it right, a function of the 
>>> SA side of myplc, and the latter a function of the MA side.
>>>
>>>
>>> As a final note. The idea that was presented by Stephen in Warsaw, 
>>> about using a 'delegation' slice on foreign nodes as a 'service 
>>> creation handle' looks real nice, and the more I think about it the 
>>> more I like this idea; it would clearly have a simpler impact on the 
>>> data model than the current cache-based federation scheme had had, 
>>> and would make the separation between MA and SA much more natural. 
>>> It would be however, mostly orthogonal with the issue I described 
>>> above; IMHO.
>>>
>>> -- 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