Skip to content. | Skip to navigation

Personal tools

Navigation

You are here: Home / Wiki / Rspecplans

Rspecplans

RSpec Plans

RSpec Plans

The RSpec is not yet in its final form. There are still a number of areas which we need to improve or flesh out.

Design Principles

  • RSpecs should be about what a Component Manager can do, not about what the user can do. For instance, a user may be able to set up a virtual router themselves on a raw PC. But the node should only have a 'virtual router' virtualization type if the CM sets one up.
  • RSpecs should contains specific information about components, not universal relationships. If a field can change from node to node even if all the other fields are identical, then that is specific information about that node. Information about the relationships between disk images and virtualization types or the virtualization type on the node and the interface are universal to those virtualization types, not the nodes.

Resource Discovery

ProtoGENI will use a very simple resource discovery model. The number of entities federating will be relatively small, so it will be reasonable to have global knowledge of which

There will be two phases.

  • In the first phase, the querier gets a list of all physical resources - whether or not they are currently available. The idea is that this operation does not need to be done often - possibly only once, or possibly weekly, monthly, etc. This information is cached.
  • In the second phase, the querier gets a list of which resources are currently available. This phase does *not* return details about the physical hardware, simply a "bit" indicating whether each component is available for use or not. This step in context-sensitive: ie. the query needs to be made with the identity of the person who will be requesting tickets, as the (aggregate) components might make different policy decisions depending on who is asking.

Because all components are uniquely identifiable with URNs, it is easy to combine the results of the second query with the results of the first, and feed this in to the slice embedding service.

The idea is to use optimistic resource reservation, as Emulab does: make the availability query right before running the slice embedder, then attempt to get tickets for the components that were chosen. If any have become unavailable in the meantime, simply hold on to the tickets you were able to grab, and run the slice embedder again to replace the unavailable ones.