+++ This bug was initially created as a clone of Bug #1288207 +++ Description of problem: The error presents its self as: (curing a stack creation - that ends with a failure) BadRequest: Invalid input for port_id. Reason: 'test-stack-instance_port-kz2mdpj4wbpq-port-5etr6o77ho7f' is not a valid UUID. ... instance_port: type: ../foundations/network_port.yaml depends_on: [security_group, tennant_network] properties: network_name: {get_attr: [tennant_network, name]} subnet_id: {get_attr: [tennant_network, subnet_id]} security_group_name: {get_attr: [security_group, name]} ... instance_floating_ip: type: OS::Neutron::FloatingIP depends_on: [instance_port] properties: floating_network: { get_param: external_network } port_id: { get_attr: [instance_port, port_name]} ## Here is where # the failure is ... The template results in the error above however, upon stack delete the delete never processes. Version-Release number of selected component (if applicable): 7.0 How reproducible: 100% Additional info: The only way, currently found to recover is to delete the resources, and then remove the entries in the database by hand, for the stack. --- Additional comment from Rabi Mishra on 2016-01-14 02:40:18 EST --- 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
managed to reproduce by mistake. since it happens now when the templates were full of errors, I am reopening on a low severity as there is little chance we will see it later.
thanks Rabi, looked the same but not the same issue.
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/RHEA-2016-0603.html