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

[Mathieu Gagné]

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
DNS.
--
Mathieu


On Wed, May 10, 2017 at 2:29 PM, Mike Dorman  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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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

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

[Mike Dorman]

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev