Hide Forgot
Description of problem: When using composable roles (i.e. Having the OpenDaylight controller on a separate node ) to deploy the overcloud there is no connectivity to the Floating IP of an instance when the compute interface facing the external network doesn't have an IP. Version-Release number of selected component (if applicable): openstack-tripleo-heat-templates-6.0.0-10.el7ost.noarch How reproducible: Steps to Reproduce: 1. Deploy the overcloud using the topology of 1 Controller,1 OpenDaylight controller and 2 compute nodes setting the use_dhcp of the external interface of the compute to false. 2. Launch an instance. 3. Verify there is no connectivity to the instance 4. Do Steps 1-3 but using use_dhcp=True for the external interface of the compute and verify there is a connectivity to the Instance. Actual results: Expected results: Additional info:
We shouldn't need an IP address on external interface of compute. This looks like a bug where some flows are missing in OVS, and restarting ODL fixes it.
When using the bridge br-ex in the compute node - there is no problem. The problem happens when we have a mapping such as OpenDaylightProviderMappings: "datacentre:eth2"
(In reply to Itzik Brown from comment #2) > When using the bridge br-ex in the compute node - there is no problem. > The problem happens when we have a mapping such as > OpenDaylightProviderMappings: "datacentre:eth2" Then this is a bug with using the interface directly on br-int for proivder networks. Changing the bug title as we should not need an IP on the linux interface.
@Itzik, can you confirm the severity of this bug? Should we retest it with RHOSP 12?
As far as I understand the common approach is using a bridge (e.g. br-ex) and not adding the interface directly to br-int so this is why I think it's a Medium priority. Regarding RHOSP12 - we need to discuss.
@Itzik, can you please review this with Tim and let me know what should be our solution for Pike/RHOSP 12? Thanks, Nir
I'll do.
@Josh, per feedback from Tim can you please take a look at this one? We should try to reproduce with Carbon SR1 and fix it if it still exists. Thanks, Nir
I think we need to understand whether or not we need to support external interfaces on br-int since OoO triple-o does not install things that way.
As it turns out, per the opener of this bug, it only occurs when the compute node's external interface is directly attached to br-int. We do not deploy the product this way any more. As such I am closing this bug.