[openstack-dev] openstack vs. well known ports

Discussion:

Sean Dague

2013-03-15 18:27:02 UTC

We're on attempt 3 or 4 to turn on swift in devstack by default, but one
of the issues we keep running into is the fact that the range of ports
that swift defaults to: 601x, is also the range of ports the X server
likes to use. This could be for a local X server, or X forwarding if you
enabled that in your ssh sessions.

In a highly optimized swift environment, it's probably not an issue. But
in an environment where the physical resources are being used for other
things, the fact that we colide with something like X seems problematic.

Has there been any investigation by anyone going to IANA to get some
ports registered for OpenStack projects? Picking ones at random has
managed not to completely burn us up to this point, but it seems like it
would be safer to get some known ones reserved.

-Sean

--
Sean Dague
IBM Linux Technology Center
email: ***@linux.vnet.ibm.com
alt-email: ***@us.ibm.com

Jeremy Stanley

2013-03-15 18:48:58 UTC

Permalink

On 2013-03-15 14:27:02 -0400 (-0400), Sean Dague wrote:
[...]

Post by Sean Dague
Has there been any investigation by anyone going to IANA to get some
ports registered for OpenStack projects? Picking ones at random has
managed not to completely burn us up to this point, but it seems
like it would be safer to get some known ones reserved.

Well, there's 35357/tcp listed with IANA as "openstack-id (OpenStack
ID Service)" registered by Ziad Sawalha with Rackspace Hosting on
2011-08-15, if that helps.

--
Jeremy Stanley

Thierry Carrez

2013-03-18 10:56:15 UTC

Permalink

Post by Jeremy Stanley
[...]

Well, there's 35357/tcp listed with IANA as "openstack-id (OpenStack
ID Service)" registered by Ziad Sawalha with Rackspace Hosting on
2011-08-15, if that helps.

A bit of historic context:

http://www.gossamer-threads.com/lists/openstack/dev/451
http://www.gossamer-threads.com/lists/openstack/dev/3153
http://www.gossamer-threads.com/lists/openstack/dev/14992

--
Thierry Carrez (ttx)
Release Manager, OpenStack

Jesse Pretorius

2013-03-18 17:23:26 UTC

Permalink

I'm very much in favour of any public endpoints being served through ports
80 & 443, with the API URI's being different to differentiate them (ie
http://hostname/auth/v2 for keystone, http://hostname/glance/v2 for glance,
etc). This allows the use of many multi-homing solutions based on the URI
to direct the requests to the right back-end server if one is using such a
tool.

Right now the overlap between API's makes this impossible to achieve,
resulting is us requiring the use of many, many ports. When clients are
accessing the API's from behind firewalls with strict rule sets or through
proxies this becomes quite a process to have to walk through with the
client.

As far as I see it - the API paths should be more descriptive and unique
and the ports should be configurable. This gives us the option to choose
how to deploy it into production.

Post by Thierry Carrez

Post by Jeremy Stanley
[...]

Well, there's 35357/tcp listed with IANA as "openstack-id (OpenStack
ID Service)" registered by Ziad Sawalha with Rackspace Hosting on
2011-08-15, if that helps.

http://www.gossamer-threads.com/lists/openstack/dev/451
http://www.gossamer-threads.com/lists/openstack/dev/3153
http://www.gossamer-threads.com/lists/openstack/dev/14992
--
Thierry Carrez (ttx)
Release Manager, OpenStack
_______________________________________________
OpenStack-dev mailing list
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Jesse Pretorius
mobile: +27 83 680 5492
email: ***@gmail.com
skype: jesse.pretorius

Dolph Mathews

2013-03-21 14:46:13 UTC

Permalink

I prefer ayoung's approach to this same issue, documented here:

https://wiki.openstack.org/wiki/URLs

The service "types" (identity, image, compute, etc) are used in the URL's
to provide a consistent URL scheme.

-Dolph

Post by Jesse Pretorius
I'm very much in favour of any public endpoints being served through ports
80 & 443, with the API URI's being different to differentiate them (ie
http://hostname/auth/v2 for keystone, http://hostname/glance/v2 for
glance, etc). This allows the use of many multi-homing solutions based on
the URI to direct the requests to the right back-end server if one is using
such a tool.
Right now the overlap between API's makes this impossible to achieve,
resulting is us requiring the use of many, many ports. When clients are
accessing the API's from behind firewalls with strict rule sets or through
proxies this becomes quite a process to have to walk through with the
client.
As far as I see it - the API paths should be more descriptive and unique
and the ports should be configurable. This gives us the option to choose
how to deploy it into production.

Post by Thierry Carrez

Post by Jeremy Stanley
[...]

Well, there's 35357/tcp listed with IANA as "openstack-id (OpenStack
ID Service)" registered by Ziad Sawalha with Rackspace Hosting on
2011-08-15, if that helps.

--
Jesse Pretorius
mobile: +27 83 680 5492
skype: jesse.pretorius
_______________________________________________
OpenStack-dev mailing list
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Nathanael Burton

2013-03-22 02:03:42 UTC

Permalink

Post by Dolph Mathews
https://wiki.openstack.org/wiki/URLs
The service "types" (identity, image, compute, etc) are used in the URL's
to provide a consistent URL scheme.
-Dolph

+1. We should work on a way to have this implemented in devstack so we
start testing it and actually getting people to use this scheme.

Jesse Pretorius

2013-03-22 09:44:32 UTC

Permalink

Post by Dolph Mathews
https://wiki.openstack.org/wiki/URLs
The service "types" (identity, image, compute, etc) are used in the URL's
to provide a consistent URL scheme.
-Dolph
On Mon, Mar 18, 2013 at 12:23 PM, Jesse Pretorius <

Post by Jesse Pretorius
I'm very much in favour of any public endpoints being served through
ports 80 & 443, with the API URI's being different to differentiate them
(ie http://hostname/auth/v2 for keystone, http://hostname/glance/v2 for
glance, etc). This allows the use of many multi-homing solutions based on
the URI to direct the requests to the right back-end server if one is using
such a tool.
Right now the overlap between API's makes this impossible to achieve,
resulting is us requiring the use of many, many ports. When clients are
accessing the API's from behind firewalls with strict rule sets or through
proxies this becomes quite a process to have to walk through with the
client.
As far as I see it - the API paths should be more descriptive and unique
and the ports should be configurable. This gives us the option to choose
how to deploy it into production.

Post by Thierry Carrez

Post by Jeremy Stanley
[...]

Well, there's 35357/tcp listed with IANA as "openstack-id (OpenStack
ID Service)" registered by Ziad Sawalha with Rackspace Hosting on
2011-08-15, if that helps.

_______________________________________________
OpenStack-dev mailing list
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Jesse Pretorius
mobile: +27 83 680 5492
email: ***@gmail.com
skype: jesse.pretorius