<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">There is two approaches.<br>
<br>
1) You make public endpoints and horizon public. White IP,
resolvable FQDN for endpoints, etc. <br>
2) You hide endpoints from user (boo... no api, no automation),
but expose horizon.<br>
<br>
Second case: horizon will sits as middleware between 'internal'
networks where endpoints live, and outer world. Horizon may works
fine even all endpoints are hidden from user. But wsgi part of the
Horizon should be able to access endpoints.<br>
<br>
<br>
On 09/30/2015 04:14 PM, Davíð Örn Jóhannsson wrote:<br>
</div>
<blockquote cite="mid:1443618886868.31541@siminn.is" type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style type="text/css" style="display:none"><!-- p { margin-top: 0px; margin-bottom: 0px; }--></style>
<div>I just recently joined a team in charge of implementing
OpenStack deployment which I'm trying to grasp the design of.</div>
<div><br>
</div>
<div>One problem I encountered is that the openstack environment
is on a pretty closed network and I need to use ssh </div>
<div>tunnelling to be able to access horizon, so I started to look
into fronting the service with a reverse proxy </div>
<div>(making it available throug, horizon.example.com/horizon),
then I noticed the horizon UI needs to contact the </div>
<div>Identity service, which I also fronted with a reverse proxy
(identity.example.com:5000/v2.0) and configured</div>
<div>OPENSTACK_HOST = identity.example.com in
/etc/openstack-dashboard/local_settings.py</div>
<div><br>
</div>
<div>The reverse proxy proxies requests to <a class="moz-txt-link-freetext" href="http://control1:5000">http://control1:5000</a> so
when the response is sent back from the api it includes </div>
<div><link href=<a class="moz-txt-link-rfc2396E" href="http://http://control1:5000/v2.0/">"http://http://control1:5000/v2.0/"</a>
rel="self"/> which the client has no network access to and a
possible solution</div>
<div>would be to edit the url in /etc/keystone/keystone.conf then
it dawned on me that we might have to re-think this design.</div>
<div><br>
</div>
<div>Possibly we are taking the wrong approach so I wanted to
reach out to get some opinions on this matter since I'm new </div>
<div>to the architecture of OpenStack and haven't yet totally
grasped how things are supposed to work together.<br>
</div>
<div><br>
</div>
<div>Regards, Davíd Johannsson<br>
</div>
<p><br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-operators mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a>
</pre>
</blockquote>
<br>
</body>
</html>