<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Mar 10, 2016 at 2:29 PM, Xav Paice <span dir="ltr"><<a href="mailto:xavpaice@gmail.com" target="_blank">xavpaice@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">Remember that we're talking here about all the projects, not just keystone.  I can't see that we'll move everything to subpaths at any time soon, and until that point we still need to at least make an informal agreement as to which 'default' port to expect services to live on.  Even if that's just for devstack until we get to the subpaths nirvana.<div><br></div><div>It's great that services are looking to the catalog for the locations of endpoints - but unless we're comfortable that every cloud is going to select a bunch of (different) random ports for each service until such time as subpaths are a reality, then we need to communicate in some way.</div><div><br></div><div>I don't see the need for a full web service environment in devstack - all that would really do is limit the choices that ops can make about the best web server/wsgi service.  If people concentrate efforts on apache/mod_wsgi, those wanting to use uwsgi, nginx, gunicorn, etc are going to have a hard road.  There's valid choices for using other web services (in fact, there's some massive arguments against mod_wsgi).</div><div><br></div><div>A simple list is probably enough for a quick ref - it's not a massive blocker if two projects slip up and get the same port number, and yes if they're doing subpaths and not ports then great.  Doesn't need to be a gate item.  But it helps communications if we have a list, even if that's temporary.</div><div><br></div><div>How about a 'default settings' list for a 'standard' reference environment?  When ops deviate from the list (and we will) that's a concious decision we make.  Should we say that the ports used in devstack are the default list, and if a new project wants to get into devstack then they need to choose a port not in use (or subpaths)?</div></div><div class="gmail_extra"><br></div></blockquote><div><br></div><div>+1. This is how we would set the default values in things like the puppet modules. It's a not a good experience if two puppet modules out of the box collide with each other. As you said operators can make whatever choices they want later, but lets make it a conscious decision to deviate from the standard list rather than presenting someone standing up OpenStack a port collision and leaving them to search for something open to use.</div></div></div></div>