+++ This bug was initially created as a clone of Bug #1057938 +++ As reported on ask.openstack.org: https://ask.openstack.org/en/question/10810/in-ethernet-device-name-causing-packstack-parse-error/ Setting CONFIG_NEUTRON_OVS_TUNNEL_IF to a VLAN defice (such as "eth0.1200") will result in packstack generating a manifest that attempts to reference `$ipaddress_eth0.1200`, which is an invalid variable/fact name. Facter converts the `.` in the interface name to `_`, so the corresponding fact is `ipaddress_eth0_1200`. Either packstack or the Puppet modules should take care of performing the appropriate transliteration. --- Additional comment from Lars Kellogg-Stedman on 2014-01-25 23:23:08 EST --- The same problem affects foreman users. --- Additional comment from Martin Magr on 2014-01-27 09:19:20 EST --- This cannot be fixed on module level. Both packstack and foreman have to have valid manifests. --- Additional comment from Lars Kellogg-Stedman on 2014-01-27 10:36:08 EST --- Martin, I agree with second part of comment #2, but I'm not sure what you mean by "this cannot be fixed on the module level". --- Additional comment from Lars Kellogg-Stedman on 2014-01-29 11:10:03 EST --- This same problem also affects the Swift templates. From jjozwiak: > When deploying Swift storage the 'swift_local_interface' was similar > where it needed to be em2_102. --- Additional comment from Lars Kellogg-Stedman on 2014-01-29 14:37:17 EST --- Proposed fix for astapor in https://github.com/redhat-openstack/astapor/pull/109. --- Additional comment from Lars Kellogg-Stedman on 2014-01-29 14:57:55 EST --- Proposed fix for packstack in https://github.com/stackforge/packstack/pull/10.
Lars has a patch for this that should be merged shortly
Merged 2 related patches: https://github.com/redhat-openstack/astapor/pull/111 https://github.com/redhat-openstack/astapor/pull/112