Feature #100

Tool for Management of Service Execution

Added by Ignacio M. Llorente over 10 years ago. Updated over 7 years ago.

Status:ClosedStart date:04/21/2009
Priority:LowDue date:
Assignee:Daniel Molina% Done:

0%

Category:CLI
Target version:-
Resolution:wontfix Pull request:

Description

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.

================================================================================
PROPOSAL OF SERVICE DEFINITION TEMPLATE (by Ruben) ================================================================================

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

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

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

DEPLOY master, node

  1. Define dependencies if a harder synchornization is needed, i.e. do not submit
  2. children until parent reaches RUNNING
  3. Syntax:
  4. 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:

$&lt;ATTRIBUTE_NAME&gt;

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:

$&lt;ATTRIBUTE_NAME&gt;[&lt;SUB_ATTRIBUTE_NAME&gt;]

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
]


Related issues

Duplicated by Feature #17: VM Groups Closed

Associated revisions

Revision dd493d92
Added by Javi Fontan over 3 years ago

Merge pull request #100 from atodorov-storpool/patch-4

im/monitor_ds.sh skip broken symlinks

History

#1 Updated by Ruben S. Montero over 7 years ago

  • Target version set to Release 3.6

#2 Updated by Daniel Molina over 7 years ago

  • Assignee changed from Javi Fontan to Daniel Molina

#3 Updated by Ruben S. Montero over 7 years ago

  • Target version changed from Release 3.6 to Release 3.8

#4 Updated by Ruben S. Montero over 7 years ago

  • Status changed from New to Closed
  • Target version deleted (Release 3.8)
  • Resolution set to wontfix

This is currently out of the scope of the project. We may reopen it in a future...

Also available in: Atom PDF