Open Stack

On Thu, Mar 10, 2016 at 2:29 PM, Xav Paice <xavpaice at gmail.com> wrote:

> 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.
>
> 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.
>
> 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).
>
> 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.
>
> 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)?
>
>
+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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160310/7e564c8b/attachment.html>