As part of documenting Juju usage in production, it occurs to me that training is an important part of making use of Juju in-house.
What is the process that you use to teach Juju? Are there are a set of steps that you encourage new operations staff to go through in your team? What would the ideal training course look like?
Beginner
Bootstrap to localhost.
Bootstrap a public cloud.
Deploy the cs:ubuntu charm in an empty model
Retrieve a public IP address from a unit
Deploy a bundle (perhaps a deploy a Kubernetes cluster)
Run an action
Use juju ssh to access a unit
Intermediate
Explain what juju switch is and what it does
Where are Juju logs stored? What does juju debug-log do?
Where is the charm you’ve deployed stored on a machine in your Juju model?
What is the effect of restarting a Juju daemon process (jujud) on a machine running in your model?
Explain what juju switch is and what it does
Can you explain the terms model, application, unit, machine and relation to someone new to Juju?
Advanced
How is Juju upgraded, and what does an upgrade mean in Juju terms?
A graphical, pedagogical, description of the state machine with a complete description of the different ‘hooks’ that are fired at each step.
Plus.
Good strategies (example code) on what to put in those hooks as a beginner charmer. This is a key thing, since many beginners will likely copy those patterns for a long time in their own work and subsequent contributions to the charm ecosystem.
The first thing I have people do when learning juju is run ‘juju help commands’, ‘juju help commands | grep thing’ . This immediately exposes the user to the wealth of juju’s capabilities, shows them how to start navigating juju from the cli and helps them understand how they can figure things out for themselves by grepping for what they are trying to do with juju. I still use this tactic to this day. If I want to know what commands are available for manipulating credentials I might run ‘juju help commands | grep credentials’.
There are three distinct sets of “How to use Juju” also.
The operator/non programmer perspective. Thing would the be like:
$ juju run-action myapp/0 do-something
$ juju add-unit myapp
$ juju config myapp var=value
… etc.
The devops/charm developer perspective. That would be a like:
“How do I reconfigure myapp using hooks with python?”
“How do I alter the cloudinit process with juju?”
How do I implement a http relation in the myapp charm?
The juju infrastructure perspective, which would be;
How do I setup/deploy a multiuser juju controllers with candid and let’s encrypt ssl certs?
How do monitor, backup and upgrade my controllers?
All of these perspectives intersect somehow, but could be organized as above perhaps.