Bug 1236251
| Summary: | Default route should be on external network when network isolation is used | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat OpenStack | Reporter: | Dan Sneddon <dsneddon> | ||||
| Component: | rhosp-director | Assignee: | Dan Prince <dprince> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Ofer Blaut <oblaut> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | high | ||||||
| Version: | 7.0 (Kilo) | CC: | dmacpher, dsneddon, mburns, mcornea, ohochman, rhel-osp-director-maint, rrosa, tfreger | ||||
| Target Milestone: | beta | Keywords: | Triaged | ||||
| Target Release: | Director | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | openstack-tripleo-heat-templates-0.8.6-22.el7ost | Doc Type: | Bug Fix | ||||
| Doc Text: |
The default route was not set on the External network. This meant you could only access Horizon and the Public API from the same subnet as the Controller. This fix updates the Heat templates to include the ExternalInterfaceDefaultRoute parameter. This ensures a default route is available on the External interface.
|
Story Points: | --- | ||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2015-08-05 13:57:11 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Dan Sneddon
2015-06-27 00:57:26 UTC
I have submitted a fix upstream for this issue: https://review.openstack.org/#/c/196732/ which also depends on this review: https://review.openstack.org/#/c/196403/1 This is closed by this patch: https://review.openstack.org/#/c/196732/ which depends on this patch: https://review.openstack.org/#/c/196403/ 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: https://review.openstack.org/#/c/197742/ 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] controller.yaml In regards to BZ#1238767 I was using the puddle from 29th June, openstack-tripleo-heat-templates-0.8.6-22.el7ost.noarch. 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 ? (In reply to Marius Cornea from comment #10) > Created attachment 1045625 [details] > controller.yaml > > In regards to BZ#1238767 I was using the puddle from 29th June, > openstack-tripleo-heat-templates-0.8.6-22.el7ost.noarch. > 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>) Tested openstack-tripleo-heat-templates-0.8.6-23.el7ost.noarch [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. https://access.redhat.com/errata/RHEA-2015:1549 |