• OMF Design & Planning 16 Feb 2012
  • 1. Federation Goal
    • 1.2. Comments
  • 2. Resource
    • 2.1. Model
    • 2.2. Naming and Addressing
    • 2.2. Protocol
    • 2.3 Simple "Hello World" scenario
    • Comments
  • 2. OMF Federation Architecture
    • 2.1. Proposed Architecture Overview
    • 2.2. Proposed PubSub Organisation
  • 3. Implementation Plan
  • 4. Remaining OMF components

OMF Design & Planning 16 Feb 2012¶

1. Federation Goal¶

• Goal: enable concurrent experiments involving resources from testbeds under different administrative control
  A group of research collaborators (i.e. users) working on the same research study want to perform a series of experiments, for which they require resources (e.g. R1, R2) provided by different testbeds or aggregates (e.g. A). This set of resources is described in one (or more) ‘resource description’. It defines a ‘virtual aggregate’ (e.g. X) or slice that includes these resources, i.e. a slice is just a container.

• For the institutions:
  A federation is an agreement between peer institutions to present a unified view of their individual aggregates. There should be no technical limit for such a peer to participate in more than one federation. Therefore, OMF should allow multiple federations with potentially overlapping institutions to co-exist.

• For the experimenters (= users):
  The above scenario involves three main steps:
  • resource discovery and reservation: the user gathers the list of resources offered by aggregates, checks their availabilities for a given time period, and requests their reservation. This may involve advanced capabilities such as having the aggregates* return a list of ressources filtered using constraints, e.g. at least x resources of type y.

• resource control: the orchestration of the resources to perform a given experiment, following the instructions in the experiment description. Some examples of instructions are the configuration of software options, starting an application, or collecting measurement variables. Before being used resources need to be provisioned - resource provisioning: is the process of preparing resources to make them available to the users at the start of their reservation period. Provisioning may involve different tasks depending on the resource’s type, e.g. creating a virtual machine, turning on a physical device, loading an OS image to a disk, or installing some pack- ages. At the end of this process, the reserved resources are ready to be used in some experiments.

1.2. Comments¶

• User could reserve/use resources from different federations for the same study

• Basic model of user/resources in federations: whiteboard figure 1

• the above steps form a scylce, at any stage we should be able to add more resource, run more experiment, etc...

• resource provisioning is part of the resource control step.

2. Resource¶

The resource model is also described in more details at: Resource Model v4

2.1. Model¶

A new component is created by an existing component receiving a create message. It is initially in the inactive state, and may transition to active immediately.

A configure message is used to change the properties of a component. Some components may only allow configuration in the inactive state, and some properties may only be set at creation time, as part of the create message. The request message asks a component to report on its status via an inform message. Some components can alternate between the inactive/active state through activate/deactivate messages respectively.

A component is discarded when it receives a release message. The creation of a component C by a component P results in a parent-child relation between them. A parent component holds a list of all its existing children. For consistency, a component forwards a received release message to its children and will only cease to exist when all its descendants do so. Some components are containers including other components.

• COMMENTS:
  • We HAVE TO put this model first on this document.
  • Resrouce discovery is a 'request' send to the parent resource for its existing children that match a given constraints. This can be optional, as for some parent resources the user know already that some children exisit
  • Resource reservation is the 'create' request being sent to a parent resource, and it can or not have a requested time (i.e. some resources may not need to be reserved, such as an application on a node that we already have)
  • Resource provisioning is the act of creation done by the parent resource, and that can happen whenever the parent resource decide to, as long as it is before the requested time.

• COMMENTS:
  • whiteboard figure 3 (discard whiteboard2)
  • Creation is = to reservation
  • Provisioning happens anytmie prior to reservation starttime (up to the parent resource)
  • No Guarantee - Best effort for reservation. When your reservation startime arrives, there is no guarantee that your resource will be ready
  • Only guarantee is that if the create message is successfull, there will be a RDV Pt created for that resource on the message system, i.e. there Obs point for that resource exist.

2.2. Naming and Addressing¶

2.2. Protocol¶

• NOTE every time a resource updates its state it MUST send a inform message on its PubSub node to say so!

2.3 Simple "Hello World" scenario¶

• Experiment script from Thierry with suggestions from Max: use-scenario-2.rb
• More suggestions from Jack: create_add_release.rb

Comments¶

• Make sure to discuss:
  • communication design for resource
  • simple scenario

2. OMF Federation Architecture¶

2.1. Proposed Architecture Overview¶

At the centre of this architecture is a publish-and-subscribe (pusub) messaging system, which is realised by a set of collaborating servers (PS).

• Resource discovery & reservation:
  the Principal Investigator (PI) of study X creates a Slice subscription node on this system, which will be the messaging channel for the Slice and its resources.
  Then the users of study X publish their resource descriptions to a specific federation subscription node, to which all the scheduler entities (SCHD) of the federated aggregates are subscribed. This subscription node embodies the federation, i.e. it is the user’s entry point to the unified view presented by the federated aggregates. To allow multiple federations to co-exist, there can be many federation subscription nodes and a SCHD can subscribe to many of them, e.g. if an institution participates to two federations, then the SCHD for its aggregate must subscribe to both corresponding federation subscription nodes. When receiving a request with a resource description, the SCHDs build a list of offered resources and their availabilities, which match the description. They may build these lists from inventory information served by an aggregate manager (AM) entity. These lists are forwarded to the user, who selects the resources to be used in the study. This results in a reservation request, which is published to the SCHDs to reserve the selected resources. The SCHD and AM have an open API, which can be used by the PI’s Experiment Controller (EC) or other software to execute all these tasks via the pubsub system.

• Resource provisioning:
  the AM performs all the tasks required to make a reserved resource ready for use. This may be initiated either by the experimenter’s EC or by some aggregate service responsible for the automatic provisioning of booked resources. At the end of this stage, a Resource Controller (RC) is associated to the newly provisioned resource (Res). The RC is the interface to the barebone resource, it uses the pubsub system to handle and process messages from/to other entities on behalf of the resource.

• Resource use:
  During the resource utilisation phase, the researcher’s EC interprets the experiment description and uses the pubsub system to send requests to the involved RCs and to receive reports on the experiment’s progress. The RC instructs the resource to execute the tasks within these requests and relays their outcomes. If the resource is instrumented, it may collect filtered measurements as instructed by the RC based on the experiment description. These data are sent to mea- surement entities (OML), which can store them or process & forward them to other OMLs. These OML entities are themselves resources, which understand the same communication protocol as the RCs and thus can also be organised and controlled via the EC and the experiment description. The researcher may use software such as LabWiki to visualise and analyse (VIS+A) the experiment’s progress and measurements. Third parties may contribute such custom software, which use the pubsub system to request resource information from the RCs or measurement samples from OML entities.

• Note: at any stage, the operator of an aggregate can use software to monitor and manage (VIS+M) the state of its provided resources via the pubsub system.

2.2. Proposed PubSub Organisation¶

• About Subscription Nodes:
  A subscription node is identified by name@domainID. The domainID is the domain name of the server hosting that node. Each aggregate must have an associated XMPP server, with domainID = aggregateID, and a DNS service record to resolve domainID. This record will be used by XMPP servers to initiate server-to-server sessions. The name part is a unique identifier for the subscription node within a domain. While this identifier could be just a fixed- length hash, for development and maintenance purpose we define it according to the tree structure as illustrated on the above figure. For example, the ID of the subscription node res3 created for the experiment exp1 part of sliceX hosted by the server foo is: sliceX/exp1/res3@foo.net. It is important to note that in the context of exp1 the users will not have to deal with such a node ID, they will only manipulate resources (e.g. res3) and the OMF control tools will handle the lookup of the corresponding subscription node IDs.

• Resource discovery & reservation:
  In the discovery and reservation phase, the PI selects a pubsub server to host the study’s slice and creates (via an EC or other tools) the slice’s nodes, e.g. sliceX@foo.net and sliceX/resources@foo.net. A user of study X then publishes a discovery message with a resource description to the federation’s subscription node federationF@bar.net. The schedulers of all the aggregates that participate to federation F are subscribed to that node and receives that request. As mentioned earlier, our architecture support multiple federations (e.g. federationG@foobar.net) and aggregates can participate to many of them, i.e. a scheduler can subscribe to many federation nodes. These schedulers receive the request and publish back their list of matching resources and availabilities. The user selects the resources and publishes the reservation requests to the same node, which will be confirmed (or not) by the schedulers.

• Resource provisioning:
  During the resource provisioning phase, the user publishes a provisioning request to the subscription node for each reserved resource (e.g. aggregateB/res3@aggregateB). In each aggregate, the AM receives the message and performs the tasks to setup the resource. When a resource (res1) is ready, the AM starts an RC (RC1) to control it and instruct that RC to subscribe to the slice’s subscription node for that resource (e.g. sliceX/resources/res1@foo.net).

• Resource use:
  In the experiment orchestration phase, the user’s EC (EC Exp1) creates the nodes related to the experiment (exp1), i.e. one for the experiment and one for each resource (e.g. sliceX/exp1@foo.net, sliceX/exp1/res1@foo.net). The EC Exp1 will also create the nodes for all new resources that are created during an experiment execution, such as a new application instance or a new container for other resources (e.g. group i). For each resource to be involved in exp1 (e.g. res3), the EC Exp1 publishes on its slice’s node (e.g. sliceX/resources/res3@foo.net) a configuration message requesting it to join exp1. Upon receiving that message, the RC (e.g. RC3) subscribes to the nodes of exp1 which are relevant to it (e.g. sliceX/exp1/res3@foo.net and sliceX/exp1/groupi@foo.net if res3 is included in the group i container). The RC is then ready to accept any commands related to exp1’s execution, which are published on these nodes.

• Note:
  Some additional subscriptions enable restricted message broadcasts and are not displayed on the above figure for legibility reason. For example, all entities involved in an experiment must also subscribe to the experiment’s node (e.g. sliceX/- exp1@foo.net) to respond to experiment-wide broadcast, such as an emergency shutdown.

3. Implementation Plan¶

• Requirements:
  • Use coding convention
  • Use namespaces
  • Write and Use tests: unit, integration, and system

• Release Date: July 12 for item 1-4 below

• 1) New RC implementation

• 2) New EC implementation

• 3) AM modification to fit the above scenario and architecture

• 4) Consolidate communication stacks for all OMF entities

• 5) Better Debug Mode for OMF entities

• 6) AM handling the Provisioning of Resources (i.e. support for virtualisation!)

• 7) New and modified AM functions (Inventory schema, SQL-agnostic, ... see tickets related to AM)

• 0) Global feature orthogonal to the above:
  • OMF packages as GEMs
  • ?

4. Remaining OMF components¶

• Integration with NITOS Scheduler

• Integration with SFA-based testbed

• System testing