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

[Larry Peterson]

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
>