Open Stack

On Wed, Feb 1, 2017 at 6:59 AM Thomas Goirand <zigo at debian.org> wrote:

> On 02/01/2017 10:54 AM, Attila Fazekas wrote:
> > Hi all,
> >
> > Typically we have two keystone service listening on two separate ports
> > 35357 and 5000.
> >
> > Historically one of the port had limited functionality, but today I do
> > not see why we want
> > to have two separate service/port from the same code base for similar
> > purposes.
>

If you're running v2, you do need two endpoints (admin and public; keystone
does not really have a use case for an internal endpoint). The specific
port numbers don't particularly matter (other than 35357 is conveniently
registered with IANA) and should not be hardcoded or assumed by clients
(and are not, AFAIK). In the case of v2, it is effectively a different
service running on each port; there's at least one unfortunately subtle
difference in behavior between admin and public.

If you're *only* running v3, you can run a single process and put the same
endpoint URL in the service catalog, for both the admin and public
endpoint. Arbitrary ports don't matter (so just use 443).


> >
> > Effective we use double amount of memory than it is really required,
> > because both port is served by completely different worker instances,
> > typically from the same physical server.
> >
> > I wonder, would it be difficult to use only a single port or at least
> > the same pool of workers for all keystone(identity, auth..) purposes?
> >
> > Best Regards,
> > Attila
>
> This has been discussed and agreed a long time ago, but nobody did the
> work.


A lot of work has gone into freeing keystone from having to run on two
ports (Adam Young, in particular, deserves a ton of credit here). You just
need to consume that operational flexibility.


> Please do get rid of the 2nd port. And when you're at it, also get
> rid of the admin and internal endpoint in the service catalog.


v3 has never presumed anything other than a public endpoint. Admin and
internal are strictly optional and only exist for backwards compatibility
with v2 (so, just use v3).


>


> Cheers,
>
> Thomas Goirand (zigo)
>
>
> __________________________________________________________________________
> 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
>
-- 
-Dolph
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170201/d2f14cd3/attachment.html>