Incomplete support for network spaces in Juju and MAAS

[Matt Rae]

When space name is updated in MAAS, juju reload-spaces doesn't properly update the space name in juju.

Other issues with juju space functionality:
- Editing a subnet in MAAS, for example going from 10.11.12.0/24 to 10.11.0.0/16 is not updated in juju
- Move a subnet to another space
- If an empty space is created, juju doesn't load it
- Delete space/VLAN/subnet
- "juju subnets" prints status as "in-use" for subnets where no unit/machine
is deployed, it's not clear what it means.

One potential solution could be to have MAAS lock spaces or subnets from being updated after they are in use by juju. Or notify the user if an operation in MAAS will affect deployed machines.

[Richard Harding (rharding)]

There are improvements in this area in 2.7 but not all the cases identified are fixed. I'm going to bump it to carry it forward.

[Richard Harding (rharding)]

I'm going to assign this to Simon as he's working on updating reload-spaces with the new 2.8 abilities and a few of these should get done. We can mark those as complete and carry over specific bugs, perhaps as new ones that "reload-spaces should support X"

[james beedy (jamesbeedy)]

Wooohoo!!! Thank you - @rharding & @simonrichardaon

[Felipe Reyes (freyes)]

On Tue, 2020-04-07 at 12:33 +0000, Richard Harding wrote:
> I'm going to assign this to Simon as he's working on updating reload-
> spaces with the new 2.8 abilities and a few of these should get done.
> We
> can mark those as complete and carry over specific bugs, perhaps as
> new
> ones that "reload-spaces should support X"

Thank you so much! :-)

[Pen Gale (pengale)]

This may have been fixed by work to track spaces by internal id rather than provider id. @manadart: is this bug fixed?

[Joseph Phillips (manadart)]

No it isn't. We implemented functionality for users to massage space names and network topology, along with a slew of safety checks based on endpoint bindings and space constraints.

What would be required here is to extract those checks into a general-use module and apply them to the reload-spaces logic so that if safe, we just consume detected MAAS space/subnet mutations.

At present this functionality remains largely as first conceived, which prevents most changes. The exception is this patch from Simon that introduced the ability to delete spaces that were removed in MAAS.

[Mark Lehrer (pyite)]

How about the following:

1) Have Juju print a warning to let the user know when it is skipping subnets/spaces

2) Add a "--force" option that would allow Juju to match whatever is configured in MAAS regardless of the consequences

At least do #1 because this behavior is very confusing to new users

[Canonical Juju QA Bot (juju-qa-bot)]

This Medium-priority bug has not been updated in 60 days, so we're marking it Low importance. If you believe this is incorrect, please update the importance.

[Boris Lukashev (rageltman)]

This is still happening on juju 3.1 + maas 3.3. Its quite problematic if space assignments are changed after address space is configured as juju cannot address the nodes correctly (or even find renamed spaces). Just adding a "flush-spaces" command to allow clean acquisition from provider might be handy.

[DUFOUR Olivier (odufourc)]

I can confirm this is still an ongoing issue with Juju 3.3 and MAAS 3.4