can't deploy underclouds with VLAN API endpoints

[Robert Collins]

Given
NeutronPublicInterface=vlan25
NeutronPublicInterfaceIP=138.35.77.4/25
NeutronPublicInterfaceRawDevice=eth2

What we get is
eth2 - dhcp
vlan25 - bound to eth2
br-ctlplane - static ip of 138.35.77.4

To deploy an undercloud with a VLAN API endpoint, we need some way to end up with:
br-ctlplane - DHCP, one port (eth2)
vlan25 layered on top of br-ctlplane with static IP of 138.35.77.4

[Robert Collins (lifeless)]

More detail - tripleo-cd.sh which was our overcloud deploy script before we got CI looped in and disabled it to avoid breaking CI...

has this:
devtest_overcloud.sh vlan25 138.35.77.4/25 eth2 138.35.77.1
which translates to
NeutronPublicInterface=vlan25
...IP=138.35.77.4/25
..RawDevice=eth2
...DefaultRoute=138.35.77.1

before 06ef9918aa63e675c0197ed934e68e21e8572f7c
vlan25 is setup by init-neutron-ovs itself :
if [ -n "$PHYSICAL_INTERFACE_RAW_DEVICE" ]; then
  if ! (ip link show dev $PHYSICAL_INTERFACE) ; then
    VLAN_ID=$(echo $PHYSICAL_INTERFACE | sed s/vlan//)
    vconfig set_name_type VLAN_PLUS_VID_NO_PAD
    vconfig add $PHYSICAL_INTERFACE_RAW_DEVICE $VLAN_ID
  fi
  ip link set $PHYSICAL_INTERFACE up
fi

which hasn't changed - note that that *does not* move IP addresses around so far.

Then the IP address supplied, if it existed, was *added* - not replaced, *added*, to the interface - so to the vlan25.

then init-neutron-ovs calls ensure bridge with
br-ex vlan25 138.35.77.4/25 138.35.77.1

The old behaviour was to:
1) ensure that the interface is in the bridge device (so vlan25 is in br-ex)
2) move all ip addresses from the interface to the bridge. So the supplied IP ends up on the bridge, and the original DHCP ip on eth2 is untouched. [My description of the bug is clearly wrong].
3) if a default route was supplied, apply it

The new behaviour is to:
1) setup definitions for a bridge on the vlan device
2) treat the public ip address as a static ip address and define it on the bridge
3) ifdown and ifup things

From this I conclude that we never had the old behaviour I thought we did, and the undercloud deployments were special snowflakes.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/103449

[OpenStack Infra (hudson-openstack)]

Change abandoned by James Polley (<email address hidden>) on branch: master
Review: https://review.openstack.org/103039
Reason: The changes here have been merged into 101438 - I9649ee74ebaf62b6b929b28243a07c789a08867c

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/101438
Committed: https://git.openstack.org/cgit/openstack/tripleo-heat-templates/commit/?id=5def125573552ec34b0d4a837873b1e91c4e295d
Submitter: Jenkins
Branch: master

commit 5def125573552ec34b0d4a837873b1e91c4e295d
Author: James Polley <email address hidden>
Date: Fri Jun 20 17:28:57 2014 +1000

    Define and bind a public virtual IP

    Prior to this change our heat templates define one virtual IP, which all
    the services are bound to.

    We wish to be able to segregate these endpoints: some need to be
    accessible to "the public"; some are only intended to be accessed within
    the cloud; some are only for admin use.

    This change adds a second VIP which we can use for binding only the
    endpoints that are intended to be publicly accessible, leaving the older
    VIP to be used for internal end points.

    Haproxy is told to also listen on that new VIP so that we can expose selected
    services via the new VIP, and keepalived is in charge of assigning the VIP to
    control plane nodes.

    This change has a proposed split of services between control-only and
    control+public interfaces. Assuming our yaml parsers (in merge.py and
    Heat) understand YAML anchors/aliases, and assuming I've got the syntax
    right, this should get expanded so that all the control+public services
    get their config defined from the same block without needing to repeat
    it for each service. (AFAICT both merge.py and heat use pyyaml, which
    does support aliases/anchors)

    The default is left at binding to only the controlplane interface, so
    that new services added to this map will default to being internal-only

    This patchset partially completes a spec which will one day live at
    https://blueprints.launchpad.net/tripleo/+specs/tripleo-juno-virtual-public-ips
    but for now can bee seen in Id9addc65f0d2ed519ce4b3edbd561ed660a2786e

    Implements: blueprint tripleo-juno-virtual-public-ips
    Change-Id: I9649ee74ebaf62b6b929b28243a07c789a08867c
    Co-Authored-By: Robert Collins <email address hidden>
    Partial-Bug #1325114

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/103449
Committed: https://git.openstack.org/cgit/openstack/tripleo-image-elements/commit/?id=48c1290c339e7497ac5f8e73cac70b674e12f5cf
Submitter: Jenkins
Branch: master

commit 48c1290c339e7497ac5f8e73cac70b674e12f5cf
Author: Robert Collins <email address hidden>
Date: Mon Jun 30 15:25:25 2014 +1200

    Fix issues with provider networks and public ips

    The current public IP address implementation layers a VLAN access port
    underneath the exterior bridge - br-ex/br-ctlplane. This prevents the
    use of Neutron provider network tagging because the access port
    overrides everything.

    Instead, put public IP addresses in an access port on top of br-ex,
    allowing provider networks to be tagged by Neutron openflow rules.

    As part of this we allow a new non-default route, so that IPMI
    connectivity is not lost when the default route is put onto a VLAN.
    This is only needed for the seed - the undercloud can receive this via
    DHCP.

    The change is backwards compatible - though the old method really is
    broken so I've marked it as deprecated in the docs and the code.

    We will need to change our heat templates and then incubator glue code
    to use the new option before the bug can be closed.

    Partial-Bug #1325114

    Change-Id: I3f77f72ac623792e844dbb4d501b6ab269141f8e

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/103757
Committed: https://git.openstack.org/cgit/openstack/tripleo-incubator/commit/?id=1abcb5fe3b56666288531a21dd17732d1bd8cba2
Submitter: Jenkins
Branch: master

commit 1abcb5fe3b56666288531a21dd17732d1bd8cba2
Author: Robert Collins <email address hidden>
Date: Tue Jul 1 18:56:10 2014 +1200

    Add public VLAN support.

    This patch adds the ability to bring up a VLAN on the seed, undercloud and
    overcloud control plane nodes. This feature was sort-of working in the past
    but the vconfig based configuration broke provider networks due to layering
    under the bridge device rather than over it. In this revised version we use
    Neutron to manage and allocate IP addresses on the VLAN, though of course
    we found some limitations in Heat when doing this :).

    This is not really fully documented yet but is otherwise believed to be
    feature complete.

    Change-Id: I78c0fa3902c1e480b7ada0055332b14828c3c7f9
    Co-Authored-By: Derek Higgins <email address hidden>
    Co-Authored-By: James Polley <email address hidden>
    Co-Authored-By: Steve Kowalik <email address hidden>
    Closes-Bug: #1325114