Sam-
Under the current design, you can provide a specific endpoint
(singular) via the `endpoint_override` conf option. Based on feedback
on this thread, we will also be keeping support for
`[glance]api_servers` for consumers who actually need to be able to
specify multiple endpoints. See latest spec proposal[1] for details.
[1] https://review.openstack.org/#/c/461481/
Thanks,
Eric (efried)
On 05/01/2017 12:20 PM, Sam Morrison wrote:
>
>> On 1 May 2017, at 4:24 pm, Sean McGinnis <sean.mcgin...@gmx.com> wrote:
>>
>> On Mon, May 01, 2017 at 10:17:43AM -0400, Matthew Treinish wrote:
>>>> ....
>>>
>>> I thought it was just nova too, but it turns out cinder has the same exact
>>> option as nova: (I hit this in my devstack patch trying to get glance
>>> deployed
>>> as a wsgi app)
>>>
>>> https://github.com/openstack/cinder/blob/d47eda3a3ba9971330b27beeeb471e2bc94575ca/cinder/common/config.py#L51-L55
>>>
>>> Although from what I can tell you don't have to set it and it will fallback
>>> to
>>> using the catalog, assuming you configured the catalog info for cinder:
>>>
>>> https://github.com/openstack/cinder/blob/19d07a1f394c905c23f109c1888c019da830b49e/cinder/image/glance.py#L117-L129
>>>
>>>
>>> -Matt Treinish
>>>
>>
>> FWIW, that came with the original fork out of Nova. I do not have any real
>> world data on whether that is used or not.
>
> Yes this is used in cinder.
>
> A lot of the projects you can set endpoints for them to use. This is
> extremely useful in a a large production Openstack install where you want to
> control the traffic.
>
> I can understand using the catalog in certain situations and feel it’s OK for
> that to be the default but please don’t prevent operators configuring it
> differently.
>
> Glance is the big one as you want to control the data flow efficiently but
> any service to service configuration should ideally be able to be manually
> configured.
>
> Cheers,
> Sam
>
>
>>
>>
>> __________________________________________________________________________
>> 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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
