Are you new to Juju and its charms? 
Welcome! 
Since you’re looking at everything with fresh eyes, you’re in a very good position to help improve the project.
Was anything more annoying than it should have been? Have you found any gaps in documentation or other too-small-to-report issues? Add your thoughts here 
Here is something oddly specific to juju’s internal codebase. Within its test suite, package check is typically aliased as gc. I keep referring to that as “garbage collector” in my head.
I found the command line parameters to be confusing. I generally expect parity commands like create/destroy, pull/push, etc. Some of the juju commands were confusing to me due to this:
bootstrap/destroy-controller
deploy/remove-application
It further confused me that I had no remove-bundle when I deployed a bundle, but instead I could remove all applications from the bundle, but if anything produced an error during this process it simply wouldn’t work. I’ve since changed to the paradigm of deploying a bundle and then destroying the model to remove everything as it doesn’t seem to get stuck, but that doesn’t sit with the desire to have parity of commands.
Another confusing item is that I use juju switch to switch models OR controllers. I’m accomplishing completely different tasks with the same command.
With specific reference to removing entities that are stuck in an error state, I found this a struggle for a while, and was also tearing down the model when that happened. I think this may be cloud-specific but in my environment I can retain the model by using remove-machine --force on the machine that houses the offending borked unit.
Juju’s CLI expects that you have bootstrapped properly. If you’re a brand new user who hasn’t initalised anything, following the steps recommended by the suggestions can feel very Kafka-esque.
Here’s one transcript of a brand new user’s experience:
$ juju help
[...]
$ juju status
ERROR No selected controller.
Please use "juju switch" to select a controller.
$ juju switch
ERROR no currently specified model
$ juju add-model
ERROR model name is required
$ juju add-model testing
ERROR No selected controller.
Please use "juju switch" to select a controller.
Ouch! That’s almost funny. I like how in some areas calling a top-level command without arguments enters an interactive mode guiding the user through getting something sensible as a result, instead of spitting out an obtuse error. It would make sense to apply that workflow to add-model, switch, status, and so on maybe? Those more experienced folks can either ^C out of it or are generally calling with args already.
EDIT: for me the extended tab-completion is a lifesaver here - getting a list of models, controllers and so on during these processes helps a lot. I’d suggest starting in the GUI would perhaps be a better beginning, with some visual wizard (witch doctor?) getting the user through it. If there were an end-to-end GUI experience including creating controllers that would make everything more comfortable to beginners. I used the GUI a lot to begin with, and also found that a bit strange until I grasped the fundamentals.
This is getting addressed in work that Ian is doing I believe for 2.5. It’s a known issue for folks that are trying to get things configured to get fussed at about not having a controller.
No… I think that the work that is being addressed in 2.5 is to do with juju plugins.
I think the error message @timClicks hit above could be improved in the situation where there are no local models or controllers. Perhaps something like…
$ juju status
ERROR No selected controller.
You have no locally referenced controllers or models.
Use "juju login" to access an existing controller you have permission to access or "juju bootstrap" to create a controller.
When writing reactive charms, I seem to have just had the dawning realization that each reaction you define with @when should also include a @when_not that references a flag you set at the end of the reaction. This might be in the docs. I might not have read it. I might not have understood it. I do now 
Otherwise you end up in a right old mess, as my grandma used to say about Kubernetes deploys.
A couple of thoughts that I surely remember have hurted a lot in my first steps
Documentation
CLI
This is intentional. We can do a better job explaining it. remove is intended for things you can redo safely, like a relation or an application you can redeploy. Destroy is for things that really involve a loss that isn’t recoverable. If you destroy a model it’s gone. Same with controller.
This is possible using the --map-existing flag on the bundle deployment command.
Is this from the CLI? Normally I think we find it easier to use the webui for browing large bits of content like the readme/relations/etc. I’m curious on what you’d like to see here for potential future updates.
So you should be able to filter juju status with the application name and the unit name.
juju status mysql
juju status mysql/0
There’s a new command landed for 2.6 that is
juju show-application mysql
And we use show-xxx as a general concept so you can use
juju show-machine 0
Agree this would be a nice thing to have.
HTH
Hi. For the first part, do you mean having multiple clients connected to the same controller? If so, then, yes, there are very justified improvements to be made to allow Juju to do that.
For the second part, our multi-user documentation was recently reviewed quite extensively. The essential tutorial is here. If this does not satisfy your concerns I’d be more than happy to discuss so they can be addressed. Model sharing can definitely be included in that tutorial.
Is this from the CLI? Normally I think we find it easier to use the webui for browing large bits of content like the readme/relations/etc. I’m curious on what you’d like to see here for potential future updates.
There are cases (especially relations and bindings) that using the webui is an overkill. For example you want to see the possible relations for Openstack Keystone to make a relation with Gnocchi. If you use the Juju GUI, you have a nice pop-up that will display all possible relations, however in the CLI you can only do it by trial and error to see the error prompt that will displays the possible relations.
The same also applies with bindings where there is almost no documentation at all in the charms.
So you should be able to filter juju status with the application name and the unit name.
It would be helpful to have a more generic command, like “juju status machines” or “juju status units” and display the status of all machines only or all units only. This would also allow easier manipulation for quick’n’dirty shell scripts or one-liners.
For the second part, our multi-user documentation was recently reviewed quite extensively. The essential tutorial is here.
I have missed that, thank you It is more than enough, however it is still unclear to me how it is possible to “register” to a controller if you do not have the register key (ex. I want to move my account to another machine)
I agree with @soumplis here. We only use the CLI and feel that relations and bindings are a bit hit and miss.
I created Bug #1672997 “Missing overview over charm bindings” : Bugs : juju and I think some work has been done in Bug #1742550 “no way to list application's current space binding...” : Bugs : juju for Juju 2.6 to help get an overview for deployed applications.
This falls under the category of being able to register a controller from multiple clients. This is definitely a topic we are aware of and one that we are looking to improve.
Here are a few pain points that I encountered while playing around with juju CLI (2.5):
While trying to remove a deployed app, the units would occasionally get stuck in a hook-failed state that prevented juju from actually removing them. I did try a bunch of different commands (e.g juju resolved, juju remove-unit and juju remove-application) whose output did not indicate an error but the units remained stuck with the only alternative being to kill the machine (a potential problem if more units were running on that machine).
I got a bit confused by the presence of two commands for tearing down controllers (destroy and kill). While I now understand the difference between the two commands it would make more sense to me to have a single command with a --force kind of flag to indicate the kill intent.
My final observation has to do with the debug-log command. Basically, I wanted to tail the logs from both the controller and the default models. I read the man page and somehow managed to skip over the -m flag so what I ended up doing was to switch to the first model start tailing the logs and then juju switch to the other model and run juju debug-log again. It wasn’t clear to me what happens to a running tail (without the -m flag) when you switch to a new model. I think it would be great if the man page could clarify what happens in this case.
Sounds like a good thing to add to the documentation.
All commands are run in a context that is set when they are started. ‘switch’ is used to set a default model if you one is not supplied by ‘-m’. Switch after a command has started has no effect on running commands.