RE: [Planetlab-arch] Proposed Changes for Dynamic Slice API

[Timothy R. <tr...@in...>]

At Tue, 27 Jan 2004 13:28:21 -0500 (EST), Steve Muir <sm...@CS...> wrote:
> On Tue, 27 Jan 2004, Timothy Roscoe wrote:
> i meant that the point i was making was an implementation point - clearly
> the architecture of planetlab doesn't dictate that we export the entire
> contents of the slice DB as an XML file (albeit in a somewhat NM-specific
> format), that's just how it's implemented right now.

Fair enough.

> i'll generalise my point to the following: since there seem to be several
> applications that require access to the slice DB we should consider if
> the needs of those applications can be met with a common DB access or
> export mechanism.  for example: listSlice could just send you the same XML
> file that we export to Node Manager.  that may not be ideal but it would
> be reasonable.
> 
> >  - list of slices I've created
> >  - list of slices I'm authorized for
> >  - list of slices created by one of my PIs
> 
> yes, those all seem like reasonable queries.  isn't the last query
> equivalent to all slices with a specific site prefix e.g., irb_?  both the
> last two points can be answered by consulting the XML file - i'll use that
> as an argument for exporting the DB wholescale and letting you grep it
> whichever way you like rather than trying to anticipate all the queries
> you might perform and encapsulating them in an API.

So I'd make a few additional points here:

 1) I think "queries" is not the best way to think of these, even if
    they end  up translating  to db queries.   I think it's  better to
    view them in the way you suggest above, as different applications.
    
 2) There is a security aspect here as well: we have yet to resolve
    whether we want the list of slices to be protected in some way,
    but in either case the issue is scoping the view of the database
    according to users. 

 3) There is a scalability aspect here independent of the centralized
    aspect of the current implementation.   Returning a list of all
    slices obviously won't scale, but limiting the list to one of the
    three attributes about does scale quite nicely. 

 4) About the prefix issue: this opens the whole Pandora's box of
    naming issues w.r.t. sites and slices.   I sent out an email to
    planetlab-arch yesterday, but sourceforge seems to have dropped
    it.  I'll resend.

> let me put a (perhaps) simple question out there: is there a reason that
> jon q. user should not be able to see the entire list of slices, including
> node and user assocations and resource specifications?

I think there may be security/privacy issues there, but I'm not
going to contribute any points yet (!).   But the scaling issue (3) is
also important, particularly as we grow.  Right now there are
relatively few people exercising this interface, but if it suddenly
became the de facto standard way to keep track of one's slice, we'd
get a whole lot of traffic very quickly.   It's certainly the way I
envisage working in the future. 

 -- Mothy