[openstack-dev] [nova][glance][keystone] Philosophy of the service catalog (was: Who needs multiple api_servers?)

Mathieu Gagné mgagne at calavera.ca
Wed May 10 21:36:33 UTC 2017

I didn't attend the LDT session but agree with the needs and
conclusions mentioned here by Mike Dorman.

It's important for us to be able to control the data path of our
internal servers and overriding the URLs is the method we are
currently using. You could do split view DNS but we prefer being
explicit (different URLs) over implicit. It ends up being much easier
for new comers to debug as they don't have to know about split view

On Wed, May 10, 2017 at 2:29 PM, Mike Dorman <mdorman at godaddy.com> wrote:
> After discussion in the Large Deployments Team session this morning, we
> wanted to follow up on the earlier thread [1,2] about overriding endpoint
> URLs.
> That topic is exposing an underlying implication about the purpose of the
> service catalog.  The LDT position is that the service catalog should be for
> end user clients to do endpoint discovery.  While it can also be used for
> discovery by other OpenStack services, we desire to maintain the ability to
> override (like that which was discussed in the previous thread about
> Glance.)  In addition to the Glance to nova-compute use case, the feedback
> during the LDT session surfaced potential use cases for other services.
> The point to raise here from LDT is that we would like to avoid a trend
> toward services *only* supporting discovery via the service catalog, with no
> ability to override in config.  I.e., we want to maintain the
> endpoint_override (and similar) options.
> Thanks!
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2017-April/116028.html /
> http://lists.openstack.org/pipermail/openstack-operators/2017-April/013272.html
> [2]
> http://lists.openstack.org/pipermail/openstack-dev/2017-May/thread.html#116133
> /
> http://lists.openstack.org/pipermail/openstack-operators/2017-May/thread.html#13309
> __________________________________________________________________________
> 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

More information about the OpenStack-dev mailing list