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

[Larry Peterson]

Immediate future is between now and whenever we do
something better. :-)

Generally, I think you're right about the relationship
between MA and SA wrt attributes. We've been thinking
about the right place to place a "peering policy engine",
and hope to have something concrete to show people in
the next few weeks.

Larry

On Jul 19, 2007, at 12:06 PM, Thierry Parmentelat wrote:

> 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
>