I'm not sure why you've marked Swift URLs as having their own scheme. It's true 
that Swift doesn't have the concept of "admin" URLs, but in general if Swift 
were to assume some URL path prefix, I'm not sure why it wouldn't work (for 
some definition of work).

Other issues might be the fact that you'd have the extra complexity of a broker 
layer for all the OpenStack components. iie instead of clients accessing Swift 
directly and the operator scaling that, the new scheme would require the 
operator to manage and scale the broker layer and also the Swift layer.

For the record, Swift would need to be updated since it assumes it's the only 
service running on the domain at that port (Swift does a lot of path parsing).


> On Nov 11, 2014, at 2:35 PM, Adam Young <> wrote:
> Recent recurrence of the "Why ios everything on its own port" question 
> triggered my desire to take this pattern and put it to rest.
> My suggestion, from a while ago, was to have a naming scheme that deconflicts 
> putting all of the services onto a single server, on port 443.
> I've removed a lot of the cruft, but not added in entries for all the new 
> *aaS services.
> Please add in anything that should be part of OpenStack.  Let's make this a 
> reality, and remove the  specific ports.
> If you are worried about debugging, look into rpdb.  It is a valuable tool 
> for debugging a mod_wsgi based application.
> _______________________________________________
> OpenStack-dev mailing list

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

OpenStack-dev mailing list

Reply via email to