On Thu, Dec 3, 2015 at 8:14 AM, Sean Dague <s...@dague.net> wrote: > For folks that don't know, we've got an effort under way to look at some > of what's happened with the service catalog, how it's organically grown, > and do some pruning and tuning to make sure it's going to support what > we want to do with OpenStack for the next 5 years (wiki page to dive > deeper here - https://wiki.openstack.org/wiki/ServiceCatalogTNG). > > One of the early Open Questions is about urls. Today there is a > completely free form field to specify urls, and there are conventions > about having publicURL, internalURL, adminURL. These are, however, only > conventions. > > The only project that's ever really used adminURL has been Keystone, so > that's something we feel we can phase out in new representations. > > The real question / concern is around public vs. internal. And something > we'd love feedback from people on. > > When this was brought up in Tokyo the answer we got was that internal > URL was important because: > > * users trusted it to mean "I won't get changed for bandwidth" > * it is often http instead of https, which provides a 20% performance > gain for transfering large amounts of data (i.e. glance images) > > The question is, how hard would it be for sites to be configured so that > internal routing is used whenever possible? Or is this a concept we need > to formalize and make user applications always need to make the decision > about which interface they should access? >
I got some additional info from operators I wanted to bring here. The publicURL has to be super denial-of-service proof as these are the published, easily found URLs. 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. 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. 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. 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. 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. 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. 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. Hope that helps. Anne > > -Sean > > -- > Sean Dague > http://dague.net > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > -- Anne Gentle Rackspace Principal Engineer www.justwriteclick.com
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
