
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">

</head>

<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">

<div>Hello All,</div>

<div><br>

</div>

<div>The purpose of this email is to document a few discussions from the summit, and to facilitate communication between parties at Docker and the Heat community.</div>

<div><br>

</div>

<div>The way the Docker resource is currently implemented requires the remote Docker api to be enabled on the compute instances that Heat wants to create containers on. The way Docker suggests securing the remote api is by using tls client certificates signed

 by  a trusted CA used to start up the docker api (<a href="http://docs.docker.io/examples/https/">http://docs.docker.io/examples/https/</a>). This presents a problem for Heat because certificates would have to be added to Heat for each Docker resource (or

 per stack) in order to have secure communication, which creates a scalability problem, and requires Heat to store customer secrets.</div>

<div><br>

</div>

<div>The solution I propose to this problem is to integrate docker with software config, which would allow the Docker api running on a compute instance to listen on an unix socket while still being able to communicate with the Heat engine. I have created a

 blueprint to capture this proposal:</div>

<div><br>

</div>

<div><a href="https://blueprints.launchpad.net/heat/+spec/software-config-docker">https://blueprints.launchpad.net/heat/+spec/software-config-docker</a></div>

<div><br>

</div>

<div>Any input on this proposal is welcome.</div>

<div><br>

</div>

<div>Thanks everyone!</div>

<div>-Andrew Plunk</div>

</body>

</html>