On 12/03/2015 09:46 AM, Fox, Kevin M wrote: > 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 >
Kevin, I'm not sure I'm on board with the three endpoints as listed, but at the very least I would swap Internal and Provider in your example: * Public - Available outside. may incur costs to access internally * Internal - Not exposed to normal users and intended for backend sorts of things. * Provider - Available publicly by machines in the cloud. no cost is ever incurred from using them. Provider would then correspond to a provider network, where it is put in place for the benefit of the VMs. -- Dan Sneddon | Principal OpenStack Engineer dsned...@redhat.com | redhat.com/openstack 650.254.4025 | dsneddon:irc @dxs:twitter _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
