Bug 1288207

# heat resource-list test-stack
ERROR: test_instance: networks networks: 0 0: port Value must be a string

^^ It is intersting that no heat resources can be pulled because of the state that this stack is in.

To recover "as a work around" you can delete all the resources "manually" and run the following in mysql: 

> update stack set status = "COMPLETE", status_reason = "Stack DELETE completed successfully", action = "DELETE", deleted_at = now()  where id = "STACK_ID";

- Note: STACK_ID needs to be replaced with your stack ID.

It seems that if you change: 

      port_id: { get_attr: [instance_port, port_name]}

to: 

      port_id: { get_attr: [instance_port, port_resource]}

You end up with a different issue/error but same "hung state" with the stack: 

The error is: 

StackValidationFailed: Property error : test_instance: networks Property error : networks: 0 Property error : 0: port Value must be a string

Resource CREATE failed: StackValidationFailed: Property error : test_instance: networks Property error : networks: 0 Property error : 0: port Value must be a string

https://bugzilla.redhat.com/show_bug.cgi?id=1288207#c2 still applies

Created attachment 1101988 [details]
Heat Templates used in testing

These heat temperates are triggered using the following: 

# heat stack-create -f heat-templates/samples/instance_and_network.yaml test-stack -P "image_name=RHEL7.2"

(In reply to Eric Rich from comment #4)
> It seems that if you change: 
> 
>       port_id: { get_attr: [instance_port, port_name]}
> 
> to: 
> 
>       port_id: { get_attr: [instance_port, port_resource]}
> 
> You end up with a different issue/error but same "hung state" with the
> stack: 
> 
> The error is: 
> 
> StackValidationFailed: Property error : test_instance: networks Property
> error : networks: 0 Property error : 0: port Value must be a string
> 
> Resource CREATE failed: StackValidationFailed: Property error :
> test_instance: networks Property error : networks: 0 Property error : 0:
> port Value must be a string
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1288207#c2 still applies

http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server-prop-networks-*-port does not seem to be correct in stating "Value must be of type neutron.port", based on the error it seems to be expecting a string!

First of all, there's a typo in network_port.yaml:

  port_resource:
    description: Port Resource
    value: {get_resouce: port}

because it says get_resouce instead of get_resource it's not recognised as an intrinsic function and just returns a map. That's why the error says that the value must be a string.

So both error messages on create are correct.

As for why it's hanging, it's difficult to say without more information, although it is likely fixed already in a later version. I really need:

* The version of heat-engine you're running
* The heat-engine log from /var/log/heat/
* Possibly the journal ("journalctl -u openstack-heat-engine.service")

(In reply to Zane Bitter from comment #7)
> First of all, there's a typo in network_port.yaml:
> 
>   port_resource:
>     description: Port Resource
>     value: {get_resouce: port}
> 
> because it says get_resouce instead of get_resource it's not recognised as
> an intrinsic function and just returns a map. That's why the error says that
> the value must be a string.
> 
> So both error messages on create are correct.

This corrects the issue creating the stack, however the bigger issue that remains is if "such a typo" is so simple to have and miss, it should not render a stack useless, or hung. 

> 
> As for why it's hanging, it's difficult to say without more information,
> although it is likely fixed already in a later version. I really need:
> 
> * The version of heat-engine you're running
> * The heat-engine log from /var/log/heat/
> * Possibly the journal ("journalctl -u openstack-heat-engine.service")

I will attach these logs so that the "hung" issue can be reviewed/corrected. 

To be honest, it simply seems like, more error checking is needed to validate that the stack could be deployed, before deploying it. Is this what 'preview' does?

I had a look at the problem.

It seems the typo mentioned above in network_port.yaml is again the issue, when we're trying to show/delete the task.

Server resource uses it for the 'networks' property.

 test_instance:
    depends_on: [ssh_key, tennant_network, security_group, instance_port]
    type: OS::Nova::Server
    properties:
      name: {get_param: instance_name}
      key_name: { get_attr: [ssh_key, key_name] }
      image: {get_param: image_name}
      flavor: {get_param: image_flavor}
      networks:
        - port: {get_attr: [instance_port, port_resource]} >>> here
      availability_zone: {get_param: az}

As 'port_resource' is not resolved and returns a map, 'get_attr' fails, when finding dependencies[1] for the server during delete/show.

[1] https://github.com/openstack/heat/blob/master/heat/engine/resources/openstack/nova/server.py#L953

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://rhn.redhat.com/errata/RHSA-2016-0266.html