Red Hat Bugzilla – Bug 1258795
[Docs] [Director] NeutronExternalBridgeConfiguration parsed as a dict, however, heat expects string
Last modified: 2015-10-12 00:14:40 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: NeutronExternalNetworkBridge: 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: 100% Steps to Reproduce: 1. Add NeutronExternalNetworkBridge: 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
That is an illegal value you provided. The workaround you provided is the actual correct thing to do.
Chris, I'm sure that there is a bug somewhere basing on documentation (section 6.2.5.2): https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/7/html/Director_Installation_and_Usage/sect-Scenario_2_Using_the_CLI_to_Create_a_Basic_Overcloud.html#sect-Isolating_the_External_Network 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: NeutronExternalNetworkBridge: 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.
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: "''"
Currently the docs recommend[1] NeutronExternalNetworkBridge: default: "''" So that'll need to be fixed up. [1]: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/7/html/Director_Installation_and_Usage/sect-Advanced-Scenario_3_Using_the_CLI_to_Create_an_Advanced_Overcloud_with_Ceph_Nodes.html#sect-Advanced-Isolating_all_Networks_into_VLANs
(In reply to Pawel Koniszewski from comment #4) Pawel, You are correct, the documentation is incorrect. As mentioned, this should work: parameter_defaults: NeutronExternalNetworkBridge: "''" I will work with the documentation team to get this corrected as soon as possible. Thanks for catching that and reporting the bug.
Thanks for the explanation, I will give it a shot.
Assigning to Dan for review.
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: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/7/html/Director_Installation_and_Usage/sect-Scenario_2_Using_the_CLI_to_Create_a_Basic_Overcloud.html#sect-Isolating_the_External_Network https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/7/html/Director_Installation_and_Usage/sect-Advanced-Scenario_3_Using_the_CLI_to_Create_an_Advanced_Overcloud_with_Ceph_Nodes.html#sect-Advanced-Isolating_all_Networks_into_VLANs Pawel -- Does this fix correct the issues you're facing? Is there any further change required?
No feedback for a month. Closing this bug.