Presently, if something is wrong with the supplied tunneling interface, the following error will be raised by the neutron module:

Local ip for ovs agent must be set when tunneling is enabled /etc/puppet/environments/production/modules/neutron/manifests/agents/ovs.pp:32 on node maca25400702876.example.com

As an end user, this isn't particularly helpful to diagnose and resolve the root problem.  From my experience, this happens because:

1) The interface given by the user does not actually exist.  Particularly problematic with mismatched discovery image and device renaming (e.g. eth0 in discovery becomes ens1 under RHEL7 or something similar).

2) The interface is correct, but it does not have an IP address assigned.  Common if the interface is on an isolated network with no DHCP, and no address has been statically assigned.

Ultimately neutron is getting fed the ipaddress_[interface name] fact, and in both of these cases the fact ends up being empty.

So I'd propose, within quickstack:

1) Validate that the provided interface actually exists.  Check the interfaces fact, and if it's not a valid interface throw an error.

2) Throw an error if the interface does not have an ip address.  This would mostly be checking the result of this construct in various places of the code:

$local_ip = find_ip("$ovs_tunnel_network","$ovs_tunnel_iface","")

If $local_ip ends up being empty, fail the catalog with an error that the interface has no assigned ip address.

One last note is that the code also allows specifying networks instead of interfaces (though not directly through the staypuft wizard).  I've focused on the interface case now but we should also throw better errors if a network is given and no interfaces have an address on that network.