Open Stack

On Tue, Oct 11, 2016, at 05:14 PM, Carl Baldwin wrote:
> I found this [1] added here [2]. Since the provider is using 10.0.0.0/8
> on
> the public interface, and the subnet pool is also 10.0.0.0/8 the call to
> ip
> route replace eliminates the route through the public interface.

It is also an issue if you have multiple subnets within 10/8 and rely on
your default route to route to them (though I don't think we currently
have any of these in the gate currently since rackspace sets more
specific routes for the subnets used for private networking there). This
would be the case if using a neutron setup with tenant networking and
floating IPs like we had with the old hpcloud.

> 
> Carl
> 
> [1] https://github.com/openstack-dev/devstack/blob/
> 6c55227595228bc37b91a1dbc665ec704cbf4c56/lib/neutron_
> plugins/services/l3#L376
> [2] https://review.openstack.org/#/c/356026/4/lib/neutron_
> plugins/services/l3
> 
> On Tue, Oct 11, 2016 at 5:32 PM, Armando M. <armamig at gmail.com> wrote:
> 
> >
> >
> > On 11 October 2016 at 14:09, Clark Boylan <cboylan at sapwetik.org> wrote:
> >
> >> Hello everyone,
> >>
> >> Currently multinode testing + neutron is broken in clouds that use
> >> portions of 10.0.0.0/8 for their networking due to route conflicts with
> >> devstack + neutron deployments. https://bugs.launchpad.net/bugs/1629133
> >> is tracking the issue for us. I would like to see this get resolved
> >> properly before we do further work on multinode testing as it is
> >> difficult to review and determine what failures are legit vs which
> >> failures are related to this bug and whether or not a specific multinode
> >> test has decided to workaround the issue.
> >>
> >> The change to use subnet pools in devstack is a non backward compatible
> >> change for devstack currently and it doesn't appear to have been
> >> documented in devstack at all. Would be great if we can finally fix this
> >> and get testing back to working and however we fix it ensure that
> >> devstack has the appropriate documentation.
> >>
> >
> > What is holding [1] back? Merging that would resolve the issue, then we
> > can drill down into why subnetpools interfere with the underlying
> > networking setup. I have asked Carl to look into broken build [2]
> >
> > [1] https://review.openstack.org/#/c/379543/
> > [2] http://logs.openstack.org/78/381278/2/check/gate-tempest-dsvm-neutron-
> > multinode-full-ubuntu-xenial/7f82862/console.html.gz
> >
> >
> >> Thank you,
> >> Clark