[openstack-dev] URLs

John Dickinson me at not.mn
Mon Nov 17 16:51:48 UTC 2014


Adam,

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).

--John






> On Nov 11, 2014, at 2:35 PM, Adam Young <ayoung at redhat.com> 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.
> 
> 
> https://wiki.openstack.org/wiki/URLs
> 
> 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
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141117/6720789f/attachment.pgp>


More information about the OpenStack-dev mailing list