Speaking as someone who is administering multiple controllers, some of which have multiple clouds, I find the --local option very unintuitive. To me, this implies “local to this controller”. In my opinion, it would be better to use --global. This implies that it’s applicable to all controllers.
--local means local to the machine from where the CLI is being invoked. A cloud added to the local cache can be used to bootstrap a new controller or added to an existing controller. A local cloud definition has no meaning as such to any running controllers - it’s simply metadata describing a cloud. --global doesn’t really fit in with this semantic.
After thinking about it, I figured what what was intended. When I encountered the --local parameter, was thinking from perspective of the controller, rather than my laptop.
Thought that I would create a thread to see if anyone else had encountered a similar cognitive dissonance.
Personally, I’d like to see add-cloud not be overridden in this way 
I love the new functionality of being able to “add a new cloud to an existing controller” (OpenStack on top of MAAS ftw!) but I’d really prefer a new command, rather than overloading an existing command in a way that breaks backwards compatibility (we have existing systems that use the Juju CLI to manage clouds in an automatic fashion and that automation will all break when we update to the Juju version with the “renovated” add-cloud command.
As an alternative to a new command, I’d rather have seen the default stay the same, in such a way that existing tooling continues to work while adding a new flag, maybe something like juju add-cloud --controller=$CONTROLLER_NAME that will add a new cloud to the existing controller known as $CONTROLLER_NAME.
add-cloud is a controller command, so that add-cloud --controller <foo> works as expected.
But currently it will also default to the current controller if --controller is not specified.
Whether that should be changed is something to discuss.
There is an issue when a controller hasn’t been created yet.
add-cloud and add-credentials should not simply fail if --local is omitted.
Novice & prospective users don’t have a mental model of Juju, so the multi cloud behaviour is not yet understood.
add-cloud doesn’t fail if --local is omitted and there’s no controllers.
It tells you that it has added the cloud to the local cache and can be bootstrapped.
add-credential has not yet been updated to understand local vs controller credentials.
My bad, I got the command wrong. It’s list-clouds that gets confused:
juju clouds
ERROR current controller not found
$ juju clouds --local
Cloud Regions Default Type Description aws 15 us-east-1 ec2 Amazon Web Services aws-china 2 cn-north-1 ec2 Amazon China aws-gov 1 us-gov-west-1 ec2 Amazon (USA Government) azure 27 centralus azure Microsoft Azure azure-china 2 chinaeast azure Microsoft Azure China cloudsigma 12 dub cloudsigma CloudSigma Cloud google 18 us-east1 gce Google Cloud Platform joyent 6 us-east-1 joyent Joyent Cloud oracle 4 us-phoenix-1 oci Oracle Cloud Infrastructure oracle-classic 5 uscom-central-1 oracle Oracle Cloud Infrastructure Classic rackspace 6 dfw rackspace Rackspace Cloud localhost 1 localhost lxd LXD Container Hypervisor microk8s 1 localhost k8s A Kubernetes Cluster ...
In my opinion, we should be revealing the public cloud providers in the --local omitted case.
Yeah, we wanted to do the smart thing for list-clouds as well as add-cloud but long story short it was not done for “reasons”. IMO list-clouds should be updated to behave the same as add-cloud.