[Planetlab-devel] NM semantics

[Faiyaz Ahmed]

Hi Justin,

Justin Cappos wrote:
> On Dec 5, 2007 6:46 PM, Faiyaz Ahmed <faiyaza at cs.princeton.edu 
> <mailto:faiyaza at cs.princeton.edu>> wrote:
> 
>     Hi Stephen,
> 
>     I can remove the Create() from the Ticket() call. It really is unneeded
>     to have both encapsulated in 1 call and the ability to have a slice
>     ready but not started may appeal to some users.
> 
> 
> What does 'ready' mean?   The reason why I requested this is that 
> sometimes I'm going to want to destroy a VM that may not exist (I can't 
> be sure) and I need to pass the ticket before calling destroy.  
> 

Currently when you deliver the ticket using the Ticket() method, 
internally this is wrapped to Create(), which dumps the ticket 
information into the NM db, then creates the sliver on disk.  The 
context isn't running and initscripts are not started.

In the vserver implementation currently in production, the context is 
started when a user ssh's into a sliver or an initscript is explicitly 
started by NM.  In the next version of vserver, due to be released in 
the near future on planetlab, the context isn't started until Start() is 
called.

The slice is therefore "ready" to be started.

>      >Why is NM keeping a record of data that is returned by the next
>     GetSlivers?? call anyway?
> 
>     NM cache's getslivers data if connectivity to PLC is lost and operations
>     on slivers needs to continue (ie. expiration, bandwidth limiting, etc).
>     When connectivity exists, GetSlivers?() is called periodically by NM to
>     the PLC API, and the NM database (cache) is updated with the latest
>     slice information.
> 
>     During the time between polls, a user may dynamically create or destroy
>     a sliver. For this operation to complete, the same information
>     presented
>     by GetSlivers? needs to be present in NM's database, so a natural work
>     around is to encapsulate the sliver information in the signed ticket
>     itself. The next time NM calls GetSlivers?, and attributes for the
>     sliver have changed, the updated attributes are used in place of
>     attributes presented by the ticket.
> 
> 
> Also, I'm not sure I understand what you're saying here, but VMs are not 
> destroyed automatically if I neglect to add them to PLC.   They happily 
> exist on the node until I tell the NM to destroy them without me ever 
> contacting PLC.
>

Are you sure?  The ticket you request from PLC takes a slice_name 
argument.  That slice_name (or slice) is first created at PLC, set to 
the "delegated" instantiation, and given a slice attribute delegating 
its authority to another slice (of "controller" instantiation).  It's 
when this slice is first created that an expiration is set, and 
therefore encapsulated in every ticket delegating its creation requested 
from PLC.

If I remember correctly, since this expiration is set in the ticket AND 
returned by GetSlivers() on PLC, NM will expire the delegated slice like 
normal.

But, I could be wrong and I'd appreciate it if you could show me where 
this doesn't work.


Faiyaz


> Thanks,
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Devel mailing list
> Devel at lists.planet-lab.org
> https://lists.planet-lab.org/mailman/listinfo/devel