[one-users] [RFC] Tool for Management of Service Execution

[Ignacio Martin Llorente]

Dear users,

We are evaluating the development of a new tool/command (oneservice?)  
to support the submission of a full service (as group of  
interconnected VMs). The user would define using a template the  
service components, number of instances, deployment ordering, and  
context definition. Below you can see a proposal for the template by  
Ruben.

We would appreciate any feedback you could provide using the mailing  
list or the development issue:

http://dev.opennebula.org/issues/100

Regards

Ignacio

---------------------

= 
= 
= 
= 
= 
= 
= 
= 
========================================================================
SERVICE DEFINITION TEMPLATE
= 
= 
= 
= 
= 
= 
= 
= 
========================================================================

# Define service components and its cardinality (number of instances)
# Syntax:
#   COMPONENT <UNIQUE_COMPONENT_NAME>  <COMPONENT_TEMPLATE>   
<CARDINALITY=1>

COMPONENT master  master.template	1
COMPONENT node    node.template		10

# Define deploy order, if you need a soft synchronization point, e.g. to
# instantiate IPs correctly
# Syntax:
#    DEPLOY <LIST OF COMPONENTS>

DEPLOY master, node

# Define dependencies if a harder synchornization is needed, i.e. do  
not submit
# children until parent reaches RUNNING
# Syntax:
#    PARENT  <LIST OF COMPONENTS> CHILD <LIST OF COMPONENTS>

PARENT master CHILD node


Example, The Cluster Service DAG:

COMPONENT sge_master master.one
COMPONENT sge_node node.one 5
DEPLOY sge_master, seg_node

= 
= 
= 
= 
= 
= 
= 
= 
========================================================================
CONTEXT SUPPORT IN TEMPLATES
= 
= 
= 
= 
= 
= 
= 
= 
========================================================================

Context definition: "A set of variables that are made available to the
VMs at boot time". Now you can refer to other service components  
context within
the component template. From the RFC:

CONTEXT = [
  <VARIABLE> = <VALUE>
  FILE       = <path to file to be included in the iso>
  DIRECTORY  = <path to directory to be included in the iso>
  TARGET     = <device to map the context block device>
]

VARIABLEs, are stored in sh syntax in a known file in the context  
block device.
Example:

CONTEXT = [
    HOSTNAME   = "sge_master"
    REPOSITORY = "https://dsa-research.org/repo"
    TARGET     = sdb
]

The context variables can refer to other template attributes. We use the
following syntax:

  $<ATTRIBUTE_NAME>

Example:
NAME = sge_master
CPU  = 1.0

...

CONTEXT = [
  HOSTNAME = "$NAME"
  TARGET   = sdb
]

If you want to address a multiple value attribute just put its name  
before the
target attribute:

  $<ATTRIBUTE_NAME>[<SUB_ATTRIBUTE_NAME>]

Example:

NIC = [ NETWORK="Public" ]

CONTEXT = [
  HOSTNAME = $NAME
  IP       = $NIC[IP]
]

If there are several attributes with the same name, select one by  
adding the
value of other attribute:

  $ATTRIBUTE_NAME[SUB_ATTRIBUTE_NAME, SUB_ATTRIBUTE_NAME = VALUE]

Example:

NIC = [ NETWORK="Public" ]
NIC = [ NETWORK="Blue" ]

CONTEXT = [
  HOSTNAME = $NAME
  IP       = $NIC[IP, NETWORK="Blue"]
]

Now you can refer to CONTEXT VARIABLES of other components using:

$<COMPONENT>.<VARIABLE>

Example:

NIC = [ NETWORK="Blue" ]

CONTEXT = [
  HOSTNAME = $NAME
  IP       = $NIC[IP]
  MASTER_NAME = $sge_master.HOSTNAME
  MASTER_IP   = $sge_master.IP
]


--
Ignacio M. Llorente, Full Professor (Catedratico): http://dsa-research.org/doku.php?id=people:llorente
DSA Research Group:  web http://dsa-research.org and blog http://blog.dsa-research.org
Globus GridWay Metascheduler: http://www.GridWay.org
OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org