<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<div>Yeah, switching them that way makes a lot of sense.<br>
<br>
Thanks,<br>
Kevin <strong>
<div><font face="Tahoma" color="#000000" size="2"> </font></div>
</strong>
<hr tabindex="-1">
<font face="Tahoma" size="2"><b>From:</b> Dan Sneddon<br>
<b>Sent:</b> Thursday, December 03, 2015 12:39:25 PM<br>
<b>To:</b> Fox, Kevin M; Jesse Keating; Sean Dague<br>
<b>Cc:</b> openstack-operators<br>
<b>Subject:</b> Re: [Openstack-operators] Service Catalog TNG urls<br>
</font><br>
<div></div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">On 12/03/2015 09:46 AM, Fox, Kevin M wrote:<br>
> We use internal to be a private network between the controllers and the<br>
> compute nodes that no one else has access to. Without that, we'd be stuck.<br>
> <br>
> An OpenStack network that's where all the public services go, that<br>
> isn't external to the cloud for billing purposes does make sense too<br>
> though. Maybe all three should be clearly delineated. Maybe something like:<br>
> <br>
> * Public - Available outside. may incur costs to access internally<br>
> * Internal - Available publicly by machines in the cloud. no cost is<br>
> ever incurred from using them.<br>
> * Provider - Not exposed to normal users and intended for backend sorts<br>
> of things.<br>
> <br>
> Hopefully we can make it a strong enough convention that apps can rely<br>
> on it between clouds.<br>
> <br>
> Thanks,<br>
> Kevin<br>
> -----------------------------------------------------------------------<br>
> *From:* Jesse Keating [jlk@bluebox.net]<br>
> *Sent:* Thursday, December 03, 2015 8:09 AM<br>
> *To:* Sean Dague<br>
> *Cc:* openstack-operators<br>
> *Subject:* Re: [Openstack-operators] Service Catalog TNG urls<br>
> <br>
> We make use of http urls internally for services to talk to each other,<br>
> but not for human users. All our human users should be using https<br>
> public url. We don't actually utilize the internalURL framework,<br>
> instead we use /etc/hosts entries to change the domain resolution of<br>
> our publicURL entries, and use other config file controls to reflect<br>
> http vs https.<br>
> <br>
> Partly this is because we don't want to advertise internal IP addresses<br>
> in the catalog. Partly this is because we do not want to advertise an<br>
> http link that a client might accidentally use and pass credentials in<br>
> the clear over the Internet.<br>
> <br>
> I believe we would be perfectly happy to do away with adminURL and<br>
> internalURL. It'd certainly reduce our per-site configuration entries,<br>
> and reduce confusion around what purpose these entries serve.<br>
> <br>
> <br>
> - jlk<br>
> <br>
> On Thu, Dec 3, 2015 at 6:14 AM, Sean Dague <sean@dague.net<br>
> <<a href="mailto:sean@dague.net">mailto:sean@dague.net</a>>> wrote:<br>
> <br>
> For folks that don't know, we've got an effort under way to look at<br>
> some<br>
> of what's happened with the service catalog, how it's organically<br>
> grown,<br>
> and do some pruning and tuning to make sure it's going to support what<br>
> we want to do with OpenStack for the next 5 years (wiki page to dive<br>
> deeper here - <a href="https://wiki.openstack.org/wiki/ServiceCatalogTNG">https://wiki.openstack.org/wiki/ServiceCatalogTNG</a>).<br>
> <br>
> One of the early Open Questions is about urls. Today there is a<br>
> completely free form field to specify urls, and there are conventions<br>
> about having publicURL, internalURL, adminURL. These are, however, only<br>
> conventions.<br>
> <br>
> The only project that's ever really used adminURL has been Keystone, so<br>
> that's something we feel we can phase out in new representations.<br>
> <br>
> The real question / concern is around public vs. internal. And<br>
> something<br>
> we'd love feedback from people on.<br>
> <br>
> When this was brought up in Tokyo the answer we got was that internal<br>
> URL was important because:<br>
> <br>
> * users trusted it to mean "I won't get changed for bandwidth"<br>
> * it is often http instead of https, which provides a 20% performance<br>
> gain for transfering large amounts of data (i.e. glance images)<br>
> <br>
> The question is, how hard would it be for sites to be configured so<br>
> that<br>
> internal routing is used whenever possible? Or is this a concept we<br>
> need<br>
> to formalize and make user applications always need to make the<br>
> decision<br>
> about which interface they should access?<br>
> <br>
> -Sean<br>
> <br>
> --<br>
> Sean Dague<br>
> <a href="http://dague.net">http://dague.net</a><br>
> <br>
> _______________________________________________<br>
> OpenStack-operators mailing list<br>
> OpenStack-operators@lists.openstack.org<br>
> <<a href="mailto:OpenStack-operators@lists.openstack.org">mailto:OpenStack-operators@lists.openstack.org</a>><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
> <br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> OpenStack-operators mailing list<br>
> OpenStack-operators@lists.openstack.org<br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators">
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
> <br>
<br>
Kevin,<br>
<br>
I'm not sure I'm on board with the three endpoints as listed, but at<br>
the very least I would swap Internal and Provider in your example:<br>
<br>
* Public - Available outside. may incur costs to access internally<br>
* Internal - Not exposed to normal users and intended for backend sorts<br>
of things.<br>
* Provider - Available publicly by machines in the cloud. no cost is<br>
ever incurred from using them.<br>
<br>
Provider would then correspond to a provider network, where it is put<br>
in place for the benefit of the VMs.<br>
-- <br>
Dan Sneddon | Principal OpenStack Engineer<br>
dsneddon@redhat.com | redhat.com/openstack<br>
650.254.4025 | dsneddon:irc @dxs:twitter<br>
</div>
</span></font>
</body>
</html>