<div dir="ltr"><div><div><div>Today the '-admin' version almost able to fully passing on tempest:<br><a href="http://logs.openstack.org/91/428091/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/9e4f5e6/logs/stackviz/#/stdin">http://logs.openstack.org/91/428091/1/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/9e4f5e6/logs/stackviz/#/stdin</a><br><br><a href="https://review.openstack.org/#/c/428091/">https://review.openstack.org/#/c/428091/</a> (Without the port merge,  but it could be the next step )<br><br>At the first looks does not seams to be impossible, to have a 'keystone-wsgi' entry which good<br>enough to pass on tempest and possible on all real user use case as well,<br> even tough it might not be 100% bug compatible with the old version, and <br>It requires some tweaks on the routes on the keystone side.<br><br></div>Would be nice to have a a wsgi entry in the keystone repository<br>which is also passing on at least test_user_update_own_password, and advertised as `the merged` entry by<br></div><div>the keystone project.<br></div><div><br></div><br></div><div><div><br><div><br><br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 1, 2017 at 4:35 PM, Dolph Mathews <span dir="ltr"><<a href="mailto:dolph.mathews@gmail.com" target="_blank">dolph.mathews@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span class=""><div>On Wed, Feb 1, 2017 at 6:59 AM Thomas Goirand <<a href="mailto:zigo@debian.org" target="_blank">zigo@debian.org</a>> wrote:<br></div></span><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 02/01/2017 10:54 AM, Attila Fazekas wrote:<br class="m_-5001915727858963481gmail_msg">
> Hi all,<br class="m_-5001915727858963481gmail_msg">
><br class="m_-5001915727858963481gmail_msg">
> Typically we have two keystone service listening on two separate ports<br class="m_-5001915727858963481gmail_msg">
> 35357 and 5000.<br class="m_-5001915727858963481gmail_msg">
><br class="m_-5001915727858963481gmail_msg">
> Historically one of the port had limited functionality, but today I do<br class="m_-5001915727858963481gmail_msg">
> not see why we want<br class="m_-5001915727858963481gmail_msg">
> to have two separate service/port from the same code base for similar<br class="m_-5001915727858963481gmail_msg">
> purposes.<br class="m_-5001915727858963481gmail_msg"></blockquote><div><br></div></span><div>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.</div><div><br></div><div>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).<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br class="m_-5001915727858963481gmail_msg">
> Effective we use double amount of memory than it is really required,<br class="m_-5001915727858963481gmail_msg">
> because both port is served by completely different worker instances,<br class="m_-5001915727858963481gmail_msg">
> typically from the same physical server.<br class="m_-5001915727858963481gmail_msg">
><br class="m_-5001915727858963481gmail_msg">
> I wonder, would it be difficult to use only a single port or at least<br class="m_-5001915727858963481gmail_msg">
> the same pool of workers for all keystone(identity, auth..) purposes?<br class="m_-5001915727858963481gmail_msg">
><br class="m_-5001915727858963481gmail_msg">
> Best Regards,<br class="m_-5001915727858963481gmail_msg">
> Attila<br class="m_-5001915727858963481gmail_msg">
<br class="m_-5001915727858963481gmail_msg">
This has been discussed and agreed a long time ago, but nobody did the<br class="m_-5001915727858963481gmail_msg">
work.</blockquote><div><br></div></span><div>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.<br></div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Please do get rid of the 2nd port. And when you're at it, also get<br class="m_-5001915727858963481gmail_msg">
rid of the admin and internal endpoint in the service catalog.</blockquote><div><br></div></span><div>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).</div><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="m_-5001915727858963481gmail_msg">
Cheers,<br class="m_-5001915727858963481gmail_msg">
<br class="m_-5001915727858963481gmail_msg">
Thomas Goirand (zigo)<br class="m_-5001915727858963481gmail_msg">
<br class="m_-5001915727858963481gmail_msg">
<br class="m_-5001915727858963481gmail_msg">
______________________________<wbr>______________________________<wbr>______________<br class="m_-5001915727858963481gmail_msg">
OpenStack Development Mailing List (not for usage questions)<br class="m_-5001915727858963481gmail_msg">
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" class="m_-5001915727858963481gmail_msg" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br class="m_-5001915727858963481gmail_msg">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" class="m_-5001915727858963481gmail_msg" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br class="m_-5001915727858963481gmail_msg">
</blockquote></span></div></div><span class="HOEnZb"><font color="#888888"><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr">-Dolph</div></div>
</font></span><br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div>