Data

Data is under development, so subject to change (quite much hopefully).
Nodes interact with Data according to a protocol. We suggest we comply with the AMQP standard. https://www.amqp.org

The Universal Truth

All nodes voluntarly sharing their information give Data the opportunity to construct a Universe of information. Data on its turn provides specific information of interest to specific nodes from this Universe to these specific nodes.

Guiding principles

• Precedence Analysis
• Desired state is assumend
• Data holds the Universal Truth

Data presents nodes on request with node taylored views on the Universal Truth, thus supplying the nodes with the the information they require. This is the normal situation in which Data provides updates on the views. Data may respond that it needs additional information. Nodes may find Data needs to be updated with information they hold.

Conceptual Communications Model

Node message (Req)	Data Response (Rep)	Node Action
Request View --->	Reply with view data --->	Process view info
	Reply with Request for Information --->	Prepare Information Feed
Request for Information Feed --->	Reply with hash of Information received --->	Store received Hash
Request Information Feed --->	Reply with hash of Information received --->	Store received updated Hash

Daemons

Data uses the cf-messagd daemon for message handling. cf-messaged answers queries and accepts feeds from nodes. Data writes feeds into a message queue in order to have an audit trail. The feeds are picked up and processed by a daemon that evaluates the feeds are propagates the data into The Universal Truth.

Feeds

Nodes send out feeds on request. This request is triggered by a Data response to an information request. The node assumes the requested information to be available from Data, but Data can decide to ask for more information before being able to supply the requested information.

Views

Data presents information from The Universal Truth through views. cf_message obtains information from Data by presenting Data with the json-container defined by the view that corresponds to its role. Data returns the information in the json container that mirrors the request.

Sample Dialogue

cf-agents through cf_message presents Data with a request ona view, in this case a nagios view:

{ "message": "view",
  "query": 
  { "view_name": "mnmutl" }
}

Nagios requests information on all the services offered by all the nodes in this symplified sample Universe. Data returns a json container with information, organized by domain, service and host.

{ "response": "mnmutl",
  "domains":
  [
  { "domain": "webhuis.nl", 
    { "services":
      [
      { "service": "http",
        "hosts": [ "apjums0001", "mnmutl0001" ] }
      { "service": "tomcat",
        "hosts": [ "webjen0001", "webjen0002" ] }
      ]
    }
  } 
  { "domain": "hnvk.nl", 
    { "services":
      [
      { "service": "http",
        "hosts": [ "apjums0002", "mnmutl0002" ] }
      { "service": "tomcat",
        "hosts": [ "webjen0003", "webjen0004" ] }
      ]
    }
  }
  ]
}

Nagios

Nagios only needs little information about the nodes in the Universe.

• Hostname, sys.uqhost
• Domain, sys.domain
• Service, delivered by the host

We feed back information on Services to Nagios. Each Service has a couple of parameters and an array of hosts fulfilling the service.

{ "services": [  { "ssh": [  { "check_command": "" 
    { "hosts": [ { "host": "<fqdn>" }, { "host": "<fqdn>" } ]
    }
  }]
}

Hostgroups are implied by their domain and role, so each host belongs to the domain group and the groups of its role.

View Queries

View Name	Sorted Result Set	Selection Keys	Comment
__________________________	__________________________	__________________________	__________________________
Nagios View	domain, uqhost, service	host, domain, role	Nagios groups and has service details

---

Return to: Cfengine