A fresh deploy of newton using the old external net config is broken

[Andreas Hasenack]

Newton cloud, deployed with juju 2.0GA and next charms using the autopilot on MAAS 1.9.x.

cs:~openstack-charmers-next/xenial/neutron-gateway-261
cs:~openstack-charmers-next/xenial/neutron-api-268
openstack-origin: cloud:xenial-newton

This deployment was done using ext-port, not the new bridge-mappings introduced in the 16.07 openstack charms.

Instance comes up, floating ip is attached, but can't be connected to.

tcpdump shows that the ARP request arrives at the br-ex bridge on neutron-gateway/0, but nothing answers. It also does not arrive at the router namespace where the instance lives.

I then removed the networks, subnets and routers and changed these charm options, according to https://wiki.ubuntu.com/OpenStack/OpenStackCharms/ReleaseNotes1607#External_Network_Update:

neutron-gateway:
- ext-port: had a list of mac addresses, was changed to empty
- data-port=br-data:eth1. I had to remove eth1 from the br-ex OVS bridge before this would work. The charm just tried to add eth1 to br-data and that failed because eth1 was still part of br-ex. Note the autopilot uses mac addresses instead of interface names, I didn't check if that would work (i.e., br-data:aa:bb:cc:dd:ee:ff instead of br-data:eth1)
- bridge-mappings was left at the default value of physnet1:br-data.
neutron-api:
- flat-network-providers=physnet1

Then I created the networks and routers again but using the flat network provider:
neutron net-create --provider:network_type flat --provider:physical_network physnet1 --shared --router:external=true $ext_net
(script I used is attached)

After this I could connect to the instance via its floating ip.

[Andreas Hasenack (ahasenack)]

"ovs-vsctl show" on neutron-gateway/0 after the deployment.

gnuoy's comment:
<gnuoy> andreas, there is a patch missing between br-ex and br-int

[Andreas Hasenack (ahasenack)]

ovs-vsctl show on neutron-gateway/0 after making the changes to use bridge-mappings for external networking. In this state, the instance can be connected to via its floating ip.

[Andreas Hasenack (ahasenack)]

script I used to create the neutron networks

[Jason Hobbs (jason-hobbs)]

OpenStack team - can you please comment on whether this is a bug in the charms that will be fixed or if this is a change going forward starting with newton?

[James Page (james-page)]

I suspect the switch in default here:

  https://github.com/openstack/neutron/commit/3f71a49e0f0603175e0d0f599ab4d73118b0e85a

is the root cause of the deprecated style of networking no longer working with the neutron-gateway charms. This change was introduced during the newton cycle, so would bisect with the reported behaviour for newton clouds.

[James Page (james-page)]

Note that the configuration option that supports the deprecated behaviour is scheduled for removal in Ocata, so end-users really do need to update to using the new style of external network configuration as supported (and tested) by default in the charms.

[James Page (james-page)]

Snippet from l3-agent template:

{% if external_configuration_new -%}
gateway_external_network_id =
external_network_bridge =
{% elif ext_net_id %}
gateway_external_network_id = {{ ext_net_id }}
{% endif -%}

external_configuration_new is set when the charm is configured in the preferred, new style of external networking. As the default in newton is '', when the charm is configured in the deprecated way, the external_network_bridge value will still be ''.

[James Page (james-page)]

Upgrade could be tricky:

The default value for ‘external_network_bridge’ has been changed to ‘’ since that is the preferred way to configure the L3 agent and will be the only way in future releases. If you have not explicitly set this value and you use the L3 agent, you will need to set this value to ‘br-ex’ to match the old default. If you are using ‘br-ex’, you should switch to ‘’, ensure your external network has a flat segment and ensure your L2 agent has a bridge_mapping entry between the external network’s flat segment physnet and ‘br-ex’ to get the same connectivity. If the external network did not already have the flat segment, you will need to detach all routers from the external networks, delete the incorrect segment type, add the flat segment, and re-attach the routers.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/400363
Committed: https://git.openstack.org/cgit/openstack/charm-neutron-gateway/commit/?id=2a89032bbd4ae9519da117b31c6d02f497f710af
Submitter: Jenkins
Branch: master

commit 2a89032bbd4ae9519da117b31c6d02f497f710af
Author: James Page <email address hidden>
Date: Mon Nov 21 17:50:21 2016 +0000

    newton: legacy external networking support

    For OpenStack Newton, the external network bridge configuration
    default switched from br-ex to '' inline with the preferred
    method of configuring external networks using provider networks
    via the l2 agent (instead of the l3 agent).

    This had the side effect of breaking support for legacy style
    networking.

    Set:

      external_network_bridge = br-ex

    in the event that new style external networking is not being used
    to preserve backwards compatibility for now.

    Note that this option will be removed in Ocata, so environments
    need to upgrade to the preferred method of external networking in
    order to stay supported.

    Change-Id: Id929c0fa9baa0ecf0168d4d08f93939b56f847ab
    Closes-Bug: 1634966