Open Stack

On Thu, Mar 10, 2016 at 4:43 AM, Sean Dague <sean at dague.net> wrote:

> On 03/10/2016 07:11 AM, Tim Bell wrote:
> >
> >
> > From: Sylvain Bauza <sbauza at redhat.com <mailto:sbauza at redhat.com>>
> > Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org
> > <mailto:openstack-dev at lists.openstack.org>>
> > Date: Thursday 10 March 2016 at 10:04
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev at lists.openstack.org
> > <mailto:openstack-dev at lists.openstack.org>>
> > Subject: Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list
> >
> >
> >
> >     Le 09/03/2016 23:41, Matt Fischer a écrit :
> >>     This is not the first time. Monasca and Murano had a collision
> >>     too[1]. When this happens the changes trickle down into automation
> >>     tools also and complicates things.
> >>
> >>     [1] https://bugs.launchpad.net/murano/+bug/1505785
> >
> >
> >     IMHO, all that info has to be standardized in the Service Catalog.
> >     That's where endpoint informations can be found for a specific
> >     service type and that's the basement for cross-project communication.
> >
> >     FWIW, there is one cross-project spec trying to clean-up the
> >     per-project bits that are not common
> >
> https://github.com/openstack/openstack-specs/blob/master/specs/service-catalog.rst
> >
> >     I'm torn between 2 opinions :
> >      - either we consider that all those endpoints are (or should be -
> >     for those which aren't) manageable thru config options, and thus
> >     that's not a problem we should solve. Any operator can then modify
> >     the ports to make sure that two conflicting big-tent projects can
> >     work together.
> >      - or, we say that it can be a concern for interoperability, and
> >     then we should somehow ensure that all projects can work together.
> >     Then, a documentation link isn't enough IMHO, we should rather test
> >     that.
> >
> >
> > If we can make it so that there are reasonable port commonalities
> > between OpenStack clouds, this would be good. Clearly, the service
> > catalog is the master so I don’t think there is an interoperability
> > concern but having each of the projects using different ports would
> > simplify some of the smaller configurations with multiple services on a
> > single box.
> >
> > This does assume that there are less big tent projects than available
> > TCP/IP ports :-)
>
> These are HTTP services. They really shoudn't be claiming new ports,
> they should be running on a real webserver on 80 or 443.
>
>
100% Correct. Services should be looking to exist on the proper HTTP ports
instead of custom ports. The "custom" ports used in the past are legacy and
we should encourage moving away from that. The only IANA assigned port is
the keystone 35357, and that comes with a host of other issues (Linux
Ephemeral Port range); we are actively working to get keystone moved to
port 80 or 443 as the default/recommended method. There are a number of
deployers/cloud operators that already run all services on 443 (using TLS
and apache/nginx to front the service).


> There is some legacy there with the original services that we are
> churning through. It would be nice if new services *started* with
> staying on wsgi only, and stopped grabbing random ports.


++
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160310/bc3fd664/attachment.html>