• The first step might be a well known (inside OpenStack) port for keystone and then register with IANA to avoid any conflicts. 
  • Second, the service should have a ping-pong interface, with pong sending a version number (to make it easy for clients to make sure they can find the functionalities they are looking for)
  • Where it could get complicated is the dynamic port configuration - ie search & find an unused port and then to let other services know of the port number
  • As I was saying earlier, we might end up implementing some capabilities of Apache ZooKeeper - for example configuration, distributed coordination & service discovery
  • BTW, Keystone looks interesting, ... need to take a closer look
Cheers
<k/>
P.S : If the service catalog becomes a central essential service, we might need to look at scalability and redundancy.
-------- Original Message --------
Subject: Re: [Openstack] Default ports for services
From: Ziad Sawalha <ziad.sawa...@rackspace.com>
Date: Mon, June 27, 2011 7:20 am
To: Thierry Carrez <thie...@openstack.org>,
"openstack@lists.launchpad.net" <openstack@lists.launchpad.net>

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
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to