On Thu, Mar 10, 2016 at 2:29 PM, Xav Paice <[email protected]> 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.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
