Bug 1235848

Summary:	vip.yaml missing interface parameter for ControlPlaneNetwork
Product:	Red Hat OpenStack	Reporter:	Dan Sneddon <dsneddon>
Component:	openstack-tripleo-heat-templates	Assignee:	Dan Sneddon <dsneddon>
Status:	CLOSED ERRATA	QA Contact:	Marius Cornea <mcornea>
Severity:	high	Docs Contact:
Priority:	high
Version:	7.0 (Kilo)	CC:	dmacpher, dsneddon, mburns, morazi, rhel-osp-director-maint, rrosa
Target Milestone:	ga
Target Release:	Director
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	openstack-tripleo-heat-templates-0.8.6-26.el7ost	Doc Type:	Bug Fix
Doc Text:	Deployments with the director plans behaved differently to Heat template-based deployments due to a missing ControlPlaneNetwork parameter. This caused plan-based Overcloud deployments to fail when using network isolation. This fix includes a patch to include the ControlPlaneNetwork parameter. Now the Overcloud deploys properly.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-08-05 13:56:34 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:
Bug Blocks:	1235803

Description Dan Sneddon 2015-06-25 22:12:19 UTC

Description of problem:
Tuskar is being very picky about the parameters in the network/ports/vip.yaml file. Heat is fine with the fact that this file is missing ControlPlaneNetwork (because it's not used in the file), but Tuskar refuses to deploy.

Version-Release number of selected component (if applicable):
2015-06-25.2

How reproducible:
100%

Steps to Reproduce:
1. Try to deploy with -e <environment_file> and --plan-uuid
2.
3.

Actual results:
ERROR: openstack ERROR: Unknown Property ControlPlaneNetwork

Expected results:
The overcloud should deploy

Additional info:
This is going to require a patch to the vip.yaml template. I am submitting a patch upstream right now.

Comment 3 Dan Sneddon 2015-06-25 22:13:29 UTC

The impact of this is somewhat limited. It means that the redis_vip can only live on the control plane when using network isolation. We should be able to put the redis_vip on the internal API network, but until the vip.yaml is patched it will have to live on the ctlplane network.

Comment 4 Dan Sneddon 2015-06-30 23:45:03 UTC

I have an upstream patch for this which is in review now, not quite ready to merge.

https://review.openstack.org/#/c/196400/

Comment 5 Mike Burns 2015-07-01 11:23:11 UTC

Dan,

Is the patch needed?  I thought this worked with tuskar now without a patch?

Comment 6 Mike Burns 2015-07-01 20:32:06 UTC

(In reply to Mike Burns from comment #5)
> Dan,
> 
> Is the patch needed?  I thought this worked with tuskar now without a patch?

Yes, this is needed.  There is still a bug in this area.

Comment 7 Jay Dobies 2015-07-06 14:48:33 UTC

Mike - You can include this in the next downstream build.

Comment 8 Jay Dobies 2015-07-06 15:17:13 UTC

Mike - Change of plans, don't include this yet.

Comment 9 Dan Sneddon 2015-07-07 17:10:31 UTC

The upstream fix for this was merged upstream.

https://review.openstack.org/#q,Ic20281e58a1130afe18d5aec505a3df199841fd5,n,z

Comment 12 errata-xmlrpc 2015-08-05 13:56:34 UTC

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://access.redhat.com/errata/RHEA-2015:1549