We use internal to be a private network between the controllers and the compute nodes that no one else has access to. Without that, we'd be stuck.
An OpenStack network that's where all the public services go, that isn't external to the cloud for billing purposes does make sense too though. Maybe all three should be clearly delineated. Maybe something like: * Public - Available outside. may incur costs to access internally * Internal - Available publicly by machines in the cloud. no cost is ever incurred from using them. * Provider - Not exposed to normal users and intended for backend sorts of things. Hopefully we can make it a strong enough convention that apps can rely on it between clouds. Thanks, Kevin ________________________________ From: Jesse Keating [j...@bluebox.net] Sent: Thursday, December 03, 2015 8:09 AM To: Sean Dague Cc: openstack-operators Subject: Re: [Openstack-operators] Service Catalog TNG urls We make use of http urls internally for services to talk to each other, but not for human users. All our human users should be using https public url. We don't actually utilize the internalURL framework, instead we use /etc/hosts entries to change the domain resolution of our publicURL entries, and use other config file controls to reflect http vs https. Partly this is because we don't want to advertise internal IP addresses in the catalog. Partly this is because we do not want to advertise an http link that a client might accidentally use and pass credentials in the clear over the Internet. I believe we would be perfectly happy to do away with adminURL and internalURL. It'd certainly reduce our per-site configuration entries, and reduce confusion around what purpose these entries serve. - jlk On Thu, Dec 3, 2015 at 6:14 AM, Sean Dague <s...@dague.net<mailto:s...@dague.net>> wrote: 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<mailto:OpenStack-operators@lists.openstack.org> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
