Re: [Openstack] Default ports for services
Are you intending to use 35357 for the admin API or the service API? And what
port will be the default for the other one?
Thanks,
Ewan.
-Original Message-
From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net
[mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net]
On Behalf Of Ziad Sawalha
Sent: 16 August 2011 22:17
To: Mark Nottingham; ksan...@doubleclix.net
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Default ports for services
Keystone has been assigned TCP port 35357 by IANA.
We'll make that the default port.
Thanks,
Z
On 6/24/11 12:46 AM, Mark Nottingham m...@mnot.net wrote:
On 24/06/2011, at 3:31 PM, ksan...@doubleclix.net
ksan...@doubleclix.net wrote:
Couple of quick points:
a) Once the ports are fixed, we should register them with IANA as
well
known ports, which is the right
place.[http://www.iana.org/assignments/port-numbers]
That would be a friendly thing to do. See below for potential
conflicts.
b) I was going to suggest something like a ZooKeeper, may be the
service catalog serves that purpose.
c) Also, on the port numbers, I assume they will manifest as
universal
constants and/or a configuration file in a universally (or
intergalactically ;o)) known place.
Cheers
k/
Original Message
Subject: [Openstack] Default ports for services
From: Ziad Sawalha ziad.sawa...@rackspace.com
Date: Wed, June 22, 2011 9:52 pm
To: openstack@lists.launchpad.net openstack@lists.launchpad.net
Where's the best place to keep track of default ports for services
to
avoid conflicts? A wiki page on wiki.openstack.org?
We had a discussion while working on Keystone about default ports
for
OpenStack services (https://github.com/rackspace/keystone/issues/31).
We
want OpenStack to work 'out-of-the-box' without built-in port
conflicts,
so we should coordinate which ports new services start on.
At a minimum, we need that for Keystone as it isn't discoverable.
Other
services can be discovered using the service catalog that Keystone
returns as part of an auth request (Sample response below at end of
email).
Here's a list of ports we talked about on
https://github.com/rackspace/keystone/issues/31
80: Swift proxy server (swift/etc/proxy-server.conf-sample)
Already taken by HTTP, of course. If it's just an HTTP API, that's
fine.
6000: Swift object server
6001: Swift container server
6002: Swift account server
These are already registered for X-windows.
6080: Nova VNC proxy
free
8001: Nova direct API
taken by vcom-tunnel
8080: Swift proxy server (swift/bin/swift-proxy-server)
already HTTP alternate. Again, if it's an HTTP server (NOT http
proxy),
that's OK.
3306: MySQL
already registered to mysql
5672: AMPQ (RabbitMQ)
already AMPQ
9292: Glance API
ArmTech Daemon (whatever that is)
9191: Glance Registry
Sun AppSvr JPDA
5900...590?: qemu-system for VNC
5901-5909 are Unassigned, 5900 is already remote framebuffer.
We've moved Keystone to 5000/5001 (for Service and Admin API,
respectively).
commplex-main and commplex-link, respectively.
Sample Response with service catalog:
{
auth:{
token:{
id:asdasdasd-adsasdads-asdasdasd-adsadsasd,
expires:2010-11-01T03:32:15-05:00
},
serviceCatalog:{
nova:[
{
region:NorthAmerica,
publicURL:https://service1-public:9000/v1/blah-blah;,
internalURL:https://service1-internal:9001/v1/blah-
blah
},
{
region:Europe,
publicURL:https://service1-public-eu/v1/blah-blah;,
internalURL:https://service1-internal-eu/v1/blah-blah;
}
],
swift:[
{
region:regionOne,
publicURL:https://service2-public-dat/v1/blah-blah;
}
]
}
}
}
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
--
Mark Nottingham http://www.mnot.net/
This email may include confidential information. If you received it in
error, please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack
Re: [Openstack] Default ports for services
OK, now I'm confused. We have three scripts in the bin directory:
keystone-admin, keystone-auth, and keystone. If the Admin API is a superset of
the Service API, then why do we need these three variants? Wouldn't we just
need two? (Or maybe just one with a flag that said enable admin functions)
Ewan.
-Original Message-
From: Ziad Sawalha [mailto:ziad.sawa...@rackspace.com]
Sent: 23 August 2011 19:37
To: Ewan Mellor; Mark Nottingham; ksan...@doubleclix.net
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Default ports for services
The Admin API is a superset of the Service API. My thinking was that by
default Keystone starts up and exposes the Admin API on 35357 allowing
services on the local machine to find it and register themselves and
their
endpoints (especially if they are picking up ports dynamically). This
is a
simple use case for installing on one machine.
What I haven't fully worked out yet is how to handle multiple machine
deployments. I'm thinking we should then register a DNS SRV record (or
listen to broadcasts) to be discoverable by other machines on the
network
(or even a remote network).
On 8/23/11 5:49 AM, Ewan Mellor ewan.mel...@eu.citrix.com wrote:
Are you intending to use 35357 for the admin API or the service API?
And
what port will be the default for the other one?
Thanks,
Ewan.
-Original Message-
From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net
[mailto:openstack-
bounces+ewan.mellor=citrix@lists.launchpad.net]
On Behalf Of Ziad Sawalha
Sent: 16 August 2011 22:17
To: Mark Nottingham; ksan...@doubleclix.net
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Default ports for services
Keystone has been assigned TCP port 35357 by IANA.
We'll make that the default port.
Thanks,
Z
On 6/24/11 12:46 AM, Mark Nottingham m...@mnot.net wrote:
On 24/06/2011, at 3:31 PM, ksan...@doubleclix.net
ksan...@doubleclix.net wrote:
Couple of quick points:
a) Once the ports are fixed, we should register them with IANA as
well
known ports, which is the right
place.[http://www.iana.org/assignments/port-numbers]
That would be a friendly thing to do. See below for potential
conflicts.
b) I was going to suggest something like a ZooKeeper, may be the
service catalog serves that purpose.
c) Also, on the port numbers, I assume they will manifest as
universal
constants and/or a configuration file in a universally (or
intergalactically ;o)) known place.
Cheers
k/
Original Message
Subject: [Openstack] Default ports for services
From: Ziad Sawalha ziad.sawa...@rackspace.com
Date: Wed, June 22, 2011 9:52 pm
To: openstack@lists.launchpad.net
openstack@lists.launchpad.net
Where's the best place to keep track of default ports for
services
to
avoid conflicts? A wiki page on wiki.openstack.org?
We had a discussion while working on Keystone about default ports
for
OpenStack services
(https://github.com/rackspace/keystone/issues/31).
We
want OpenStack to work 'out-of-the-box' without built-in port
conflicts,
so we should coordinate which ports new services start on.
At a minimum, we need that for Keystone as it isn't discoverable.
Other
services can be discovered using the service catalog that Keystone
returns as part of an auth request (Sample response below at end
of
email).
Here's a list of ports we talked about on
https://github.com/rackspace/keystone/issues/31
80: Swift proxy server (swift/etc/proxy-server.conf-sample)
Already taken by HTTP, of course. If it's just an HTTP API, that's
fine.
6000: Swift object server
6001: Swift container server
6002: Swift account server
These are already registered for X-windows.
6080: Nova VNC proxy
free
8001: Nova direct API
taken by vcom-tunnel
8080: Swift proxy server (swift/bin/swift-proxy-server)
already HTTP alternate. Again, if it's an HTTP server (NOT http
proxy),
that's OK.
3306: MySQL
already registered to mysql
5672: AMPQ (RabbitMQ)
already AMPQ
9292: Glance API
ArmTech Daemon (whatever that is)
9191: Glance Registry
Sun AppSvr JPDA
5900...590?: qemu-system for VNC
5901-5909 are Unassigned, 5900 is already remote framebuffer.
We've moved Keystone to 5000/5001 (for Service and Admin API,
respectively).
commplex-main and commplex-link, respectively.
Sample Response with service catalog:
{
auth:{
token:{
id:asdasdasd-adsasdads-asdasdasd-adsadsasd,
expires:2010-11-01T03:32:15-05:00
},
serviceCatalog:{
nova:[
{
region:NorthAmerica,
publicURL:https://service1-public:9000/v1/blah-
blah,
internalURL:https://service1-internal:9001/v1/blah-
blah
Re: [Openstack] Default ports for services
OK, I get you. So keystone-control admin start brings up both APIs on port 35357, so which port should keystone-control auth start be using? Ewan. -Original Message- From: Ziad Sawalha [mailto:ziad.sawa...@rackspace.com] Sent: 23 August 2011 20:31 To: Ewan Mellor; Mark Nottingham; ksan...@doubleclix.net Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Default ports for services Admin and Service start on different ports (and potentially different networks). That's a deployment option we are trying to support from the get go to allow for deployments where the Admin APIU cannot be exposed on a public-facing network. Z On 8/23/11 9:55 AM, Ewan Mellor ewan.mel...@eu.citrix.com wrote: If the Admin API is a superset of the Service API, then what's the difference between keystone-control admin start and keystone- control ALL start? Thanks, Ewan. -Original Message- From: Ziad Sawalha [mailto:ziad.sawa...@rackspace.com] Sent: 23 August 2011 20:24 To: Ewan Mellor; Mark Nottingham; ksan...@doubleclix.net Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Default ports for services Yes, we'll probably be getting rid of some of those. They've been useful for testing (you can chose one, the other, or both) while we waited for a more robust implementation following other OpenStack service patterns. Keystone-control has been added to the bin folder to support the more OpenStack-like commands, but is not yet working. I think the pattern in keystone-control now is: keystone-control ALL start or keystone-control auth start or keystone-control admin start (probably should be `keystone-control service' start for the second one). On 8/23/11 9:45 AM, Ewan Mellor ewan.mel...@eu.citrix.com wrote: OK, now I'm confused. We have three scripts in the bin directory: keystone-admin, keystone-auth, and keystone. If the Admin API is a superset of the Service API, then why do we need these three variants? Wouldn't we just need two? (Or maybe just one with a flag that said enable admin functions) Ewan. -Original Message- From: Ziad Sawalha [mailto:ziad.sawa...@rackspace.com] Sent: 23 August 2011 19:37 To: Ewan Mellor; Mark Nottingham; ksan...@doubleclix.net Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Default ports for services The Admin API is a superset of the Service API. My thinking was that by default Keystone starts up and exposes the Admin API on 35357 allowing services on the local machine to find it and register themselves and their endpoints (especially if they are picking up ports dynamically). This is a simple use case for installing on one machine. What I haven't fully worked out yet is how to handle multiple machine deployments. I'm thinking we should then register a DNS SRV record (or listen to broadcasts) to be discoverable by other machines on the network (or even a remote network). On 8/23/11 5:49 AM, Ewan Mellor ewan.mel...@eu.citrix.com wrote: Are you intending to use 35357 for the admin API or the service API? And what port will be the default for the other one? Thanks, Ewan. -Original Message- From: openstack- bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack- bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Ziad Sawalha Sent: 16 August 2011 22:17 To: Mark Nottingham; ksan...@doubleclix.net Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Default ports for services Keystone has been assigned TCP port 35357 by IANA. We'll make that the default port. Thanks, Z On 6/24/11 12:46 AM, Mark Nottingham m...@mnot.net wrote: On 24/06/2011, at 3:31 PM, ksan...@doubleclix.net ksan...@doubleclix.net wrote: Couple of quick points: a) Once the ports are fixed, we should register them with IANA as well known ports, which is the right place.[http://www.iana.org/assignments/port-numbers] That would be a friendly thing to do. See below for potential conflicts. b) I was going to suggest something like a ZooKeeper, may be the service catalog serves that purpose. c) Also, on the port numbers, I assume they will manifest as universal constants and/or a configuration file in a universally (or intergalactically ;o)) known place. Cheers k/ Original Message Subject: [Openstack] Default ports for services From: Ziad Sawalha ziad.sawa...@rackspace.com Date: Wed, June 22, 2011 9:52 pm To: openstack@lists.launchpad.net openstack@lists.launchpad.net Where's the best place to keep track of default ports for services to avoid conflicts
Re: [Openstack] Default ports for services
If the Admin API is a superset of the Service API, then what's the difference between keystone-control admin start and keystone-control ALL start? Thanks, Ewan. -Original Message- From: Ziad Sawalha [mailto:ziad.sawa...@rackspace.com] Sent: 23 August 2011 20:24 To: Ewan Mellor; Mark Nottingham; ksan...@doubleclix.net Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Default ports for services Yes, we'll probably be getting rid of some of those. They've been useful for testing (you can chose one, the other, or both) while we waited for a more robust implementation following other OpenStack service patterns. Keystone-control has been added to the bin folder to support the more OpenStack-like commands, but is not yet working. I think the pattern in keystone-control now is: keystone-control ALL start or keystone-control auth start or keystone-control admin start (probably should be `keystone-control service' start for the second one). On 8/23/11 9:45 AM, Ewan Mellor ewan.mel...@eu.citrix.com wrote: OK, now I'm confused. We have three scripts in the bin directory: keystone-admin, keystone-auth, and keystone. If the Admin API is a superset of the Service API, then why do we need these three variants? Wouldn't we just need two? (Or maybe just one with a flag that said enable admin functions) Ewan. -Original Message- From: Ziad Sawalha [mailto:ziad.sawa...@rackspace.com] Sent: 23 August 2011 19:37 To: Ewan Mellor; Mark Nottingham; ksan...@doubleclix.net Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Default ports for services The Admin API is a superset of the Service API. My thinking was that by default Keystone starts up and exposes the Admin API on 35357 allowing services on the local machine to find it and register themselves and their endpoints (especially if they are picking up ports dynamically). This is a simple use case for installing on one machine. What I haven't fully worked out yet is how to handle multiple machine deployments. I'm thinking we should then register a DNS SRV record (or listen to broadcasts) to be discoverable by other machines on the network (or even a remote network). On 8/23/11 5:49 AM, Ewan Mellor ewan.mel...@eu.citrix.com wrote: Are you intending to use 35357 for the admin API or the service API? And what port will be the default for the other one? Thanks, Ewan. -Original Message- From: openstack- bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack- bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Ziad Sawalha Sent: 16 August 2011 22:17 To: Mark Nottingham; ksan...@doubleclix.net Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Default ports for services Keystone has been assigned TCP port 35357 by IANA. We'll make that the default port. Thanks, Z On 6/24/11 12:46 AM, Mark Nottingham m...@mnot.net wrote: On 24/06/2011, at 3:31 PM, ksan...@doubleclix.net ksan...@doubleclix.net wrote: Couple of quick points: a) Once the ports are fixed, we should register them with IANA as well known ports, which is the right place.[http://www.iana.org/assignments/port-numbers] That would be a friendly thing to do. See below for potential conflicts. b) I was going to suggest something like a ZooKeeper, may be the service catalog serves that purpose. c) Also, on the port numbers, I assume they will manifest as universal constants and/or a configuration file in a universally (or intergalactically ;o)) known place. Cheers k/ Original Message Subject: [Openstack] Default ports for services From: Ziad Sawalha ziad.sawa...@rackspace.com Date: Wed, June 22, 2011 9:52 pm To: openstack@lists.launchpad.net openstack@lists.launchpad.net Where's the best place to keep track of default ports for services to avoid conflicts? A wiki page on wiki.openstack.org? We had a discussion while working on Keystone about default ports for OpenStack services (https://github.com/rackspace/keystone/issues/31). We want OpenStack to work 'out-of-the-box' without built-in port conflicts, so we should coordinate which ports new services start on. At a minimum, we need that for Keystone as it isn't discoverable. Other services can be discovered using the service catalog that Keystone returns as part of an auth request (Sample response below at end of email). Here's a list of ports we talked about on https://github.com/rackspace/keystone/issues/31 80: Swift proxy server (swift/etc/proxy-server.conf-sample) Already taken by HTTP, of course. If it's just an HTTP API, that's fine. 6000: Swift object server 6001: Swift
Re: [Openstack] Default ports for services
Yes, but I'd also like to give the sysadmin's the choice at least in case they are dealing with deployment constraints that are imposed on them. From: Yuriy Taraday yorik@gmail.commailto:yorik@gmail.com Date: Tue, 23 Aug 2011 20:05:26 +0400 To: Ziad Sawalha ziad.sawa...@rackspace.commailto:ziad.sawa...@rackspace.com Cc: Ewan Mellor ewan.mel...@eu.citrix.commailto:ewan.mel...@eu.citrix.com, Mark Nottingham m...@mnot.netmailto:m...@mnot.net, ksan...@doubleclix.netmailto:ksan...@doubleclix.net ksan...@doubleclix.netmailto:ksan...@doubleclix.net, openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Default ports for services Shouldn't it be a sysadmin's headache? I think, it should be secure enough to run both APIs on one port and let sysadmin decide to allow or deny access to them on some conditions. Kind regards, Yuriy. On Tue, Aug 23, 2011 at 19:00, Ziad Sawalha ziad.sawa...@rackspace.commailto:ziad.sawa...@rackspace.com wrote: Admin and Service start on different ports (and potentially different networks). That's a deployment option we are trying to support from the get go to allow for deployments where the Admin APIU cannot be exposed on a public-facing network. Z On 8/23/11 9:55 AM, Ewan Mellor ewan.mel...@eu.citrix.commailto:ewan.mel...@eu.citrix.com wrote: If the Admin API is a superset of the Service API, then what's the difference between keystone-control admin start and keystone-control ALL start? Thanks, Ewan. -Original Message- From: Ziad Sawalha [mailto:ziad.sawa...@rackspace.commailto:ziad.sawa...@rackspace.com] Sent: 23 August 2011 20:24 To: Ewan Mellor; Mark Nottingham; ksan...@doubleclix.netmailto:ksan...@doubleclix.net Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Default ports for services Yes, we'll probably be getting rid of some of those. They've been useful for testing (you can chose one, the other, or both) while we waited for a more robust implementation following other OpenStack service patterns. Keystone-control has been added to the bin folder to support the more OpenStack-like commands, but is not yet working. I think the pattern in keystone-control now is: keystone-control ALL start or keystone-control auth start or keystone-control admin start (probably should be `keystone-control service' start for the second one). On 8/23/11 9:45 AM, Ewan Mellor ewan.mel...@eu.citrix.commailto:ewan.mel...@eu.citrix.com wrote: OK, now I'm confused. We have three scripts in the bin directory: keystone-admin, keystone-auth, and keystone. If the Admin API is a superset of the Service API, then why do we need these three variants? Wouldn't we just need two? (Or maybe just one with a flag that said enable admin functions) Ewan. -Original Message- From: Ziad Sawalha [mailto:ziad.sawa...@rackspace.commailto:ziad.sawa...@rackspace.com] Sent: 23 August 2011 19:37 To: Ewan Mellor; Mark Nottingham; ksan...@doubleclix.netmailto:ksan...@doubleclix.net Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Default ports for services The Admin API is a superset of the Service API. My thinking was that by default Keystone starts up and exposes the Admin API on 35357 allowing services on the local machine to find it and register themselves and their endpoints (especially if they are picking up ports dynamically). This is a simple use case for installing on one machine. What I haven't fully worked out yet is how to handle multiple machine deployments. I'm thinking we should then register a DNS SRV record (or listen to broadcasts) to be discoverable by other machines on the network (or even a remote network). On 8/23/11 5:49 AM, Ewan Mellor ewan.mel...@eu.citrix.commailto:ewan.mel...@eu.citrix.com wrote: Are you intending to use 35357 for the admin API or the service API? And what port will be the default for the other one? Thanks, Ewan. -Original Message- From: openstack- bounces+ewan.mellor=citrix@lists.launchpad.netmailto:citrix@lists.launchpad.net [mailto:openstack-mailto:openstack- bounces+ewan.mellor=citrix@lists.launchpad.netmailto:citrix@lists.launchpad.net] On Behalf Of Ziad Sawalha Sent: 16 August 2011 22:17 To: Mark Nottingham; ksan...@doubleclix.netmailto:ksan...@doubleclix.net Cc: openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [Openstack] Default ports for services Keystone has been assigned TCP port 35357 by IANA. We'll make that the default port. Thanks, Z On 6/24/11 12:46 AM, Mark Nottingham m...@mnot.netmailto:m...@mnot.net wrote: On 24/06/2011, at 3:31 PM, ksan
Re: [Openstack] Default ports for services
Keystone has been assigned TCP port 35357 by IANA.
We'll make that the default port.
Thanks,
Z
On 6/24/11 12:46 AM, Mark Nottingham m...@mnot.net wrote:
On 24/06/2011, at 3:31 PM, ksan...@doubleclix.net
ksan...@doubleclix.net wrote:
Couple of quick points:
a) Once the ports are fixed, we should register them with IANA as well
known ports, which is the right
place.[http://www.iana.org/assignments/port-numbers]
That would be a friendly thing to do. See below for potential conflicts.
b) I was going to suggest something like a ZooKeeper, may be the
service catalog serves that purpose.
c) Also, on the port numbers, I assume they will manifest as universal
constants and/or a configuration file in a universally (or
intergalactically ;o)) known place.
Cheers
k/
Original Message
Subject: [Openstack] Default ports for services
From: Ziad Sawalha ziad.sawa...@rackspace.com
Date: Wed, June 22, 2011 9:52 pm
To: openstack@lists.launchpad.net openstack@lists.launchpad.net
Where's the best place to keep track of default ports for services to
avoid conflicts? A wiki page on wiki.openstack.org?
We had a discussion while working on Keystone about default ports for
OpenStack services (https://github.com/rackspace/keystone/issues/31). We
want OpenStack to work 'out-of-the-box' without built-in port conflicts,
so we should coordinate which ports new services start on.
At a minimum, we need that for Keystone as it isn't discoverable. Other
services can be discovered using the service catalog that Keystone
returns as part of an auth request (Sample response below at end of
email).
Here's a list of ports we talked about on
https://github.com/rackspace/keystone/issues/31
80: Swift proxy server (swift/etc/proxy-server.conf-sample)
Already taken by HTTP, of course. If it's just an HTTP API, that's fine.
6000: Swift object server
6001: Swift container server
6002: Swift account server
These are already registered for X-windows.
6080: Nova VNC proxy
free
8001: Nova direct API
taken by vcom-tunnel
8080: Swift proxy server (swift/bin/swift-proxy-server)
already HTTP alternate. Again, if it's an HTTP server (NOT http proxy),
that's OK.
3306: MySQL
already registered to mysql
5672: AMPQ (RabbitMQ)
already AMPQ
9292: Glance API
ArmTech Daemon (whatever that is)
9191: Glance Registry
Sun AppSvr JPDA
5900...590?: qemu-system for VNC
5901-5909 are Unassigned, 5900 is already remote framebuffer.
We've moved Keystone to 5000/5001 (for Service and Admin API,
respectively).
commplex-main and commplex-link, respectively.
Sample Response with service catalog:
{
auth:{
token:{
id:asdasdasd-adsasdads-asdasdasd-adsadsasd,
expires:2010-11-01T03:32:15-05:00
},
serviceCatalog:{
nova:[
{
region:NorthAmerica,
publicURL:https://service1-public:9000/v1/blah-blah;,
internalURL:https://service1-internal:9001/v1/blah-blah;
},
{
region:Europe,
publicURL:https://service1-public-eu/v1/blah-blah;,
internalURL:https://service1-internal-eu/v1/blah-blah;
}
],
swift:[
{
region:regionOne,
publicURL:https://service2-public-dat/v1/blah-blah;
}
]
}
}
}
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
--
Mark Nottingham http://www.mnot.net/
This email may include confidential information. If you received it in error,
please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Default ports for services
Todd Willey wrote: I think people will probably deploy in such a way that clients talk to 80 or 443. But there are a number of ways to get to that outcome, including specifying it in the server configuration, or running behind load balancers or other front-end services. Running everything be default on different ports by default has little bearing on how it gets run in production. Also running on *separate* ports has an added advantage in distro packaging: you can apt-get install the different components and start them up at install-time with default configs, without having to care for them potentially interfering with each other in the (common) case of all-in-ones. If we switch to using 80/8080 by default everywhere, to workaround this issue we'll have to package each component with a config that enables a specific port. And then we have a different defaults (the packaging default and the what happens when I remove the port option default), which will be confusing... for little gain. So I'm -1 on this :) -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Default ports for services
The effort Jay (and others) are doing on standardizing across services could also be helpful here; having a -p --ports command-line and config setting that works with all services would make it easier to stand up a set of services on non-conflicting ports. On 6/25/11 9:11 PM, Todd Willey t...@ansolabs.com wrote: On Sat, Jun 25, 2011 at 11:47 AM, Jay Pipes jaypi...@gmail.com wrote: On Fri, Jun 24, 2011 at 10:10 AM, Todd Willey t...@ansolabs.com wrote: I'd prefer to keep it convenient to develop and demo on a single machine. I don't think there is any added inconvenience during deployment if the ports are not the standard http ports. Can you explain why having the *default* port be 80/8080 for HTTP services would hinder that? Unless I'm mistaken, spinning up servers on different ports is as simple as specifying a set of test config files that have ports set for an all-on-one-machine setup? Just curious... -jay I'm just trying to avoid having to either remember a command line flag for every service I launch, or remember to not check in config files that specify port numbers that I've changed in source directories. If we go to a 80/8080 setup I'll just end up writing scripts that wrap all the services, but I imagine that if I'm doing that to make things easier, people who want to evaluate OpenStack on a single box are going to find things unnecessarily complicated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Default ports for services
We have the service catalog functionality in Keystone which provides discovery. We still need to complete the user story of how a service registers itself; the functionality is available, but not fully documented as a story. The question of ports still remains, though. How do you find Keystone? Options: - Register a port as suggested earlier (that would be a port for the service catalog?) - DNS? SRV record? - convention: 80/8080 (and raise conflicts as an error?) We could also provide some form of proxy functionality if services are running on non-standard portsŠ On 6/27/11 3:01 AM, Thierry Carrez thie...@openstack.org wrote: Todd Willey wrote: I think people will probably deploy in such a way that clients talk to 80 or 443. But there are a number of ways to get to that outcome, including specifying it in the server configuration, or running behind load balancers or other front-end services. Running everything be default on different ports by default has little bearing on how it gets run in production. Also running on *separate* ports has an added advantage in distro packaging: you can apt-get install the different components and start them up at install-time with default configs, without having to care for them potentially interfering with each other in the (common) case of all-in-ones. If we switch to using 80/8080 by default everywhere, to workaround this issue we'll have to package each component with a config that enables a specific port. And then we have a different defaults (the packaging default and the what happens when I remove the port option default), which will be confusing... for little gain. So I'm -1 on this :) -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Default ports for services
2011/6/25 Jay Pipes jaypi...@gmail.com: Can you explain why having the *default* port be 80/8080 for HTTP services would hinder that? Unless I'm mistaken, spinning up servers on different ports is as simple as specifying a set of test config files that have ports set for an all-on-one-machine setup? I've heard this sort of argument before, and I've never quite understood it. Yes, our API happens to be built on top of HTTP, but why must that bleed into the choice of port number? I think of port 80 not so much as the HTTP port, but rather the www port (and 8080 as the unprivileged www port). Say we had come up with our own basic, generic protocol, on top of which we'd built the Glance API, Nova API, Swift API, etc... Would you want them to have assigned a single port as well, just because their API's all were encapsulated in the same generic protocol? -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Default ports for services
On Sun, Jun 26, 2011 at 3:15 AM, Soren Hansen so...@linux2go.dk wrote: 2011/6/25 Jay Pipes jaypi...@gmail.com: Can you explain why having the *default* port be 80/8080 for HTTP services would hinder that? Unless I'm mistaken, spinning up servers on different ports is as simple as specifying a set of test config files that have ports set for an all-on-one-machine setup? I've heard this sort of argument before, and I've never quite understood it. Yes, our API happens to be built on top of HTTP, but why must that bleed into the choice of port number? I think of port 80 not so much as the HTTP port, but rather the www port (and 8080 as the unprivileged www port). Say we had come up with our own basic, generic protocol, on top of which we'd built the Glance API, Nova API, Swift API, etc... Would you want them to have assigned a single port as well, just because their API's all were encapsulated in the same generic protocol? If we develop APIs on top of other protocols, I'd expect them to be different ports. All I'm saying is that our services (except for Burrow, which has non-HTTP choices) are HTTP services, and since 80 is the default port for HTTP, I think it's natural for our services to run on 80. I hear the other arguments, though. Just offering my opinion. :) -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Default ports for services
If we use something other than 80 for http and/or 443 for https, then clients will have to know magic numbers for the port and firewall obstacles will annoy them. I don't see HTTP as something we just happen to have chosen. We should prefer convention over configuration, and embrace the conventions of HTTP. On 6/26/11 11:13 AM, Jay Pipes jaypi...@gmail.com wrote: On Sun, Jun 26, 2011 at 3:15 AM, Soren Hansen so...@linux2go.dk wrote: 2011/6/25 Jay Pipes jaypi...@gmail.com: Can you explain why having the *default* port be 80/8080 for HTTP services would hinder that? Unless I'm mistaken, spinning up servers on different ports is as simple as specifying a set of test config files that have ports set for an all-on-one-machine setup? I've heard this sort of argument before, and I've never quite understood it. Yes, our API happens to be built on top of HTTP, but why must that bleed into the choice of port number? I think of port 80 not so much as the HTTP port, but rather the www port (and 8080 as the unprivileged www port). Say we had come up with our own basic, generic protocol, on top of which we'd built the Glance API, Nova API, Swift API, etc... Would you want them to have assigned a single port as well, just because their API's all were encapsulated in the same generic protocol? If we develop APIs on top of other protocols, I'd expect them to be different ports. All I'm saying is that our services (except for Burrow, which has non-HTTP choices) are HTTP services, and since 80 is the default port for HTTP, I think it's natural for our services to run on 80. I hear the other arguments, though. Just offering my opinion. :) -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Default ports for services
So, I gather you're agreeing with me? :) -jay On Sun, Jun 26, 2011 at 9:50 AM, Bryan Taylor btay...@rackspace.com wrote: If we use something other than 80 for http and/or 443 for https, then clients will have to know magic numbers for the port and firewall obstacles will annoy them. I don't see HTTP as something we just happen to have chosen. We should prefer convention over configuration, and embrace the conventions of HTTP. On 6/26/11 11:13 AM, Jay Pipes jaypi...@gmail.com wrote: On Sun, Jun 26, 2011 at 3:15 AM, Soren Hansen so...@linux2go.dk wrote: 2011/6/25 Jay Pipes jaypi...@gmail.com: Can you explain why having the *default* port be 80/8080 for HTTP services would hinder that? Unless I'm mistaken, spinning up servers on different ports is as simple as specifying a set of test config files that have ports set for an all-on-one-machine setup? I've heard this sort of argument before, and I've never quite understood it. Yes, our API happens to be built on top of HTTP, but why must that bleed into the choice of port number? I think of port 80 not so much as the HTTP port, but rather the www port (and 8080 as the unprivileged www port). Say we had come up with our own basic, generic protocol, on top of which we'd built the Glance API, Nova API, Swift API, etc... Would you want them to have assigned a single port as well, just because their API's all were encapsulated in the same generic protocol? If we develop APIs on top of other protocols, I'd expect them to be different ports. All I'm saying is that our services (except for Burrow, which has non-HTTP choices) are HTTP services, and since 80 is the default port for HTTP, I think it's natural for our services to run on 80. I hear the other arguments, though. Just offering my opinion. :) -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Default ports for services
I think people will probably deploy in such a way that clients talk to 80 or 443. But there are a number of ways to get to that outcome, including specifying it in the server configuration, or running behind load balancers or other front-end services. Running everything be default on different ports by default has little bearing on how it gets run in production. On Sun, Jun 26, 2011 at 12:50 PM, Bryan Taylor btay...@rackspace.com wrote: If we use something other than 80 for http and/or 443 for https, then clients will have to know magic numbers for the port and firewall obstacles will annoy them. I don't see HTTP as something we just happen to have chosen. We should prefer convention over configuration, and embrace the conventions of HTTP. On 6/26/11 11:13 AM, Jay Pipes jaypi...@gmail.com wrote: On Sun, Jun 26, 2011 at 3:15 AM, Soren Hansen so...@linux2go.dk wrote: 2011/6/25 Jay Pipes jaypi...@gmail.com: Can you explain why having the *default* port be 80/8080 for HTTP services would hinder that? Unless I'm mistaken, spinning up servers on different ports is as simple as specifying a set of test config files that have ports set for an all-on-one-machine setup? I've heard this sort of argument before, and I've never quite understood it. Yes, our API happens to be built on top of HTTP, but why must that bleed into the choice of port number? I think of port 80 not so much as the HTTP port, but rather the www port (and 8080 as the unprivileged www port). Say we had come up with our own basic, generic protocol, on top of which we'd built the Glance API, Nova API, Swift API, etc... Would you want them to have assigned a single port as well, just because their API's all were encapsulated in the same generic protocol? If we develop APIs on top of other protocols, I'd expect them to be different ports. All I'm saying is that our services (except for Burrow, which has non-HTTP choices) are HTTP services, and since 80 is the default port for HTTP, I think it's natural for our services to run on 80. I hear the other arguments, though. Just offering my opinion. :) -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Default ports for services
Right, but it's not all about deployment, because representations within the API have absolute hrefs embedded within them. On 6/26/11 12:11 PM, Todd Willey t...@ansolabs.com wrote: I think people will probably deploy in such a way that clients talk to 80 or 443. But there are a number of ways to get to that outcome, including specifying it in the server configuration, or running behind load balancers or other front-end services. Running everything be default on different ports by default has little bearing on how it gets run in production. On Sun, Jun 26, 2011 at 12:50 PM, Bryan Taylor btay...@rackspace.com wrote: If we use something other than 80 for http and/or 443 for https, then clients will have to know magic numbers for the port and firewall obstacles will annoy them. I don't see HTTP as something we just happen to have chosen. We should prefer convention over configuration, and embrace the conventions of HTTP. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Default ports for services
On Fri, Jun 24, 2011 at 10:10 AM, Todd Willey t...@ansolabs.com wrote: I'd prefer to keep it convenient to develop and demo on a single machine. I don't think there is any added inconvenience during deployment if the ports are not the standard http ports. Can you explain why having the *default* port be 80/8080 for HTTP services would hinder that? Unless I'm mistaken, spinning up servers on different ports is as simple as specifying a set of test config files that have ports set for an all-on-one-machine setup? Just curious... -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Default ports for services
On Sat, Jun 25, 2011 at 11:47 AM, Jay Pipes jaypi...@gmail.com wrote: On Fri, Jun 24, 2011 at 10:10 AM, Todd Willey t...@ansolabs.com wrote: I'd prefer to keep it convenient to develop and demo on a single machine. I don't think there is any added inconvenience during deployment if the ports are not the standard http ports. Can you explain why having the *default* port be 80/8080 for HTTP services would hinder that? Unless I'm mistaken, spinning up servers on different ports is as simple as specifying a set of test config files that have ports set for an all-on-one-machine setup? Just curious... -jay I'm just trying to avoid having to either remember a command line flag for every service I launch, or remember to not check in config files that specify port numbers that I've changed in source directories. If we go to a 80/8080 setup I'll just end up writing scripts that wrap all the services, but I imagine that if I'm doing that to make things easier, people who want to evaluate OpenStack on a single box are going to find things unnecessarily complicated. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Default ports for services
Thanks Mark.Excellent - better to find the conflicts now than later.On a related note, we should also have media types (and supporting RFCs) for the appropriate http interactions. We did that for CDMI (http://tools.ietf.org/html/rfc6208) Makes it easy for ops and implementations ...Cheersk/
Original Message
Subject: Re: [Openstack] Default ports for services
From: Mark Nottingham m...@mnot.net
Date: Thu, June 23, 2011 10:46 pm
To: ksan...@doubleclix.net ksan...@doubleclix.net
Cc: "Ziad Sawalha" ziad.sawa...@rackspace.com,
"openstack@lists.launchpad.net" openstack@lists.launchpad.net
On 24/06/2011, at 3:31 PM, ksan...@doubleclix.net ksan...@doubleclix.net wrote:
Couple of quick points:
a) Once the ports are fixed, we should register them with IANA as well known ports, which is the right place.[http://www.iana.org/assignments/port-numbers]
That would be a friendly thing to do. See below for potential conflicts.
b) I was going to suggest something like a ZooKeeper, may be the service catalog serves that purpose.
c) Also, on the port numbers, I assume they will manifest as universal constants and/or a configuration file in a universally (or intergalactically ;o)) known place.
Cheers
k/
Original Message
Subject: [Openstack] Default ports for services
From: Ziad Sawalha ziad.sawa...@rackspace.com
Date: Wed, June 22, 2011 9:52 pm
To: "openstack@lists.launchpad.net" openstack@lists.launchpad.net
Where's the best place to keep track of default ports for services to avoid conflicts? A wiki page on wiki.openstack.org?
We had a discussion while working on Keystone about default ports for OpenStack services (https://github.com/rackspace/keystone/issues/31). We want OpenStack to work 'out-of-the-box' without built-in port conflicts, so we should coordinate which ports new services start on.
At a minimum, we need that for Keystone as it isn't discoverable. Other services can be discovered using the service catalog that Keystone returns as part of an auth request (Sample response below at end of email).
Here's a list of ports we talked about on https://github.com/rackspace/keystone/issues/31
80: Swift proxy server (swift/etc/proxy-server.conf-sample)
Already taken by HTTP, of course. If it's just an HTTP API, that's fine.
6000: Swift object server
6001: Swift container server
6002: Swift account server
These are already registered for X-windows.
6080: Nova VNC proxy
free
8001: Nova direct API
taken by vcom-tunnel
8080: Swift proxy server (swift/bin/swift-proxy-server)
already HTTP alternate. Again, if it's an HTTP server (NOT http proxy), that's OK.
3306: MySQL
already registered to mysql
5672: AMPQ (RabbitMQ)
already AMPQ
9292: Glance API
ArmTech Daemon (whatever that is)
9191: Glance Registry
Sun AppSvr JPDA
5900...590?: qemu-system for VNC
5901-5909 are Unassigned, 5900 is already remote framebuffer.
We've moved Keystone to 5000/5001 (for Service and Admin API, respectively).
commplex-main and commplex-link, respectively.
Sample Response with service catalog:
{
"auth":{
"token":{
"id":"asdasdasd-adsasdads-asdasdasd-adsadsasd",
"expires":"2010-11-01T03:32:15-05:00"
},
"serviceCatalog":{
"nova":[
{
"region":"NorthAmerica",
"publicURL":"https://service1-public:9000/v1/blah-blah",
"internalURL":"https://service1-internal:9001/v1/blah-blah"
},
{
"region":"Europe",
"publicURL":"https://service1-public-eu/v1/blah-blah",
"internalURL":"https://service1-internal-eu/v1/blah-blah"
}
],
"swift":[
{
"region":"regionOne",
"publicURL":"https://service2-public-dat/v1/blah-blah"
}
]
}
}
}
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
--
Mark Nottingham http://www.mnot.net/
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Default ports for services
Hi!
As I stated on our Skype chat about this the other day, I think that
the default port for HTTP services should be 80, with 8080 used for
administrative endpoints. Unless there's a good reason to have a
specific port assigned to what is essentially just an HTTP service, I
don't think we should stray from the standard.
That said, I recognize that Glance's API and registry servers are at
9292 and 9191 respectively. I believe it was a mistake to do that, and
I would support switching those both back to 80.
-jay
On Wed, Jun 22, 2011 at 9:52 PM, Ziad Sawalha
ziad.sawa...@rackspace.com wrote:
Where's the best place to keep track of default ports for services to avoid
conflicts? A wiki page on wiki.openstack.org?
We had a discussion while working on Keystone about default ports for
OpenStack services (https://github.com/rackspace/keystone/issues/31). We
want OpenStack to work 'out-of-the-box' without built-in port conflicts, so
we should coordinate which ports new services start on.
At a minimum, we need that for Keystone as it isn't discoverable. Other
services can be discovered using the service catalog that Keystone returns
as part of an auth request (Sample response below at end of email).
Here's a list of ports we talked about on
https://github.com/rackspace/keystone/issues/31
80: Swift proxy server (swift/etc/proxy-server.conf-sample)
6000: Swift object server
6001: Swift container server
6002: Swift account server
6080: Nova VNC proxy
8001: Nova direct API
8080: Swift proxy server (swift/bin/swift-proxy-server)
3306: MySQL
5672: AMPQ (RabbitMQ)
9292: Glance API
9191: Glance Registry
5900...590?: qemu-system for VNC
We've moved Keystone to 5000/5001 (for Service and Admin API, respectively).
Sample Response with service catalog:
{
auth:{
token:{
id:asdasdasd-adsasdads-asdasdasd-adsadsasd,
expires:2010-11-01T03:32:15-05:00
},
serviceCatalog:{
nova:[
{
region:NorthAmerica,
publicURL:https://service1-public:9000/v1/blah-blah;,
internalURL:https://service1-internal:9001/v1/blah-blah;
},
{
region:Europe,
publicURL:https://service1-public-eu/v1/blah-blah;,
internalURL:https://service1-internal-eu/v1/blah-blah;
}
],
swift:[
{
region:regionOne,
publicURL:https://service2-public-dat/v1/blah-blah;
}
]
}
}
}
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Default ports for services
I'd prefer to keep it convenient to develop and demo on a single
machine. I don't think there is any added inconvenience during
deployment if the ports are not the standard http ports.
On Fri, Jun 24, 2011 at 12:15 PM, Jay Pipes jaypi...@gmail.com wrote:
Hi!
As I stated on our Skype chat about this the other day, I think that
the default port for HTTP services should be 80, with 8080 used for
administrative endpoints. Unless there's a good reason to have a
specific port assigned to what is essentially just an HTTP service, I
don't think we should stray from the standard.
That said, I recognize that Glance's API and registry servers are at
9292 and 9191 respectively. I believe it was a mistake to do that, and
I would support switching those both back to 80.
-jay
On Wed, Jun 22, 2011 at 9:52 PM, Ziad Sawalha
ziad.sawa...@rackspace.com wrote:
Where's the best place to keep track of default ports for services to avoid
conflicts? A wiki page on wiki.openstack.org?
We had a discussion while working on Keystone about default ports for
OpenStack services (https://github.com/rackspace/keystone/issues/31). We
want OpenStack to work 'out-of-the-box' without built-in port conflicts, so
we should coordinate which ports new services start on.
At a minimum, we need that for Keystone as it isn't discoverable. Other
services can be discovered using the service catalog that Keystone returns
as part of an auth request (Sample response below at end of email).
Here's a list of ports we talked about on
https://github.com/rackspace/keystone/issues/31
80: Swift proxy server (swift/etc/proxy-server.conf-sample)
6000: Swift object server
6001: Swift container server
6002: Swift account server
6080: Nova VNC proxy
8001: Nova direct API
8080: Swift proxy server (swift/bin/swift-proxy-server)
3306: MySQL
5672: AMPQ (RabbitMQ)
9292: Glance API
9191: Glance Registry
5900...590?: qemu-system for VNC
We've moved Keystone to 5000/5001 (for Service and Admin API, respectively).
Sample Response with service catalog:
{
auth:{
token:{
id:asdasdasd-adsasdads-asdasdasd-adsadsasd,
expires:2010-11-01T03:32:15-05:00
},
serviceCatalog:{
nova:[
{
region:NorthAmerica,
publicURL:https://service1-public:9000/v1/blah-blah;,
internalURL:https://service1-internal:9001/v1/blah-blah;
},
{
region:Europe,
publicURL:https://service1-public-eu/v1/blah-blah;,
internalURL:https://service1-internal-eu/v1/blah-blah;
}
],
swift:[
{
region:regionOne,
publicURL:https://service2-public-dat/v1/blah-blah;
}
]
}
}
}
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Default ports for services
Couple of quick points:a) Once the ports are fixed, we should register them with IANA as well known ports, which is the right place.[http://www.iana.org/assignments/port-numbers]b) I was going to suggest something like a ZooKeeper, may be the service catalog serves that purpose.c) Also, on the port numbers, I assume they will manifest as universal constants and/or a configuration file in a universally (or intergalactically ;o)) known place.Cheersk/
Original Message
Subject: [Openstack] Default ports for services
From: Ziad Sawalha ziad.sawa...@rackspace.com
Date: Wed, June 22, 2011 9:52 pm
To: "openstack@lists.launchpad.net" openstack@lists.launchpad.net
Where's the best place to keep track of default ports for services to avoid conflicts? A wiki page on wiki.openstack.org? We had a discussion while working on Keystone about default ports for OpenStack services (https://github.com/rackspace/keystone/issues/31). We want OpenStack to work 'out-of-the-box' without built-in port conflicts, so we should coordinate which ports new services start on. At a minimum, we need that for Keystone as it isn't discoverable. Other services can be discovered using the service catalog that Keystone returns as part of an auth request (Sample response below at end of email). Here's a list of ports we talked about on https://github.com/rackspace/keystone/issues/31 80: Swift proxy server (swift/etc/proxy-server.conf-sample) 6000: Swift object server 6001: Swift container server 6002: Swift account server 6080: Nova VNC proxy 8001: Nova direct API 8080: Swift proxy server (swift/bin/swift-proxy-server) 3306: MySQL 5672: AMPQ (RabbitMQ) 9292: Glance API 9191: Glance Registry 5900...590?: qemu-system for VNC We've moved Keystone to 5000/5001 (for Service and Admin API, respectively).Sample Response with service catalog: { "auth":{ "token":{ "id":"asdasdasd-adsasdads-asdasdasd-adsadsasd", "expires":"2010-11-01T03:32:15-05:00" }, "serviceCatalog":{ "nova":[{ "region":"NorthAmerica", "publicURL":"https://service1-public:9000/v1/blah-blah", "internalURL":"https://service1-internal:9001/v1/blah-blah"},{ "region":"Europe", "publicURL":"https://service1-public-eu/v1/blah-blah", "internalURL":"https://service1-internal-eu/v1/blah-blah"} ], "swift":[{ "region":"regionOne", "publicURL":"https://service2-public-dat/v1/blah-blah"} ] } } } ___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
