Open Stack

On Sun, Jun 26, 2011 at 3:15 AM, Soren Hansen <soren at linux2go.dk> wrote:
> 2011/6/25 Jay Pipes <jaypipes at 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