Description of problem:
The current templates for the network interfaces don't configure a default route explicitly, so it gets configured by DHCP on the provisioning interface.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Deploy overcloud with network isolation enabled.
Default route is on provisioning interface
Default route should be on external network so Horizon and Public API are accessible from outside the cloud.
This is going to require updates to the network interface configuration templates. I'll submit a patch upstream.
I have submitted a fix upstream for this issue:
which also depends on this review:
This is closed by this patch:
which depends on this patch:
Using both patches I was able to see the configuration file correctly written for the default route for the external vlan.
Another few updates related to getting the default route onto the external network.
By default the Undercloud neutron pushes a default route to the provisioning network (nic1 in our existing templates). Adding a default route on the external network can conflict with the neutron supplied provisioning network route and as such the external network default route can fail to get added properly.
When dev/testing I think the existing patches could work fine so long as you share the default route for the external network with the provisioning network (something you might try when doing ad-hoc dev/testing testing on this). The new route would fail but so long as it is the same as the old it could be fine.
Here is a patch which allows us to suppress the default route on the provisioning network:
There are also 2 dependent changes which are required by the above patch for the following components:
tripleo-image-elements METADATA_IP_ADDR: https://review.openstack.org/#/c/197739/
os-net-config (dhclient_args): https://review.openstack.org/#/c/197738/
*** Bug 1238767 has been marked as a duplicate of this bug. ***
Created attachment 1045625 [details]
In regards to BZ#1238767 I was using the puddle from 29th June, openstack-tripleo-heat-templates-0.8.6-22.el7ost.noarch.
Could my issue be related to the fact that I'm running it in virt env thus the overcloud VMs have a single nic ?
(In reply to Marius Cornea from comment #10)
> Created attachment 1045625 [details]
> In regards to BZ#1238767 I was using the puddle from 29th June,
> Attaching controller.yaml.
> Could my issue be related to the fact that I'm running it in virt env thus
> the overcloud VMs have a single nic ?
I think that is exactly the issue. Once Dan Prince and I have worked out the details, we will get the single-nic templates working. The thing we are trying to get working is pointing the default route back at the undercloud, so the undercloud can reach the public VIP for postconfig.
What I do for reaching the public VIP in order to pass postconfig is to add a vlan interface in the external net vlan on the undercloud and assign it an IP address from the external net subnet(outside the range defined the env file and floating IPs range):
ovs-vsctl add-port br-ctlplane vlan10 tag=10 -- set interface vlan10 type=internal
ip l set dev vlan10 up; ip addr add 10.0.0.251/24 dev vlan10
That works fine for me but if you want to access the external network from other networks(for instance I'm running a VPN tunnel between my laptop and the physical host where I'm running the virt environment) then you need to set the default route through the external network. Otherwise requests reaching the external net interface will get their answers through the provisioning network which I noticed that doesn't work. That's particular to my setup and probably we don't intend to support such things. But my initial bug was about the actual deployed networking settings on the overcloud nodes not reflecting the network template files so I believe we should document if setting the default route through the external network doesn't work only on virt env, it definitely works fine on baremetal env.
According to comment #7 I cannot verify it on VIRT ENV. I the fix is relevant only in BM ENV. (veified with <mcornea>)
[root@overcloud-controller-2 heat-admin]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.35.180.254 0.0.0.0 UG 0 0 0 vlan195
0.0.0.0 192.0.2.1 0.0.0.0 UG 100 0 0 eth3
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.