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" <att...@componentsoft.eu<mailto:att...@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-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
