<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">Le 09/03/2016 23:41, Matt Fischer a
écrit :<br>
</div>
<blockquote
cite="mid:CAHr1CO9UBvEQ_ywzuqjFX94o7yxv0V-2i2=mWO1WOHVRGUJXiQ@mail.gmail.com"
type="cite">
<div dir="ltr">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.
<div><br>
</div>
<div>[1] <a moz-do-not-send="true"
href="https://bugs.launchpad.net/murano/+bug/1505785">https://bugs.launchpad.net/murano/+bug/1505785</a><br>
</div>
</div>
</blockquote>
<br>
<br>
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.<br>
<br>
FWIW, there is one cross-project spec trying to clean-up the
per-project bits that are not common
<a class="moz-txt-link-freetext" href="https://github.com/openstack/openstack-specs/blob/master/specs/service-catalog.rst">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 -
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.<br>
- 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.<br>
<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAHr1CO9UBvEQ_ywzuqjFX94o7yxv0V-2i2=mWO1WOHVRGUJXiQ@mail.gmail.com"
type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Mar 9, 2016 at 3:30 PM, Xav
Paice <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:xavpaice@gmail.com" target="_blank">xavpaice@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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.</div>
<div class="HOEnZb">
<div class="h5">
<div class="gmail_extra"><br>
<div class="gmail_quote">On 10 March 2016 at 10:35,
Fei Long Wang <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:feilong@catalyst.net.nz"
target="_blank">feilong@catalyst.net.nz</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi
all,<br>
<br>
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 <a moz-do-not-send="true"
href="http://docs.openstack.org/liberty/config-reference/content/firewalls-default-ports.html"
rel="noreferrer" target="_blank">http://docs.openstack.org/liberty/config-reference/content/firewalls-default-ports.html</a>.
So my question is should we document the default
ports list on an official place given the big tent
mode? Thanks.<br>
<br>
-- <br>
Cheers & Best regards,<br>
Fei Long Wang (王飞龙)<br>
--------------------------------------------------------------------------<br>
Senior Cloud Software Engineer<br>
Tel: <a moz-do-not-send="true"
href="tel:%2B64-48032246" value="+6448032246"
target="_blank">+64-48032246</a><br>
Email: <a moz-do-not-send="true"
href="mailto:flwang@catalyst.net.nz"
target="_blank">flwang@catalyst.net.nz</a><br>
Catalyst IT Limited<br>
Level 6, Catalyst House, 150 Willis Street,
Wellington<br>
--------------------------------------------------------------------------<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>