[Openstack] Default ports for services
Ziad Sawalha
ziad.sawalha at rackspace.com
Wed Jul 13 04:13:50 UTC 2011
Excellent points (including the PS – right now, the only scale we offer is the ability to use MySQL instead of sqlite which gives you decent scale as a reference implementation. Memcache, LDAP, and other goodness to come….).
We've put Keystone on 5000/5001 for now (that's an OpenStack-only solution for now). The service can be started on any port using the –p/--port parameter or config setting.
Z
From: <ksankar at doubleclix.net<mailto:ksankar at doubleclix.net>>
Date: Mon, 27 Jun 2011 08:58:25 -0700
To: Ziad Sawalha <ziad.sawalha at rackspace.com<mailto:ziad.sawalha at rackspace.com>>
Cc: Thierry Carrez <thierry at openstack.org<mailto:thierry at openstack.org>>, "openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>" <openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>>
Subject: RE: [Openstack] Default ports for services
* 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.sawalha at rackspace.com<http://ziad.sawalha@rackspace.com>>
Date: Mon, June 27, 2011 7:20 am
To: Thierry Carrez <thierry at openstack.org<mailto:thierry at openstack.org>>,
"openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>" <openstack at lists.launchpad.net<mailto:openstack at 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" <thierry at openstack.org<mailto:thierry at 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 at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
>Unsubscribe : https://launchpad.net/~openstack
>More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to : openstack at lists.launchpad.net<mailto:openstack at lists.launchpad.net>
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
This email may include confidential information. If you received it in error, please delete it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110713/e5de96a9/attachment.html>
More information about the Openstack
mailing list