Open Stack

Hi,

I recalled one issue during using endpoint structure in public cloud
based on OpenStack.

Currently each service listens on its own port, the format of the endpoint
is like: service-specific ports, e.g., https://cloud.com:1234/v2

If the end user want to access Nova/Cinder/Neutron service endpoint
directly, for example using curl or other tools, then these ports 8774, 8776, 9696 have to be
exposed to the end user. Then you have to open these ports
in many devices if you want to provide these services in the public cloud directly to
end user. The more services are added to the public cloud, the more have to be
configured in these devices for security purpose.

>From public cloud point of view, the port 80 will be opened by default, but if you have
to open so many non-80 ports, it brings additional work and challenge to manage these ports,
especially in firewalls, anti-DDoS, etc.

So I think that it would be better to use sub-domain or path to expose different
services end-point. 

A. subdomains, e.g., https://service.cloud.com/v2
 B. paths, e.g., https://cloud.com/service/v2 

Best Regards
Chaoyi Huang (joehuang)

________________________________________
From: Brian Curtin [brian at python.org]
Sent: 19 October 2016 23:32
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] Endpoint structure: a free-for-all

I'm currently facing what looks more and more like an impossible
problem in determining the root of each service on a given cloud. It
is apparently a free-for-all in how endpoints can be structured, and I
think we're out of ways to approach it that catch all of the ways that
all people can think of.

In openstacksdk, we can no longer use the service catalog for
determining each service's endpoints. Among other things, this is due
to a combination of some versions of some services not actually being
listed, and with things heading the direction of version-less services
anyway. Recently we changed to using the service catalog as a pointer
to where services live and then try to find the root of that service
by stripping the path down and making some extra requests on startup
to find what's offered. Despite a few initial snags, this now works
reasonably well in a majority of cases.

We have seen endpoints structured in the following ways:
 A. subdomains, e.g., https://service.cloud.com/v2
 B. paths, e.g., https://cloud.com/service/v2 (sometimes there are
more paths in between the root and /service/)
 C. service-specific ports, e.g., https://cloud.com:1234/v2
 D. both A and B plus ports

Within all of these, we can find the root of the given service just
fine. We split the path and build successively longer paths starting
from the root. In the above examples, we need to hit the path just
short of the /v2, so in B it actually takes two requests as we'd make
one to cloud.com which fails, but then a second one to
cloud.com/service gives us what we need.

However, another case came up: the root of all endpoints is itself
another service. That makes it look like this:

 E. https://cloud.com:9999/service/v2
 F. https://cloud.com:9999/otherservice

In this case, https://cloud.com:9999 is keystone, so trying to get E's
base by going from the root and outward will give me a versions
response I can parse properly, but it points to keystone. We then end
up building requests for 'service' that go to keystone endpoints and
end up failing. We're doing this using itertools.accumulate on the
path fragments, so you might think 'just throw it through
`reversed()`' and go the other way. If we do that, we'll also get a
versions response that we can parse, but it's the v2 specific info,
not all available versions.

So now that we can't reliably go from the left, and we definitely
can't go from the right, how about the middle?

This sounds ridiculous, and if it sounds familiar it's because they
devise a "middle out" algorithm on the show Silicon Valley, but in
most cases it'd actually work. In E above, it'd be fine. However,
depending on the number of path fragments and which direction we chose
to move first, we'd sometimes hit either a version-specific response
or another service's response, so it's not reliable.

Ultimately, I would like to know how something like this can be solved.

1. Is there any reliable, functional, and accurate programmatic way to
get the versions and endpoints that all services on a cloud offer?

2. Are there any guidelines, rules, expectations, or other
documentation on how services can be installed and their endpoints
structured that are helpful to people build apps that use them, not in
those trying to install and operate them? I've looked around a few
times and found nothing useful. A lot of what I've found has
referenced suggestions for operators setting them up behind various
load balancing tools.

3. If 1 and 2 won't actually help me solve this, do you have any other
suggestions that will? We already go left, right, and middle of each
URI, so I'm out of directions to go, and we can't go back to the
service catalog.

Thanks,

Brian

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev