Open Stack

Today the '-admin' version almost able to fully passing on tempest:
http://logs.openstack.org/91/428091/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/9e4f5e6/logs/stackviz/#/stdin

https://review.openstack.org/#/c/428091/ (Without the port merge,  but it
could be the next step )

At the first looks does not seams to be impossible, to have a
'keystone-wsgi' entry which good
enough to pass on tempest and possible on all real user use case as well,
even tough it might not be 100% bug compatible with the old version, and
It requires some tweaks on the routes on the keystone side.

Would be nice to have a a wsgi entry in the keystone repository
which is also passing on at least test_user_update_own_password, and
advertised as `the merged` entry by
the keystone project.






On Wed, Feb 1, 2017 at 4:35 PM, Dolph Mathews <dolph.mathews at gmail.com>
wrote:

> 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
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170202/b1914b73/attachment.html>