yahoo-eng-team team mailing list archive

[Jamie Lennox <jamielennox@xxxxxxxxxx>]

Public bug reported:

If a configurer fails to set a public_endpoint or admin_endpoint in the
keystone.conf file then it defaults to http://localhost:%(port)d this is
a relatively common thing to forget as no-one has been doing much
version discovery - or at least not following the links once done.

This is a dumb default as for almost all situations the endpoint is
wrong.

It also has the problem that regardless of whether you arrived at the
page via the 'public' endpoint or the 'private' endpoint you will see
the same path to consume the service so using the admin URL was
essentially useless.

A recently written proposal (mine):
https://wiki.openstack.org/wiki/VersionDiscovery advocates that
discovery services should make this URL relative to stop this confusion
however that is unlikely to be acceptable for existing clients.


Thus at the very least we should change the default value to be relative to the URL with which the user accessed the site as it will always be available from this same source. (or configurable away)

** Affects: keystone
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1288009

Title:
  Default discovery endpoints create an unusable service

Status in OpenStack Identity (Keystone):
  New

Bug description:
  If a configurer fails to set a public_endpoint or admin_endpoint in
  the keystone.conf file then it defaults to http://localhost:%(port)d
  this is a relatively common thing to forget as no-one has been doing
  much version discovery - or at least not following the links once
  done.

  This is a dumb default as for almost all situations the endpoint is
  wrong.

  It also has the problem that regardless of whether you arrived at the
  page via the 'public' endpoint or the 'private' endpoint you will see
  the same path to consume the service so using the admin URL was
  essentially useless.

  A recently written proposal (mine):
  https://wiki.openstack.org/wiki/VersionDiscovery advocates that
  discovery services should make this URL relative to stop this
  confusion however that is unlikely to be acceptable for existing
  clients.

  
  Thus at the very least we should change the default value to be relative to the URL with which the user accessed the site as it will always be available from this same source. (or configurable away)

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1288009/+subscriptions