This is really a Horizon bug but I can't find a BZ component for that at the moment, so assigning to python-heatclient for now.

I think the Right Thing here would be to treat relative paths as relative to the template. I'm not sure why it isn't doing that.

There is a problem with the way I passed the environment in the original bug post.
I misunderstood this to be the overcloudrc file but its not !!


For now a good workaround is to do this :
use resource_registry.

Example of a commandline and files using resource regstry is the following

CLI:

openstack stack create wordpress -f yaml -t http://10.3.9.250/templates/heat_app.yaml  -e http://10.3.9.250/templates/env.yaml

the contents of the heat_app template is this:

heat_template_version: 2013-05-23
 
description: Template that installs a wordpress server and supporting MySQL database running on separate servers

parameters:
  image:
    type: string
    label: Image name or ID
    description: Image to be used for server. Please use an Ubuntu based image.
    default: trusty-server-cloudimg-amd64
  flavor:
    type: string
    label: Flavor
    description: Type of instance (flavor) to be used on the compute instance.
    default: m1.small
  key:
    type: string
    label: Key name
    description: Name of key-pair to be installed on the compute instance.
    default: stack 
  private_network:
    type: string
    label: Private network name or ID
    description: Network to attach server to.
    default: test 
 
resources:
  mysql:
 #   type: lib/mysql.yaml
    type: Lib::MSG::MySQL
    properties:
      image: { get_param: image }
      flavor: { get_param: flavor }
      key: { get_param: key }
      private_network: { get_param: private_network }
      database_name: wordpress
      database_user: wordpress_user
 
  wordpress:
#    type: lib/wordpress.yaml
    type: Lib::MSG::Wordpress
    properties:
      image: { get_param: image }
      flavor: { get_param: flavor }
      key: { get_param: key }
      private_network: { get_param: private_network }
      mysql_server: { get_attr: [mysql, ip] }
      database_name: wordpress
      database_user: wordpress_user
      database_password: { get_attr: [mysql, database_password] }


and the env file is this:

resource_registry:
  Lib::MSG::MySQL: http://10.3.9.250/templates/lib/mysql.yaml
  Lib::MSG::Wordpress: http://10.3.9.250/templates/lib/wordpress.yaml

With this method the same templates can be used for CLI or via the dashboard;

Image attached with the dashboard:
<workaround.jpg>

There is a problem with the way I passed the environment in the original bug post.
I misunderstood this to be the overcloudrc file but its not !!


For now a good workaround is to do this :
use resource_registry.

Example of a commandline and files using resource regstry is the following

CLI:

openstack stack create wordpress -f yaml -t http://10.3.9.250/templates/heat_app.yaml  -e http://10.3.9.250/templates/env.yaml

the contents of the heat_app template is this:

heat_template_version: 2013-05-23
 
description: Template that installs a wordpress server and supporting MySQL database running on separate servers

parameters:
  image:
    type: string
    label: Image name or ID
    description: Image to be used for server. Please use an Ubuntu based image.
    default: trusty-server-cloudimg-amd64
  flavor:
    type: string
    label: Flavor
    description: Type of instance (flavor) to be used on the compute instance.
    default: m1.small
  key:
    type: string
    label: Key name
    description: Name of key-pair to be installed on the compute instance.
    default: stack 
  private_network:
    type: string
    label: Private network name or ID
    description: Network to attach server to.
    default: test 
 
resources:
  mysql:
 #   type: lib/mysql.yaml
    type: Lib::MSG::MySQL
    properties:
      image: { get_param: image }
      flavor: { get_param: flavor }
      key: { get_param: key }
      private_network: { get_param: private_network }
      database_name: wordpress
      database_user: wordpress_user
 
  wordpress:
#    type: lib/wordpress.yaml
    type: Lib::MSG::Wordpress
    properties:
      image: { get_param: image }
      flavor: { get_param: flavor }
      key: { get_param: key }
      private_network: { get_param: private_network }
      mysql_server: { get_attr: [mysql, ip] }
      database_name: wordpress
      database_user: wordpress_user
      database_password: { get_attr: [mysql, database_password] }


and the env file is this:

resource_registry:
  Lib::MSG::MySQL: http://10.3.9.250/templates/lib/mysql.yaml
  Lib::MSG::Wordpress: http://10.3.9.250/templates/lib/wordpress.yaml

With this method the same templates can be used for CLI or via the dashboard;

Image attached with the dashboard:
<workaround.jpg>

The original issue still stands about inconsistency between the CLI and the dashboard.

but this is just a workaround half the way since the env.yaml doesn't have the option to come from a "url" but only direct or file.

So if this is a BUG or an RFE

* Relative paths of the files should be handled consistently
* the environment file should have an option of being a url as well.

Created attachment 1221657 [details]
workaround image with the env used correctly

I opened the attached bug against Horizon.

I found an older bug for this issue: https://bugs.launchpad.net/horizon/+bug/1467781

I verified that get_file is handled correctly as per lp#1512564, but I can't verify this works with the original user templates, because the user didn't attach them, and the addresses mentioned in the bug report don't work.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:3462