* the main work for this requirement will do on testbed server, but testbed node needs to provide some API to perform actions managed by the server.
When the experiment needs to be run, the server in charge* of the selected resources needs to perform the necessary operations so that the slice is allocated and all the necessary steps to start running the experiment are done over the nodes.
*NOTE: I had not realized until now, but this phrasal assumes that Confine has more than one server. So, consistency and replication information protocols will be require (and have not yet analyzed on requirements list)
This requirement is about the necessary steps to provide a slice ready to be used from the resource allocation decided previously and freeing the resources after the slice lifecycle. It involves the creation of the slivers on each of the nodes involved on the slice deployment and removing them on the slice decommission.
It involves all the necessary operations until the slice is ready to be used. For instance, if the slice requests consists on a set of VMs over a set of nodes, the creation of those VMs on the node belongs to this phase, so also implies the resource allocation.
This requirement is close related to SRSM-6 requirement because the mechanism to activate/deactivate slices might be provided by SRSM-6.
Researchers need a way to Start and Stop or schedule an experiment (so: activate, deactivate and put on-hold a slice) For this analysis, it is assumed that this mechanism exists. In the same way, it is assumed that exist a set of valid R resources announced over a set of N nodes into the server and a valid user U. Below is described the set of steps that a server should make in order to check that the requested operation is performed ok.
SFA provides some information about what they consider as this operations:
“The first two operations stop and start the execution of any active slivers within an existing slice. The slice retains any resources it holds, although a component that uses work-conserving schedulers is free to utilize those resources for the duration of the suspension. The slice should not expect threads running in the slice to resume at the point the slice was suspended, as the implementation of StopSlice is free to kill all running threads, in which case, StartSlice effectively reboots the slice. However, the slice’s on-disk state should remain unaffected by the operations. The third operation resets a slice to its initial state. This includes clearing any on-disk state associated with the slice. Thus, ResetSlice is effectively equivalent to deleting and re-creating the slice, but without freeing the slice’s resources. The fourth operation removes the slice from the aggregate and releases all of its resources.”
And finally, explains: “Note that these operations might be invoked by a user responsible for the slice (e.g., a researcher associated with the slice with the slice or a suitably authorized administrative entity responding to unexpected behavior in the slice), or by a user responsible for the component or aggregate (e.g., an operator affiliated with the MA). In the latter case, the operator might not know that the slice exists on the component, but is terminating or suspending the slice on all components it manages. This permits an operator to control a slice on all of the components it manages without the cooperation of a slice manager that knows all the components on which the slice has been embedded. These four control operations affect the slice state on a particular aggregate, but not on other aggregates where the slice may also have a presence.”
I'm not sure about the expected recommendation… To Do: discuss on new week-meeting (2012.01.25)