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.
The same problem affects foreman users.
This cannot be fixed on module level. Both packstack and foreman have to have valid manifests.
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".
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.
Proposed fix for astapor in https://github.com/redhat-openstack/astapor/pull/109.
Proposed fix for packstack in https://github.com/stackforge/packstack/pull/10.
Updated fix at https://github.com/stackforge/packstack/pull/11 also handles "-" in interface names.
Lars thanks for a patch! But could you please submit the patch to Gerrit? We don't accept pull requests. Thanks in advance.
For more info check https://wiki.openstack.org/wiki/Gerrit_Workflow
I'm familiar with launchpad's Gerrit workflow, but I wasn't aware that was the primary site for the stackforge repositories. Thanks.
Fix proposed in https://review.openstack.org/#/c/73060/
Proposed fix for packstack in https://review.openstack.org/#/c/99749/