Tags:
create new tag
, view all tags

Topology Instantiation Protocol (TIP)

Overview

Topology Instantiation Protocol (TIP) defines the interaction between AST_master, minions and resource brokers. This model is a generic implementation and should be extensible to any kinds of resources. When new resource types are defined, its related resource brokers and minions should incorporate TIP so that they can communicate with the AST_master in a scandalized way.

TIP uses Application Specific Topology Data Language (ASTDL) for communication. The Extensible Markup Language (XML) is a general-purpose makeup language. Its extensibility comes from the fact that it allows users to define their own tags, and tools are available to define its schema, parse and validate the XML files. AST defines its own set of tags in its ASTDL. In AST, the schema of ASTDL is defined in Relax NG (RNG). The set of tags defined in ASTDL is also used in the TIP for the interaction between AST_master, minions and resource brokers. The extensibility in XML also allows AST to include new resources definitions in ASTDL without interrupting the core operation of AST_master.

Prior to receiving requests from client, AST_master should be started. It can run in any host that the user have access to. When AST_master starts, it will read its configuration file and load the resource descriptors.

Life Cycle of a typical AST

pre-setup stage

  • User will send the setup_req to the well-known port that AST_master is listening to. This is an ordinary socket connection.
  • Once AST_master receives the setup_req, it will validate the file by the schema specified at resources descriptors. Once validated, AST_master will load the default values to any undefined attributes in the setup_req file.
  • reservation_req. Then, AST_master will send reservation_req to its resource brokers. Resource brokers will identify the resource if this is a logical resource, not a physical one. It will also bear the responsibility to reserve the resource for this AST.
  • reservation_resp. The resource broker will send resource_resp to AST_master indicating if the reservation is successful or not. In the case of a success, resource broker will return a reservation_id to AST_master.
  • Once AST_master receives all reservation_resp from all resource brokers, it will return a success or failure to the client.
  • If this is a success case, the client will receives an ast_id, a globally unique topology ID, to identify the AST in subsequent requests. And the topology will be written to a the ASTDB

setup stage

  • setup_req. When itís time to provision the AST, AST_master will contact minions by sending the setup_req to them.
  • setup_resp. The minions will return setup_resp to AST_master to indicate success or failure for the setup_req.
    • If any of the setup_resp is a failure, AST_master will release all reservation of that AST and send release_req to all minions.
    • If all setup_resp are successful, AST_master will put the AST to the next stage.

active stage

  • ast_complete. Once all resources are setup according to what the XML file specifies, AST_master will send a ast_complete to all minions. In this message, AST_master will give the minions the whole AST details instead of only the resources that the minions are responsible for.
  • app_complete. Minions will return app_complete to AST_master when they no longer need the services of that AST.

release stage

  • The release stage starts when any one of the following situation is satisfied.
    1. The AST failed at the setup stage, AST_master will automatically issue release_req on that AST.
    2. The client sends a release_req for the AST.

  • release_req. When AST_master receives the release_req on an AST, it will send release_req to all minions.
  • release_resp. Minions will send release_resp to AST_master, indicating whether the request is success or failure.

State Machine for AST instances

At any given point, an AST is given a state to denote the stage that the AST is at in respect to the AST life cycle.

Basic AST state type: SETUP_REQ, SETUP_RESP, AST_COMPLETE, APP_COMPLETE, RELEASE_REQ, RELEASE_RESP Advanced AST state type: MOD_REQ, MOD_RESP

At any given point, an AST is given a status which tells the status of the stage that the AST is at.

AST status type: FAILURE, SUCCESS, PENDING

The below State Machine illustrates how the AST changes stages and status in the AST life cycle.

State Machine for AST

Topic revision: r4 - 2008-03-31 - FionaLeung
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback