<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 15, 2013 at 10:44 AM, Stephen Gran <span dir="ltr"><<a href="mailto:stephen.gran@theguardian.com" target="_blank">stephen.gran@theguardian.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<br></div>
Surely those are local deployment policy decisions that shouldn't affect the development of capabilities in heat itself, right?  If a deployer does not want one heat deployment to be able to reach some endpoints, they'll set up a local heat that can reach those endpoints and deploy their stack through that one, right?<br>

<br></blockquote><div><br></div><div> You are right. At the same time heat feature should not enforce some specific deployment requirements to other openstack components especially taking into account different security considerations. I am trying to rise a concern about possible security implications of that particular approach of using exposed openstack APIs and bring security requirements to the table for discussion. Probably this will help to design better solution for heat to heat or DC to DC communication if it exists. I hope that there is a room for discussion and it is possible to influence on the final design and implementation. I really want this feature to be flexible and useful for most of OpenStack deployments rather then for some specific deployment case.</div>
<div><br></div><div><br></div></div><div><br></div>-- <br>Georgy Okrokvertskhov<br>
Technical Program Manager,<br>Cloud and Infrastructure Services,<br>
Mirantis<br>
<a href="http://www.mirantis.com/" target="_blank">http://www.mirantis.com</a><br>
Tel. +1 650 963 9828<br>
Mob. +1 650 996 3284<br>
</div></div>