<div dir="ltr">We make use of http urls internally for services to talk to each other, but not for human users. All our human users should be using https public url. We don't actually utilize the internalURL framework, instead we use /etc/hosts entries to change the domain resolution of our publicURL entries, and use other config file controls to reflect http vs https.<div><br></div><div>Partly this is because we don't want to advertise internal IP addresses in the catalog. Partly this is because we do not want to advertise an http link that a client might accidentally use and pass credentials in the clear over the Internet.</div><div><br></div><div>I believe we would be perfectly happy to do away with adminURL and internalURL. It'd certainly reduce our per-site configuration entries, and reduce confusion around what purpose these entries serve.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br></div><div dir="ltr">- jlk</div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Dec 3, 2015 at 6:14 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">For folks that don't know, we've got an effort under way to look at some<br>
of what's happened with the service catalog, how it's organically grown,<br>
and do some pruning and tuning to make sure it's going to support what<br>
we want to do with OpenStack for the next 5 years (wiki page to dive<br>
deeper here - <a href="https://wiki.openstack.org/wiki/ServiceCatalogTNG" rel="noreferrer" target="_blank">https://wiki.openstack.org/wiki/ServiceCatalogTNG</a>).<br>
<br>
One of the early Open Questions is about urls. Today there is a<br>
completely free form field to specify urls, and there are conventions<br>
about having publicURL, internalURL, adminURL. These are, however, only<br>
conventions.<br>
<br>
The only project that's ever really used adminURL has been Keystone, so<br>
that's something we feel we can phase out in new representations.<br>
<br>
The real question / concern is around public vs. internal. And something<br>
we'd love feedback from people on.<br>
<br>
When this was brought up in Tokyo the answer we got was that internal<br>
URL was important because:<br>
<br>
* users trusted it to mean "I won't get changed for bandwidth"<br>
* it is often http instead of https, which provides a 20% performance<br>
gain for transfering large amounts of data (i.e. glance images)<br>
<br>
The question is, how hard would it be for sites to be configured so that<br>
internal routing is used whenever possible? Or is this a concept we need<br>
to formalize and make user applications always need to make the decision<br>
about which interface they should access?<br>
<span class="HOEnZb"><font color="#888888"><br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
</font></span></blockquote></div><br></div>