[openstack-dev] [Heat] publicURL vs internalURL for resource validation

Randall Burt randall.burt at RACKSPACE.COM
Sat Oct 24 16:10:07 UTC 2015

This is a coin flip IMO. Heat can be deployed separately from other infrastructure.  If this does change, I'd like to see a fail over mechanism in the client plugin mechanism that will switch to the public URL if it can't access the private one.

-------- Original message --------
From: Matt Fischer
Date:10/24/2015 2:35 AM (GMT-06:00)
To: "OpenStack Development Mailing List (not for usage questions)"
Subject: Re: [openstack-dev] [Heat] publicURL vs internalURL for resource validation

>From an operations point of view I'd also prefer all service to service calls to go through the internalURL is there a reason it's not default?

On Oct 24, 2015 7:56 AM, "Attila Szlovencsak" <attila at componentsoft.eu<mailto:attila at componentsoft.eu>> wrote:

I am using Openstack Kilo (2015.1.1)
As I learned from the code, heat-engine uses the endpoint-type "publicURL",
when validating templates. I also see that I can override that from
heat.conf via [clients_XXX]/endpoint_type.

    def _create(self):
        endpoint_type = self._get_client_option('nova', 'endpoint_type')
        management_url = self.url_for(service_type='compute',

# these options define baseline defaults that apply to all clients
default_clients_opts = [

My questions:

1. Shouldn't we use the  interalURL instead as default?  In a typical case,
the controller node sits behind a load-balancer, and IP for the publicURLs
are held by the load-balancer. The controller node (so heat-engine) might
not have access to the publicURL at all.

2. Instead of creating and "endpoint_type" entry in heat.conf for each and
every service,  is there a simpler way to force using the internalURL?

Thanks in advance,

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151024/ec7eb339/attachment.html>

More information about the OpenStack-dev mailing list