Bug 1258795 - [Docs] [Director] NeutronExternalBridgeConfiguration parsed as a dict, however, heat expects string
[Docs] [Director] NeutronExternalBridgeConfiguration parsed as a dict, howeve...
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation (Show other bugs)
7.0 (Kilo)
Unspecified Unspecified
medium Severity medium
: y1
: 7.0 (Kilo)
Assigned To: Dan Macpherson
: Documentation, Reopened
Depends On:
  Show dependency treegraph
Reported: 2015-09-01 06:10 EDT by Pawel Koniszewski
Modified: 2015-10-12 00:14 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-10-12 00:14:40 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Pawel Koniszewski 2015-09-01 06:10:32 EDT
Description of problem:
I'm trying to deploy setup with Neutron configured with vxlans. Documentation says that I should provide NeutronExternalBridgeConfiguration: # Set to "br-ex" if using floating IPs on native VLAN on bridge br-ex

So when I set this parameter in network-environment.yaml to:
  default: "br-ex"
  type: string
heat fails with an error that NeutronExternalNetworkBridge should be a string. 

This is what Heat received:
"NeutronExternalNetworkBridge": "{u'default': u'br-ex', u'type': u'string'}"

And this is what Heat expects:
"NeutronExternalNetworkBridge": "br-ex"

To workaround this issue I've added:
'NeutronExternalNetworkBridge': 'br-ex',
to dict of parameters in overcloud_deploy.py.

How reproducible:

Steps to Reproduce:
1. Add 
  default: "br-ex"
  type: string
To network-environment.yaml
2. Try to deploy overcloud with vxlans

Actual results:
Stack create failed, controllers failed to deploy.

Expected results:
Stack deployed successfully with network configured on br-ex
Comment 3 chris alfonso 2015-09-02 12:11:36 EDT
That is an illegal value you provided. The workaround you provided is the actual correct thing to do.
Comment 4 Pawel Koniszewski 2015-09-02 12:40:23 EDT
Chris, I'm sure that there is a bug somewhere basing on documentation (section


It says that default value for NeutronExternalNetworkBridge is:

NeutronExternalNetworkBridge: default: "''"

however it is not a legal value. It also says that it can be changed to:

NeutronExternalNetworkBridge: default: "br-ex"

and it is even worse. Correct value is:

  default: "br-ex"
  type: string

but the way it is parsed is wrong. Are you saying that user should MANUALLY edit overcloud_deploy.py to configure network on br-ex?

Marking back as a new bug as I don't understand explanation.
Comment 5 Zane Bitter 2015-09-02 13:21:27 EDT
That looks like a docs bug. The format you're trying to use is the way to specify the parameter schema in a template, but the environment only includes parameter *values*. Likely the error crept in while copying and pasting from one to the other. The docs should say:

    NeutronExternalNetworkBridge: "''"
Comment 7 Dan Sneddon 2015-09-02 13:34:20 EDT
(In reply to Pawel Koniszewski from comment #4)


You are correct, the documentation is incorrect. As mentioned, this should work:

  NeutronExternalNetworkBridge: "''"

I will work with the documentation team to get this corrected as soon as possible. Thanks for catching that and reporting the bug.
Comment 8 Pawel Koniszewski 2015-09-03 02:14:53 EDT
Thanks for the explanation, I will give it a shot.
Comment 9 Andrew Dahms 2015-09-03 02:40:10 EDT
Assigning to Dan for review.
Comment 12 Dan Macpherson 2015-09-08 21:48:07 EDT
I've pushed an update to the documentation with that changes the syntax of NeutronExternalNetworkBridge. The format is now just:

  # Set to "br-ex" if using floating IPs on native VLAN on bridge br-ex
  NeutronExternalNetworkBridge: "''"

This bug is also related: https://bugzilla.redhat.com/show_bug.cgi?id=1252433

Here are the links for both the Basic and Advanced Scenarios:



Pawel -- Does this fix correct the issues you're facing? Is there any further change required?
Comment 13 Dan Macpherson 2015-10-12 00:14:40 EDT
No feedback for a month. Closing this bug.

Note You need to log in before you can comment on or make changes to this bug.