<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 3, 2015 at 8: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:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style: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></blockquote><div><br></div><div>I got some additional info from operators I wanted to bring here. </div><div><br></div><div>The publicURL has to be super denial-of-service proof as these are the published, easily found URLs.</div><div><br></div><div>All URLs might have regional requirements around data privacy and where the data is eventually housed, such as EU requirements for some products. The data privacy requirement might mean a requirement for completely separate networks.</div><div><br></div><div>Going through a proxy breaks what those promises are to customers - that they are on a separate network. Plus a proxy may not be performant enough for possible denial of service attacks. </div><div><br></div><div>Also for legal reasons some URLs are exposed internal only. So this is in addition to the billing use case for internalURL, there may also be a legal/contractual requirement.</div><div><br></div><div>Providers may need to decrypt data to determine the actual URL, so while processing and redirection can happen on network devices, audits and debugging mean the providers/ops need the actual URL at some point. I don't think the design prevents that but wanted to bring it up.</div><div><br></div><div>Another use case I hadn't heard yet is if a public URL is DDoSed, you can have a second URL on internal-only systems that can't be attacked from the outside world. So it's a publicURL in that you can access the service, but an internal-only URL so we can protect.</div><div><br></div><div>Some of the regional/legal requirements could be solved with split horizon DNS - the ability for a DNS-server to give a different answer to a query based on the source of the query - but if a provider doesn't already have that in their network gear they'd have to invest, perhaps heavily, to get it.</div><div><br></div><div>All of these use cases don't require that a deployer publish an internalURL or adminURL in the service catalog, I realize this. It does provide explanations for possible other endpoints you may need to tell people about when they query a service.</div><div>Hope that helps.</div><div>Anne</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<span class=""><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><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Anne Gentle</div><div>Rackspace</div><div>Principal Engineer</div><div><a href="http://www.justwriteclick.com" target="_blank">www.justwriteclick.com</a></div></div></div>
</div></div>