[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:
Hi!
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.
heat/engine/clients/os/nova.py
================================
def _create(self):
endpoint_type = self._get_client_option('nova', 'endpoint_type')
management_url = self.url_for(service_type='compute',
endpoint_type=endpoint_type)
/heat/common/config.py
=====================================
# these options define baseline defaults that apply to all clients
default_clients_opts = [
cfg.StrOpt('endpoint_type',
default='publicURL',
============
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,
Attila
__________________________________________________________________________
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>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- 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