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 <ayo...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
