Certificates and Testing

Security

Mutual authentication of executor and orchestrator

Orchestrator and Executor now use x509 certificates to authenticate each-others.
A tool for generating self signed certificates has also been included in security/util

Orchestrator

Bug fix

A major rewrite has been done in the concurrency code. The sync.Broadcast function is no longer used. Instead a fanOut function which rely on channels has been implemented.

Testing

A lot of more testing case has been developed. 87.7% of the code is covered so far:

go test -coverprofile=/tmp/coverage.out github.com/owulveryck/gorchestrator/orchestrator
ok      github.com/owulveryck/gorchestrator/orchestrator        8.797s  coverage: 87.7% of statements

go tool cover -func=/tmp/coverage.out
github.com/owulveryck/gorchestrator/orchestrator/executor.go:21:        Init            90.9%
github.com/owulveryck/gorchestrator/orchestrator/graph.go:36:           getNodeFromName 0.0%
github.com/owulveryck/gorchestrator/orchestrator/graph.go:44:           Run             100.0%
github.com/owulveryck/gorchestrator/orchestrator/graph.go:114:          Check           100.0%
github.com/owulveryck/gorchestrator/orchestrator/node.go:46:            Execute         66.7%
github.com/owulveryck/gorchestrator/orchestrator/node.go:108:           Run             93.5%
github.com/owulveryck/gorchestrator/orchestrator/structure.go:38:       Error           100.0%
github.com/owulveryck/gorchestrator/orchestrator/util.go:22:            fanOut          100.0%
github.com/owulveryck/gorchestrator/orchestrator/util.go:34:            fanIn           100.0%
total:                                                                  (statements)    87.7%

Race conditions

The code has been tested against race conditions. 4 of them has been detected and eradicated:

go test -race .
ok      github.com/owulveryck/gorchestrator/orchestrator        9.374s

API enchancement

• a GET /tasks is now listing all the tasks
• a DELETE /tasks/{id} Now stops a tasks (actually sets its timeout to 0)

The changes has also been ported to the swagger "contract"

Executor

A basic shell engine has been hardcoded for testing purpose.

Misc

A Makefile has been included and is helpful to build the executables with tests certificates.

Clients

A TOSCA client is in progress. So far it is able to parse the examples files in the standard documentation (eg single_instance_wordpress).

TESTING the release

Download the binary or grab the source, install tmux and run make testing

Communication with the executor

• Initiating the Executor interface that takes as parameter a "node"

      {
        "id": 4,
        "name": "le nom",
        "engine": "shell",
        "artifact": "example/script.sh",
        "args": null,
        "output": null
      },

POST and GET have been implemented

By now: no engine, but a ZMQ interface for communication between the drivers and the executor is in the pipe.

• The orchestrator is effectively calling the executor in the Execute function of a node
• The orchestrator now handle the corss node arguments:; for example, consider those nodes:

      {
        "id": 2,
        "name": "Node1",
        "engine": "shell",
        "artifact": "example/script.sh",
        "args": [
          "-e",
          "get_attribute Noeud1:output1"
        ],
        "output": null
      },
      {
        "id": 3,
        "name": " Node2",
        "engine": "shell",
        "artifact": "example/script.sh",
        "args": null,
        "output": [
        output1: "" 
  ]     
},

When Node2 is executed, depending of the engine, a result in placed in output1, then when Node1 is running, the orchestrator does substitute the get_attribute with the correct value from Node1 before sending it to the executor.

Featuring arguments

The node's input arguments have been implemented

Orchestration engine OK

• The orchestration engine seems to be bug free.
• The API is nearly stable
• A viewer client exists and is used mainly for development purpose by now
• A TOSCA client is in progress

TODO:

• Initiate the execution engine
• Implement the DELETE method in the orchestrator
• Use a Bearer Token to introduce the Authentication mechanism