<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 10, 2016 at 4:43 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 03/10/2016 07:11 AM, Tim Bell wrote:<br>
><br>
><br>
> From: Sylvain Bauza <<a href="mailto:sbauza@redhat.com">sbauza@redhat.com</a> <mailto:<a href="mailto:sbauza@redhat.com">sbauza@redhat.com</a>>><br>
<span class="">> Reply-To: "OpenStack Development Mailing List (not for usage questions)"<br>
> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
</span>> <mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>><br>
<span class="">> Date: Thursday 10 March 2016 at 10:04<br>
> To: "OpenStack Development Mailing List (not for usage questions)"<br>
> <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
</span>> <mailto:<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>>><br>
<div><div class="h5">> Subject: Re: [openstack-dev] [all][zaqar][cloudkitty] Default ports list<br>
><br>
><br>
><br>
> Le 09/03/2016 23:41, Matt Fischer a écrit :<br>
>> This is not the first time. Monasca and Murano had a collision<br>
>> too[1]. When this happens the changes trickle down into automation<br>
>> tools also and complicates things.<br>
>><br>
>> [1] <a href="https://bugs.launchpad.net/murano/+bug/1505785" rel="noreferrer" target="_blank">https://bugs.launchpad.net/murano/+bug/1505785</a><br>
><br>
><br>
> IMHO, all that info has to be standardized in the Service Catalog.<br>
> That's where endpoint informations can be found for a specific<br>
> service type and that's the basement for cross-project communication.<br>
><br>
> FWIW, there is one cross-project spec trying to clean-up the<br>
> per-project bits that are not common<br>
> <a href="https://github.com/openstack/openstack-specs/blob/master/specs/service-catalog.rst" rel="noreferrer" target="_blank">https://github.com/openstack/openstack-specs/blob/master/specs/service-catalog.rst</a><br>
><br>
> I'm torn between 2 opinions :<br>
> - either we consider that all those endpoints are (or should be -<br>
> for those which aren't) manageable thru config options, and thus<br>
> that's not a problem we should solve. Any operator can then modify<br>
> the ports to make sure that two conflicting big-tent projects can<br>
> work together.<br>
> - or, we say that it can be a concern for interoperability, and<br>
> then we should somehow ensure that all projects can work together.<br>
> Then, a documentation link isn't enough IMHO, we should rather test<br>
> that.<br>
><br>
><br>
> If we can make it so that there are reasonable port commonalities<br>
> between OpenStack clouds, this would be good. Clearly, the service<br>
> catalog is the master so I don’t think there is an interoperability<br>
> concern but having each of the projects using different ports would<br>
> simplify some of the smaller configurations with multiple services on a<br>
> single box.<br>
><br>
> This does assume that there are less big tent projects than available<br>
> TCP/IP ports :-)<br>
<br>
</div></div>These are HTTP services. They really shoudn't be claiming new ports,<br>
they should be running on a real webserver on 80 or 443.<br>
<br></blockquote><div><br></div><div>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).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
There is some legacy there with the original services that we are<br>
churning through. It would be nice if new services *started* with<br>
staying on wsgi only, and stopped grabbing random ports.</blockquote></div><br></div><div class="gmail_extra">++ </div></div>