Open Stack

On Thu, Dec 3, 2015 at 8:14 AM, Sean Dague <sean at 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
Anne Gentle
Rackspace
Principal Engineer
www.justwriteclick.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20151216/7fda0841/attachment.html>