Autodetection of subnets prevents bootstrap when there are duplicate subnet ranges

Bug #1733266 reported by John A Meinel on 2017-11-20
48
This bug affects 11 people
Affects Status Importance Assigned to Milestone
juju
High
John A Meinel
2.3
High
John A Meinel

Bug Description

This is a spin off of the issue filed in: bug #1710848

In 2.2 we introduced automatic detection of subnets. But Openstack defaults to a configuration where lots of things are exposed as link-local subnets, and so they all collide.
Nobody is going to be putting those subnets into spaces, so it is ~ok to ignore them.

The correct fix (ultimately) is to change our internals to model separate networks and each network has non-overlapping subnets, but vs other networks they might collide.

In the short term, we need to just change the autodetection code to not fail in a blocking way when subnets overlap.

John A Meinel (jameinel) on 2017-11-27
Changed in juju:
status: Triaged → In Progress
Ian Booth (wallyworld) wrote :

The PR attached to this bug does not address the issue in the bug. I've raised a new bug to cover the fact that Juju should ignore certain subnets. Bug 1734772.

This bug will be marked as triaged again so that we can work to address the dupe issue.

Changed in juju:
milestone: 2.3-rc2 → 2.3.1
status: In Progress → Triaged
Changed in juju:
milestone: 2.3.1 → none
Tim Penhey (thumper) on 2017-12-10
Changed in juju:
milestone: none → 2.3.2
John A Meinel (jameinel) wrote :

Removing from the 2.3.2 milestone because the larger fix of modeling Networks for overlapping subnet ranges is a much bigger change.

Changed in juju:
assignee: Witold Krecicki (wpk) → nobody
milestone: 2.3.2 → none
Vincenzo Di Somma (vds) wrote :

This bug is preventing a customer deployment, could we change the "importance" to critical?

I believe there is a workaround if you create a tenant that doesn't have
visibility to all of the networks that aren't useful. You tend to run into
this when you bootstrap as the admin of Openstack which seems a bit like
running all your applications as root.

If it needs to be escalated then please go through the normal channels to
do so.

As for possible internal fixes. One reasonably straightforward one is to
only include subjects in the Network that was supplied for the model.

John
=:->

On Mar 20, 2018 20:58, "Launchpad Bug Tracker" <email address hidden>
wrote:

> You have been subscribed to a public bug by Vincenzo Di Somma (vds):
>
> This is a spin off of the issue filed in: bug #1710848
>
> In 2.2 we introduced automatic detection of subnets. But Openstack
> defaults to a configuration where lots of things are exposed as link-local
> subnets, and so they all collide.
> Nobody is going to be putting those subnets into spaces, so it is ~ok to
> ignore them.
>
> The correct fix (ultimately) is to change our internals to model
> separate networks and each network has non-overlapping subnets, but vs
> other networks they might collide.
>
> In the short term, we need to just change the autodetection code to not
> fail in a blocking way when subnets overlap.
>
> ** Affects: juju
> Importance: High
> Status: Triaged
>
>
> ** Tags: network openstack-provider
> --
> Autodetection of subnets prevents bootstrap when there are duplicate
> subnet ranges
> https://bugs.launchpad.net/bugs/1733266
> You received this bug notification because you are subscribed to the bug
> report.
>

Nicholas Skaggs (nskaggs) wrote :

Unsubbing field critical as there is a workaround in place, and it's been utilized successfully.

Jeff Hillman (jhillman) on 2018-05-22
tags: added: cpe-onsite
John A Meinel (jameinel) wrote :

We should be able to filter to just the subnets that are part of the Openstack Network that we have defined in Config.

There is "network" and "external-network" which are both something like:
  The network label or UUID to bring machines up on when multiple networks exist.

Essentially when we scan subnets to record in the database we could just filter to the network id that is known.

Note that we'll want to be careful because eventually we may want to inventory all networks, but it should be a reasonable first pass fix.

John A Meinel (jameinel) on 2018-05-23
Changed in juju:
assignee: nobody → John A Meinel (jameinel)
status: Triaged → In Progress
milestone: none → 2.4-beta3
John A Meinel (jameinel) wrote :

https://github.com/juju/juju/pull/8751 only includes subnets that we would have access to, given that they are associated with the network that the user defined.

John A Meinel (jameinel) wrote :
Changed in juju:
milestone: 2.4-beta3 → none
John A Meinel (jameinel) on 2018-06-05
Changed in juju:
milestone: none → 2.4-rc1
status: In Progress → Fix Committed
John A Meinel (jameinel) wrote :

I believe this actually made it into 2.4-beta3, but it isn't worth reopening the milestone.

Dmitrii Shcherbakov (dmitriis) wrote :

Just in case, OpenStack has a concept of address scopes to allow overlapping subnet ranges for networks with multiple VRFs:

https://docs.openstack.org/neutron/queens/admin/config-address-scopes.html

If I read that document correctly, all subnets in a given 'network id' are
associated with a given address scope. Which still disallows subnets to
overlap. So within a 'network' none of the subnets overlap. It is just that
you might share address scopes across networks.

Juju currently only supports 1 network for all of the instances in the
model, which still restricts you to non-overlapping subnets.

Eventually we probably want to handle >1 network for instances, but as yet
that hasn't been a significant request.

On Tue, Jun 5, 2018 at 8:56 AM, Dmitrii Shcherbakov <
<email address hidden>> wrote:

> Just in case, OpenStack has a concept of address scopes to allow
> overlapping subnet ranges for networks with multiple VRFs:
>
> https://docs.openstack.org/neutron/queens/admin/config-address-
> scopes.html
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1733266
>
> Title:
> Autodetection of subnets prevents bootstrap when there are duplicate
> subnet ranges
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1733266/+subscriptions
>

Changed in juju:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers