Bug 1054117

> Description of problem:
> 
> Under neutron networker host groups, the following parameters are being
> removed 
> each time i enter the host group page:
issue happens in compute neutron as well.
>  
> 
> ovs_bridge_mappings
> ovs_bridge_uplinks
> 
> 
> How reproducible:
> 
> 
> Steps to Reproduce:
> 1.override both 
> ovs_bridge_mappings & ovs_bridge_uplinks parameters in neutron networker
> host group and submit
as well as compute neutron.

> 2.exit the host group page and revisit 
> 3. these parameters will be empty again. ( issue is not seen with other
> parameters )
these parameters are not being used in 
/etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini 
on both network controller  and compute
> 
> 
> 
> Actual results:
> 
> 
> Expected results:
> 
> 
> Additional info:

I just tried this on a fully working setup installed yesterday, and was not able to replicate the error.  I will create a fresh setup here from the latest release and test once more to see if I can replicate.

After further discussion, this appears to be an issue of it not being clear to the user how to format the expected value.  Closing as not a bug, though perhaps one should be opened to make sure this is described in the official documentation?  I'll try to add these parameters with description to the upstream wiki [1] for now.

http://openstack.redhat.com/Deploying_RDO_Using_Foreman#Neutron_with_Networker_Node

The main issue here is that there are different formats in neutron parameters

User experience is not intuitive at all and will cause lots of problems.
 

for example: 

external_network_bridge:br-ex
ovs_vlan_ranges:inter-vlan:196:203,ext-vlan:195:195
ovs_bridge_mappings: ["inter-vlan:br-eth3","ext-vlan:br-ex"]
ovs_bridge_uplinks:["br-eth3:eth3","br-ex:eth3.195"]

1. There is no input validation, and user can make mistake very easily.

When i have used 
ovs_bridge_uplinks = br-eth3:eth3 - succeeded but disappeared from GUI
ovs_bridge_uplinks = [br-eth3:eth3] - failed
ovs_bridge_uplinks:["br-eth3:eth3"],["br-ex:eth3.195"] - succeeded but bad ports names bridges will be used 

2. other ranges like vlan range doesn't requires any brackets and quotation
 using external_network_bridge with quotation "br-ex" will fail on the L3 agent operation .

This should really be handled as a follow-on effort when the foreman plugins/dynamic hostgroup solutions are planned.

I struggled to make it work for automation : some of this neutron parameters have 'type = array' which requires "[]" and a certain format in the API as well.

The problem is that the format of parameters is inconsistent. I would suggest to add tool-tip + a link to parameters-documentation under 'help', 
 

Example: API for editing parameter with type=array : 
--------------------------------------------------- 
ovs_bridge_uplinks : br-eth3:eth3

curl -s -H "Accept:application/json,version=2" -k -u admin:changeme https://${FOREMAN_IP}/api/puppetclasses/quickstack::neutron::compute/smart_class_parameters/ovs_bridge_uplinks -X PUT
 -H "Content-Type: application/json" -d {\"default_value\":[\"br-eth3:eth3\"]} -o -

I understand your frustration, and we can see if there are things we can do to make this more obvious over time, but really, I think the only thing we can do right now is to document expected usage in our official documentation.  Also, part of the issue is that what you are looking at in foreman is much different than what you may be used to from packstack.  Foreman is a very thin wrapper on puppet, so you are seeing exactly the parameters puppet uses, whereas packstack is more of a wrapper that sort of abstracts away this fact, so you are in less direct contact with the configuration.  The parameters we expose in our hostgroups are just a layer to collect everything the underlying openstack puppet modules need to do their configuration (with a few exceptions, but none apply here).  So for this example, the puppet code we rely on specifies ovs_bridge_mappings and ovs_bridge_uplinks as arrays, whereas the vlan_ranges parameter has a default of 'undef'.  The code (again, code we are consuming, not code we own/have written) then just stuffs whatever value you specified into the config file.  To this point, we have generally just taken the type expected in the underlying puppet code, and set our parameters on the hostgroups to match that expectation.

Hi  Jason

Another item i encountered as well is ovs_tunnel_types =[]

i have used ovs_tunnel_types = vxlan , it passed the GUI , but cause the L2 agent to fail

"2014-02-19 12:00:51.460 12223 ERROR neutron.plugins.openvswitch.agent.ovs_neutron_agent [-] (u'Invalid tunnel type specificed: %s', '') Agent terminated!
2014-02-19 12:07:45.561 13031 ERROR neutron.plugins.openvswitch.agent.ovs_neutron_agent [-] (u'Invalid tunnel type specificed: %s', '') Agent terminated!
"

ovs_tunnel_types =[vxlan] worked

is this still relevant?

This should be addressed and hidden behind rhel-osp-installer.