Bug 1258107

I think similar steps to what we looked at on Friday is a good start:

1. First make sure that any scripts you are using to patch the tripleo heat templates are working. Look at /usr/share/openstack-tripleo-heat-templates and make sure that they look ok (i.e. patched according to your needs)

2. If these are ok ^^^ but config isn't applying then check on the controller(s) for any errors during for example the puppet run (or application of any other config). Did the stack create OK? If not which resource failed. If it was a compute resource then also look on the compute note for any traceback/clues.

3. Could this be a product of the ml2 package install issue at https://bugzilla.redhat.com/show_bug.cgi?id=1258106 (don't know enough at this point about what is being installed by the package but could it be that if installed correctly we don't hit this?)

thanks

Writing of the config in OSPd context shouldn't depend on the Big Switch ML2 plugin package installation. But i second that 1. and 2. are things to look at.

The [restproxy] section is actually get configured. However the "parameters" part in 
bigswitch-config.yaml did not get configured.

cat ../templates/bigswitch-config.yaml
# A Heat environment file which can be used to enable Big Switch
# extensions, configured via puppet
resource_registry:
  OS::TripleO::ControllerExtraConfigPre: ../puppet/extraconfig/pre_deploy/controller/neutron-bigswitch.yaml

parameters:
  ExtraConfig:
    neutron_ovs_use_veth: true                          <<< this is not applied
    NeutronMechanismDrivers: openvswitch, bsn_ml2       <<< nor this

parameter_defaults:
  # Required to fill in:
  NeutronBigswitchRestproxyServers: 10.8.68.11:8000,10.8.68.12:8000
  NeutronBigswitchRestproxyServerAuth: admin:adminadmin

  # Optional:
  NeutronBigswitchRestproxyAutoSyncOnFailure: True
  NeutronBigswitchRestproxyConsistencyInterval: 10
  NeutronBigswitchRestproxyNeutronId: neutron
  NeutronBigswitchRestproxyServerSsl: True
  NeutronBigswitchRestproxySslCertDirectory: /var/lib/neutron

The parameters section should look like this (moved NeutronMechanismDrivers a level up and removed the space after the comma):

parameters:
  ExtraConfig:
    neutron_ovs_use_veth: true
  NeutronMechanismDrivers: openvswitch,bsn_ml2

However at least the ovs_use_veth setting should have gotten applied. Let's debug together on the call.

Did it work after you corrected the params section?

To summarize what we found so far:
1. [restproxy] portion of ml2_conf.ini, which specifies Big Switch controller information, is correctly configured.
2. ovs_use_veth = True is NOT configured in l3_agent.ini and dhcp_agent.ini. The reason is that the code is in upstream but not in osp product. @Jiri is going to do the backporting.
3. We haven't got the chance to try out @Jiri's proposal about NeutronMechanismDrivers. Will try it out today.

With Jiri's suggestion, by fixing NeutronMechanismDrivers' indentation, bsn_ml2 is configured in ml2_conf.ini. However, ovs_use_veth is still false, even when I manually apply the patch at https://github.com/jistr/tripleo-bigswitch-temporary-setup/pull/2

Was the bigswitch config patch updated from patchset 2 to patchset 3 as suggested [1]?

[1] https://github.com/jistr/tripleo-bigswitch-temporary-setup/pull/2#issuecomment-137223131

Here is the latest update about configuration problems.
1. ovs_use_veth is still false even though we applied patchset 3 at https://github.com/jistr/tripleo-bigswitch-temporary-setup/pull/2#issuecomment-137223131
2. In dhcp_agent.ini, both enable_isolated_metadata and enable_isolated_metadata are all false. This cause a vm cannot gets its metadata when its network is not attached to a router. We've discussed this before (https://bugzilla.redhat.com/show_bug.cgi?id=1254685). For the short term, we need to add Giulio's workaround in our script as well.
3. I notice that when l3_ha is true in neutron.conf, any change to floating ip causes l3 connectivity problem. The behavior is similar to https://bugzilla.redhat.com/show_bug.cgi?id=1181592, however, I didn't spend much time to figure out the root cause. On the other hand, if l3_ha is false, we don't have any problem with l3 connectivity and floating ip.

Re 1., i was able to reproduce this, it is caused by a known bug in CLI:

https://bugzilla.redhat.com/show_bug.cgi?id=1245737#c7

Since we only need this setting on controllers, i was able to fix the situation locally by using controllerExtraConfig instead. Please try amending the parameters section like this:

parameters:
  controllerExtraConfig:
    neutron_ovs_use_veth: true
  NeutronMechanismDrivers: openvswitch,bsn_ml2

On my environment the ovs_use_veth setting then got propagated:

[root@overcloud-controller-0 ~]# grep ^ovs_use_veth /etc/neutron/l3_agent.ini 
ovs_use_veth = True

Re 2., we can try:

parameters:
  controllerExtraConfig:
    neutron_ovs_use_veth: true
    neutron::agents::dhcp::enable_isolated_metadata: true
    neutron::agents::dhcp::enable_metadata_network: true
  NeutronMechanismDrivers: openvswitch,bsn_ml2

Jiri, the proposed solution works. However there is one missing configure:
in dhcp_agent.ini, the ovs_use_veth is still false. Can we do something similar to make it true as well?

Yes, i updated https://review.openstack.org/213142 and tested it:

[root@overcloud-controller-0 ~]# grep ^ovs_use_veth /etc/neutron/dhcp_agent.ini 
ovs_use_veth = True

Just verified, ovs_use_veth in dhcp_agent.ini got the correct configuration. We can close this bugzilla now.