Open Stack

We at Nectar are in the same boat as Mike. Our use-case is a little
bit more about geo-distributed operations though - our Cells are in
different States around the country, so the local glance-apis are
particularly important for caching popular images close to the
nova-computes. We consider these glance-apis as part of the underlying
cloud infra rather than user-facing, so I think we'd prefer not to see
them in the service-catalog returned to users either... is there going
to be a (standard) way to hide them?

On 28 April 2017 at 09:15, Mike Dorman <mdorman at godaddy.com> wrote:
> We make extensive use of the [glance]/api_servers list.  We configure that on hypervisors to direct them to Glance servers which are more “local” network-wise (in order to reduce network traffic across security zones/firewalls/etc.)  This way nova-compute can fail over in case one of the Glance servers in the list is down, without putting them behind a load balancer.  We also don’t run https for these “internal” Glance calls, to save the overhead when transferring images.
>
> End-user calls to Glance DO go through a real load balancer and then are distributed out to the Glance servers on the backend.  From the end-user’s perspective, I totally agree there should be one, and only one URL.
>
> However, we would be disappointed to see the change you’re suggesting implemented.  We would lose the redundancy we get now by providing a list.  Or we would have to shunt all the calls through the user-facing endpoint, which would generate a lot of extra traffic (in places where we don’t want it) for image transfers.
>
> Thanks,
> Mike
>
>
>
> On 4/27/17, 4:02 PM, "Matt Riedemann" <mriedemos at gmail.com> wrote:
>
>     On 4/27/2017 4:52 PM, Eric Fried wrote:
>     > Y'all-
>     >
>     >   TL;DR: Does glance ever really need/use multiple endpoint URLs?
>     >
>     >   I'm working on bp use-service-catalog-for-endpoints[1], which intends
>     > to deprecate disparate conf options in various groups, and centralize
>     > acquisition of service endpoint URLs.  The idea is to introduce
>     > nova.utils.get_service_url(group) -- note singular 'url'.
>     >
>     >   One affected conf option is [glance]api_servers[2], which currently
>     > accepts a *list* of endpoint URLs.  The new API will only ever return *one*.
>     >
>     >   Thus, as planned, this blueprint will have the side effect of
>     > deprecating support for multiple glance endpoint URLs in Pike, and
>     > removing said support in Queens.
>     >
>     >   Some have asserted that there should only ever be one endpoint URL for
>     > a given service_type/interface combo[3].  I'm fine with that - it
>     > simplifies things quite a bit for the bp impl - but wanted to make sure
>     > there were no loudly-dissenting opinions before we get too far down this
>     > path.
>     >
>     > [1]
>     > https://blueprints.launchpad.net/nova/+spec/use-service-catalog-for-endpoints
>     > [2]
>     > https://github.com/openstack/nova/blob/7e7bdb198ed6412273e22dea72e37a6371fce8bd/nova/conf/glance.py#L27-L37
>     > [3]
>     > http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2017-04-27.log.html#t2017-04-27T20:38:29
>     >
>     > Thanks,
>     > Eric Fried (efried)
>     > .
>     >
>     > __________________________________________________________________________
>     > 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
>     >
>
>     +openstack-operators
>
>     --
>
>     Thanks,
>
>     Matt
>
>     __________________________________________________________________________
>     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
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



-- 
Cheers,
~Blairo