I have a space in MaaS and consequently Juju that has a /24 subnet assigned to it. I want to change this subnet to a /23 and while MaaS allows the change (being aware that this change is not reflected to the deployed hosts) Juju seems not to respect it but instead still knows and uses the /24. Can you suggest any way to make Juju refresh the space information from MaaS ?
You might want to check out juju reload-spaces!
Usage: juju reload-spaces [options]
Summary:
Reloads spaces and subnets from substrate.
Global Options:
--debug (= false)
equivalent to --show-log --logging-config=<root>=DEBUG
-h, --help (= false)
Show help on a command or other topic.
--logging-config (= "")
specify log levels for modules
--quiet (= false)
show no informational output
--show-log (= false)
if set, write the log file to stderr
--verbose (= false)
show more verbose output
Command Options:
-B, --no-browser-login (= false)
Do not use web browser for authentication
-m, --model (= "")
Model to operate in. Accepts [<controller name>:]<model name>|<model UUID>
Details:
Reloades spaces and subnets from substrate
Unfortunately I hoped this would be the solution but it refuses to run.
The status is:
ubuntu@cfp001:~$ juju spaces | grep ^6
6 os-internal 10.1.0.0/24
Then I change the subnet in MaaS and…
ubuntu@cfp001:~$ juju reload-spaces
ERROR could not reload spaces: subnet “10.1.0.0/23” not found (not found)
I am tempted to manually change it directly to MongoDB under the subnets collection but I am not confident it will not break something else…
reload-spaces currently only picks up non-destructive changes like new subnets and new spaces.
This cycle we’re working on the mutation of spaces and outputting warnings when those changes might cause issues with running instances and such.
Unfortunately you’ve hit this gap and it doesn’t have an easy fix out until this work is done.
Lucky me 
Any hints on “manually” checking for potential issues if changing it directly to mongo ?
The main thing is running through juju show-machine and see if any of the machines are using any of the addresses you’ll lose by limiting the subnet.
The other thing is that you might find any of the applications that have written out network info will have that /24 written out. It really depends on what the charms did with the subnet info Juju told them when it said it’s the /24.
OK, I can handle all this as it gets down to charms and applications. I was worried for any Juju internal magic that would backfire 
Thank you, I think I will be brave (or to be accurate, I have to be brave on this!)
2 Likes
If you hit issues reach out in IRC and ping @manadart and he might have some other suggestions. Apologies for the issue but glad that the work we’re doing is important and solving issues for folks.
2 Likes
For the record, we have made the change. We had to change several entries in the DB (apart from subnets, there is also information in ip.addresses) and until we did all changes (in a try’n’error series) the related units over that network space complained that there was no relation.
One last change that we had to do is charm specific and in our case was haproxy that we should some trigger the recreation of haproxy.conf in order to create the correct ACL for that space.
1 Like
Thanks for the feedback. Really happy you were able to get things going and amazing job.