Newcomer papercuts


#1

Are you new to Juju and its charms? :sparkles: Welcome! :wave:

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 :writing_hand:t4:


Juju Show #43 - Nov 28th 18:00 UTC
#2

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.


#3

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.


#4

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.


#5

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.

#6

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.


#7

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.


#8

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.

#9

(post withdrawn by author, will be automatically deleted in 24 hours unless flagged)