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.math...@gmail.com> wrote: > On Wed, Feb 1, 2017 at 6:59 AM Thomas Goirand <z...@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-requ...@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-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