Open Stack

Yeah, switching them that way makes a lot of sense.

Thanks,
Kevin

________________________________
From: Dan Sneddon
Sent: Thursday, December 03, 2015 12:39:25 PM
To: Fox, Kevin M; Jesse Keating; Sean Dague
Cc: openstack-operators
Subject: Re: [Openstack-operators] Service Catalog TNG urls

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 [jlk at 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 <sean at dague.net
> <mailto:sean at 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 at lists.openstack.org
>     <mailto:OpenStack-operators at lists.openstack.org>
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at 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
dsneddon at redhat.com |  redhat.com/openstack
650.254.4025        |  dsneddon:irc   @dxs:twitter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20151203/f639ceb2/attachment.html>