Changes between Version 8 and Version 9 of WorryingSlivers


Ignore:
Timestamp:
12/08/11 10:17:09 (13 years ago)
Author:
chase@cs.duke.edu
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • WorryingSlivers

    v8 v9  
    9494== Slivers ==
    9595
    96 Finally we come to slivers.  What is a sliver?  A sliver is a region of a slice's virtual resource graph.  A sliver API allows a client to operate on one region independently of other regions.
     96Finally we come to slivers.  What is a sliver?  A sliver is a region of a slice's virtual resource graph.  A sliver API allows a client to operate on one region independently of other regions.   For example, we can add virtual resources to a slice by attaching a new region, without changing anything about the graph as it exists.  And we can remove virtual resources from a slice by detaching a region, without changing anything about the rest of the graph as it exists.
    9797
    98 There seem to be three classes of arguments "against" slivers.  First: the name sliver is confusing to people.  We can change the name, but it probably won't help.  Using a name that we're already using for something else (like resource, or component, both of which refer to physical substrate) might make the situation worse, rather than better.  I think sliver is a good name. 
     98There seem to be three classes of arguments "against" slivers.  First: the name sliver is confusing to people.  Well, we can change the name, but it probably won't help.  I think sliver is a good name, because it sounds like what it is---a piece of a slice---and it doesn't already mean something else.  Other options proposed, like resource or component, might make the situation worse by promoting a confusion between virtual resources and physical resources.  (I say this recognizing that they are sometimes the same thing, but that makes the confusion more confusing, not less.)
    9999
    100100The second common argument makes various assumptions about what others assume slivers to be, and then argues that system X is different.  Indeed, perhaps system X is different.
     
    102102The third argument is (in essence) that virtual resources are tightly coupled, and we can't operate on them independently, or that trying to do so might add undue complexity to the API, or might get us into trouble later if we discover unexpected dependencies.
    103103
    104 The third argument merits a response.  My response is: either the virtual resource graph is partitionable, or it is not. 
    105 If the graph is not partitionable, then it is not partitionable across aggregates.  Then there are only slices, and each aggregate must receive the entire graph for the entire slice.   If we change any part of the graph, we must pass the new slice rspec to at least all aggregates participating in the slice.  We can make this approach work for demos, but it will not scale to large slices, and it will not succeed in accommodating dynamic slices.  And then somebody in another project will figure out how to describe a virtual resource graph in a way that makes it partitionable, and we will move forward again from there.
     104The third argument merits a substantive response.  My response is: either the virtual resource graph is partitionable, or it is not.  If the graph is not partitionable, then it is not partitionable across aggregates.  Then there are only slices, and each aggregate must receive the entire graph for the entire slice.   If we change any part of the graph, we must pass the new slice rspec to at least all aggregates participating in the slice.  We can make this approach work for demos, but it will not scale to large slices, and it will not succeed in accommodating dynamic slices.  And then somebody in another project will figure out how to describe a virtual resource graph in a way that makes it partitionable, and we will move forward again from there.
    106105
    107 On the other hand, if the graph is partitionable across aggregates, then it is also partitionable within aggregates.  I hope and believe that the graph is partitionable.  Then the only question is whether the aggregate API permits any partitioning within an aggregate, at the aggregate's discretion.  And why would the API prohibit that?  Why would the API prohibit an aggregate from grouping and organizing the virtual resources that it serves?  Why would the API prohibit an aggregate from breaking its virtual resources into slivers that can be operated on through sliver APIs?
     106On the other hand, if the graph is partitionable across aggregates, then it is also partitionable within aggregates.  Then the only question is: should the aggregate API permit any partitioning within an aggregate, at the aggregate's discretion? And why would the API prohibit that?  Why would the API prohibit an aggregate from grouping and organizing the virtual resources that it serves?  Why would the API prohibit an aggregate from breaking its virtual resources into slivers that can be operated on through sliver APIs?  If the aggregate finds its resources to be not easily partitionable, then it can always choose not to partition them, and group all the virtual resources of a slice at that aggregate as a single sliver.  It then has all the advantages of the current AM-API.
     107
     108Needless to say, I hope and believe that the virtual resource graph is partitionable. 
    108109
    109110== Types of Slivers ==
     
    122123The Vision Slide says that GENI will support heterogeneous deeply programmable virtualized infrastructure resources.  What are those?  We do not know.  But they are heterogeneous, so there could be many different kinds.  And if the architecture is to have impact over more than a few years, then it must accommodate resources that have not been invented yet.  We do not know what these will look like.
    123124
    124 What we do know is that it must be possible to describe these new virtual resources using a semantic model, and that the description will be a graph of elements and edges representing relationships among the elements.  And if we have a stitching architecture that can propagate labels across edges, then the graph will be partitionable.    And if the graph is partitionable, then it will be convenient to partition it into regions in order to allow the possibility that we might use the aggregate API to operate on different regions independently of other regions.  For example, we can add virtual resources to a slice by attaching a new region, without changing anything about the graph as it exists.  And we can remove virtual resources from a slice by detaching a region, without changing anything about the rest of the graph as it exists.  But we can't say in advance what the regions might represent, or what the various type-specific sliver APIs might be (except for the ones we understand now).
     125What we do know is that it must be possible to describe these new virtual resources using a semantic model, and that the description will be a graph of elements and edges representing relationships among the elements.  And if we have a stitching architecture that can propagate labels across edges, then the graph will be partitionable.    And if the graph is partitionable, then it will be convenient to partition it into regions in order to allow the possibility that we might use the aggregate API to operate on different regions independently of other regions.  But we can't say in advance what the regions might represent, or what the various type-specific sliver APIs might be (except for the ones we understand now).
    125126
    126127In the past, some have seemed to argue that the impracticality of a one-size-fits-all sliver API undermines the whole dream of GENI.  But the notion of subtyping has been proven in many other contexts and should be comfortable here as well.