Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RDO tickets are now tracked in Jira https://issues.redhat.com/projects/RDO/issues/

Bug 1059417

Summary:	Errors when setting CONFIG_NEUTRON_OVS_TUNNEL_IF to a VLAN interface
Product:	[Community] RDO	Reporter:	Mike Orazi <morazi>
Component:	openstack-foreman-installer	Assignee:	Jason Guiditta <jguiditt>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Ofer Blaut <oblaut>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	aortega, derekh, lars, morazi, yeylon
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openstack-foreman-installer-1.0.4-1.el6ost	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	1057938	Environment:
Last Closed:	2014-09-16 19:02:14 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1057938
Bug Blocks:

Description Mike Orazi 2014-01-29 20:14:47 UTC

+++ 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.

Comment 1 Jason Guiditta 2014-01-31 20:20:08 UTC

Lars has a patch for this that should be merged shortly

Comment 2 Jason Guiditta 2014-02-03 17:56:43 UTC

Merged 2 related patches:

https://github.com/redhat-openstack/astapor/pull/111
https://github.com/redhat-openstack/astapor/pull/112