@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
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
; 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
; 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
@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
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
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
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
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?
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
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
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
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
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
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
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
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
/
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
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
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
, 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
21 matches
Mail list logo
