Open Stack

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20151203/334ea8b1/attachment.html>