For folks that don't know, we've got an effort under way to look at some
of what's happened with the service catalog, how it's organically grown,
and do some pruning and tuning to make sure it's going to support what
we want to do with OpenStack for the next 5 years (wiki page to dive
deeper here - https://wiki.openstack.org/wiki/ServiceCatalogTNG).
One of the early Open Questions is about urls. Today there is a
completely free form field to specify urls, and there are conventions
about having publicURL, internalURL, adminURL. These are, however, only
conventions.
The only project that's ever really used adminURL has been Keystone, so
that's something we feel we can phase out in new representations.
The real question / concern is around public vs. internal. And something
we'd love feedback from people on.
When this was brought up in Tokyo the answer we got was that internal
URL was important because:
* users trusted it to mean "I won't get changed for bandwidth"
* it is often http instead of https, which provides a 20% performance
gain for transfering large amounts of data (i.e. glance images)
The question is, how hard would it be for sites to be configured so that
internal routing is used whenever possible? Or is this a concept we need
to formalize and make user applications always need to make the decision
about which interface they should access?
-Sean
--
Sean Dague
http://dague.net
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
