[Planetlab-devel] Re: [PL #17324] wildcards in slices

[Thierry Parmentelat]

>> - how do we tell a slice is defined on all nodes (I take it this is the 
>> case for pl_conf) that has node_ids=[]
>>     
>
> For now, there's a hack in GetSlivers() that adds slices that begin with 
> PLC_SLICE_PREFIX (by default, "pl") to the slivers[] lists for all local nodes.
>
> We can probably replace this with some sort of slice attribute, or a DB hack. 
> I'm leaning toward the latter.
>   
up to you, but db hack or not, somehow a peer calling GetSlices() has to 
be able to tell that the two returned slices in question are special. 
Maybe the fact that the returned node_ids is the empty list is enough, 
in fact. Let's just be aware of the various dependencies.
>> I have that issue that I need to kind of ignore the 2 builtin slices 
>> when I perform caching, at least that's the smartest idea I have about 
>> this, which doesn't sound that smart...
>>     
>
> The plan was to use GetSlivers() to get sliver information, right? I haven't 
> been following the development of RefreshPeer()...how much functionality is 
> duplicated between GetSlivers() and RefreshPeer()?
>   
Well, GetSlivers essentially performs a cartesian product of nodes and 
slices; so once you've cached nodes and slices - which is what 
RefreshPeer is about right now - you're about done; I've never used 
GetSlivers yet but if it's working on an unfederated plc, I dont expect 
to have to change anything to it, in much the same way as 
AddSliceToNodes is essentially intact. At least, that was my understanding.

>> - can I safely assume the slice_attribute_ids will make sense across 
>> various plc's ?
>>     
>
> Hmm. Good point. Probably not. You can assume that the slice attribute names 
> will be consistent, so you may have to call GetSliceAttributes() as well.
>
> --Mark