Open Stack

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.

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.

	-Sean

-- 
Sean Dague
http://dague.net