Changes between Version 6 and Version 7 of WorryingSlivers
- Timestamp:
- 12/08/11 00:32:42 (12 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
WorryingSlivers
v6 v7 80 80 We should be able to describe these relationships using our semantic models, and propagate labels by querying descriptions based on those models. We don't need to write any new code for stitching. We don't need to describe the producer to the consumer if the consumer already understands what kind of resource or service it wants to bind to. If it does not, then the configuration of virtual resources is malformed. 81 81 82 Let us suppose that we succeed in describing the relevant information as pairwise directed relationships in our models. This is equivalent to saying that we can represent a configuration of virtual resources or virtual resource elements as an entity-relationship graph. Moreover, we can partition the graph by aggregates, so that each node (vertex) of the graph resides in the partition for the aggregate controlling that node's virtual resource. Some edges in the graph cross partition boundaries. These edges require coordination among a pair of aggregates, i.e., stitching.83 84 82 == Partitioning Virtual Resources Within Aggregates == 85 83 86 Suppose then that we can describe virtual resources of a slice by a graph of elements (entities) and relationships, using a semantic model. Suppose further that we can partition the graph across aggregates as I have described, so that we talk to each aggregate only about the virtual resource elements that it hosts, and any adjacent edges. 84 Suppose then that we can describe virtual resources of a slice by a graph of elements (entities) and relationships, using a semantic model. Suppose further that we can partition the graph across aggregates as I have described, so that we talk to each aggregate only about the virtual resource elements that it hosts, and any adjacent edges. Edges crossing partition boundaries require coordination among a pair of aggregates, i.e., stitching. 87 85 88 Now the question is: how does the aggregate expose the graph through its API, so that a slice owner can operate on the graph? In the current (or near future) [DRAFT_GAPI_AM_API AM-API] there are simple calls to operate on the graph: create, destroy, and (soon) update. The create and update operations take as an argument an rspec document describing at least the entire partition of the graph residing at that aggregate. The requester says what region of the graph they want to operate on somewhere in the rspec document attached to the request, and not in the API.86 Now the question is: how does the aggregate expose the graph through its API, so that a slice owner can operate on the graph? In the current (or near future) [DRAFT_GAPI_AM_API AM-API] there are simple calls to operate on the graph: create, destroy, and (soon) update. The create and update operations take as an argument an rspec document describing at least the entire partition of the graph residing at that aggregate. The requester says what region(s) of the graph they want to operate on somewhere in the rspec document attached to the request, and not in the API. 89 87 90 Th e AM-APIoffers no way to talk to an aggregate about some regions of the graph independently of other regions of the graph. If we want to add resources, we must pass an rspec for the entire graph, with the new parts added. If we want to remove resources, we must pass a description for the entire graph, with some parts removed.88 Thus the AM-API itself offers no way to talk to an aggregate about some regions of the graph independently of other regions of the graph. If we want to add resources, we must pass an rspec for the entire graph, with the new parts added. If we want to remove resources, we must pass a description for the entire graph, with some parts removed. 91 89 92 The alternative view is that if a virtual resource graph can be partitioned across aggregates, then it must also be possible to partition the graph within aggregates. We can break the graph into named regions and use the aggregate API to talk about specific regions, passing the rspec for only the regions of interest. Welet the aggregate handle any edges that cross region boundaries within the aggregate.90 But if a virtual resource graph can be partitioned across aggregates, then it must also be possible to partition the graph within aggregates. We can break the graph into named regions and use the aggregate API to talk about specific regions, passing the rspec for only the regions of interest. We can let the aggregate handle any edges that cross region boundaries within the aggregate. 93 91 94 If we partition the graph into regions, how shall we decide where the boundaries are? How big are the regions? At one extreme there is a single region: this is the degenerate case represented by the v2.0 AM-API. We can make any changes we want using a single API call, but we must pass rspec for the entire graph, even for a minor change. If we introduce region boundaries, then we have a tradeoff. With smaller regions, we need more requests to instantiate or update a given graph, but each request passes a smaller rspec. With larger regions, we make fewer API calls to instantiate or update the graph, but the rspec documents are larger.92 If we can partition the graph into regions, how shall we decide where to set the boundaries? How big shall we make the regions? At one extreme there is a single region: this is the degenerate case represented by the v2.0 AM-API. We can make any changes we want using a single API call, but we must pass rspec for the entire graph, even for a minor change. If we introduce region boundaries, then we have a tradeoff. With smaller regions, we need more requests to instantiate or update a given graph, but each request passes a smaller rspec. With larger regions, we make fewer API calls to instantiate or update the graph, but the rspec documents are larger. 95 93 96 94 == Slivers == 97 95 98 Finally we come to slivers. What is a sliver? A sliver is a region of a slice's virtual resource graph. Either the graph is partitionable, or it is not. If the graph is partitionable, then we need a name for the partitions. Sliver is a fine name. But perhaps the community will insist on a different name.96 Finally we come to slivers. What is a sliver? A sliver is a region of a slice's virtual resource graph. Either the graph is partitionable, or it is not. If the graph is partitionable, and we choose to partition it, then we need a name for the partitions. Sliver is a fine name. But perhaps the community will insist on a different name. (Virtual Resource Assembly?) 99 97 100 98 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. 101 99 102 100 I believe that we know how to describe the resources we care about as partitionable graphs. 103 If the graph is partitionable across aggregates, then it is partitionable within aggregates. Then the only question is whether the aggregate API permits any partitioning within an aggregate. And why would the API prohibit an aggregate from selecting a suitable partitioning for the virtual resources that it serves?101 If the graph is partitionable across aggregates, then it is partitionable within aggregates. Then the only question is whether the aggregate API permits any partitioning within an aggregate. And 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? 104 102 105 103 But what is a sliver *really*? What does a region of the graph represent? I have been vague in talking about "virtual resource elements" and "entities" and "virtual resources". It is an abstraction. The 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.
