[openstack-dev] [all][zaqar][cloudkitty] Default ports list

Tim Bell Tim.Bell at cern.ch
Thu Mar 10 12:11:32 UTC 2016



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 :-)

Tim





On Wed, Mar 9, 2016 at 3:30 PM, Xav Paice <xavpaice at gmail.com<mailto:xavpaice at gmail.com>> wrote:
From an ops point of view, this would be extremely helpful information to share with various teams around an organization.  Even a simple wiki page would be great.

On 10 March 2016 at 10:35, Fei Long Wang <feilong at catalyst.net.nz<mailto:feilong at catalyst.net.nz>> wrote:
Hi all,

Yesterday I just found cloudkitty is using the same default port (8888) which is used by Zaqar now. So I'm wondering if there is any rule/policy for those new services need to be aware. I googled but can't find anything about this. The only link I can find is http://docs.openstack.org/liberty/config-reference/content/firewalls-default-ports.html. So my question is should we document the default ports list on an official place given the big tent mode? Thanks.

--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--------------------------------------------------------------------------
Senior Cloud Software Engineer
Tel: +64-48032246<tel:%2B64-48032246>
Email: flwang at catalyst.net.nz<mailto:flwang at catalyst.net.nz>
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--------------------------------------------------------------------------


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<mailto:OpenStack-dev-request at lists.openstack.org?subject:unsubscribe>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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


More information about the OpenStack-dev mailing list