Outline for a hands on Technical Demo Talk

• Target Devconf 2015

With each section comes some talking explanation, and then hands on demonstration. We should also save videos of how things work if the demo falls over.

1. What is Cockpit

Slide:

• Intro

• "Welcome."

• "Cockpit is an interactive browser based Linux admin interface. What does it look like? It looks like this:"

Demo:

• Log into Cockpit
• Show the dashboard, Server Summary and Storage tabs

Slide:

• Screenshot or dashboard

• "Hopefully by the end of this talk you'll have a better understanding of how Cockpit works, why it exists, and how you can build stuff with it."

• "We won't go into every nook and cranny of the Cockpit user interface, because you're big girls and boys and can do that on your own."

• "This is a more technical talk."

Preparation:

• Ensure that a trusted certificate is used
  • TODO: I have this on my laptop, document and generalize

2. Goals of Cockpit

• "Why does Cockpit exist?"
• "We explained this in our talk here last year ..."
• ... From last year....

Slides:

• Truck analogy

Slide:

• Goal 1: Make Linux servers usable by non-expert admins.

• Goal 2: Make complex Linux features discoverable.

• "I just showed you how easy it is to click around and start configuring your server".

• "We make it trivial to do a basic task like setting the Host name of the machine."

Demo:

• Show how a non expert can change the host name, and perform mundane task.

• Click on the server section

• Click on Host name

• Change it

• "So that was easy. Trivial ... but you guys already knew how to do that. On to our second goal, make linux features discoverable."

• "How many of you know off the top of your head how to setup a bonded network interface in linux."

Demo:

• Show how even an expert (like those in the room) can a Network bond (rather esoteric complex feature).
• Click on the Networking section
• Choose 'Add Bond'
• Click eth5 and eth6
• Create the bond
• Click on the bond to set an address
• Configure the address

Preparation:

• Create eth5 and eth6 bridges:

  brctl addbr eth5

  brctl addbr eth6

3. Cockpit out of the box

• "That's all well and good, but if you have to configure Cockpit, before using it, then we've already lost the game."
• "Cockpit has to work out of the box"

Slide?

• Cat coming out of box?

• Cockpit is designed so that it can be included by default. We'll talk more about that later ... but let me show you how it just plain works on Fedora 21 Server"

Preparation:

• Install a Fedora Server 21 VM. Setup static IP address.
  • Create a snapshot while running installer has finished at 'Reboot' button.
• Stop the cockpit network

  virsh net-destroy cockpit

Demo:

• Show Fedora 21 Server with Cockpit just running after install
  • Run the snapshot you created above
  • Connect to Cockpit at the static IP address
  • Shutdown through Cockpit, showing we are in fact talking to that virtual machine.

4. Doesn't own server

TODO: Needs a better tag line ^^

Cockpit doesn't store data or make policy decisions on its own. It just exposes the configuration services and state of the actual server.

Slide:

• Slide showing that Cockpit is just the presentation layer

Demo:

• Show that the user account used to log in is a server account
• Show how the user is authenticated in a real linux session, as if they were SSH'd in

Slide:

• Declarative or Interactive

"Cockpit is interactive, it shows you what's on your machines, and carries out your actions on the machine. In this way it's different from other tools like Spacewalk or Puppet, which contain policy. Those are declarative tools, whereas Cockpit is interactive".

5. Cockpit reacts to the server

"Cockpit can't and will be able to do everything. It's vital that Cockpit reacts to changes made by other tools, such as the CLI, management systems, scripts, etc."

Demo:

• Show starting a Docker container, and how that updates the display
• Access the container terminal and actually do stuff through Cockpit
• Exit the container by typing exit at the terminal
• Cockpit knows that it exited.

"For example if you wanted to use some feature of Docker that doesn't show up in Cockpit, you can just do that one thing from the terminal, and happily continue to use Cockpit for other Docker stuff."

6. Lightweight

"There's no excuse to not running Cockpit on your server."

"Your Server job is not to run Cockpit. It's to serve stuff."

Slide:

• Cockpit runs with zero prior config
• Cockpit hash zero footprint starts on demand
• Comes by default, and no excuses not to have it by default

Demo:

• Show that cockpit isn't running on your machine with $ ps -xa | grep cockpit ... no cockpit processes
• Access cockpit on the local machine $ ps -xa | grep cockpit ... cockpit-ws started up
• Log into Cockpit ... cockpit-bridge started up
• Talk about how it exits when not in use

Demo:

• Show how few dependencies cockpit-bridge has

7. How does Cockpit work

Slide:

• Transport slide

Demo:

• Show Cockpit bridge transport protocol

8. Pluggable and Modifiable

Demo:

• Cockpit lets you edit it really easily
  • Link stuff into home directory
  • "Those of you coming from a PHP world may think this is no big deal ... but this is important"
  • Show editing a page, and changes immediately

Demo:

• Create a new component executing a process.

  • Put the pinger component into the right place
  • Log out of cockpit and back in

• Create a new component running a systemd DBus command

9. Embedding Cockpit?

Note: Easy to demo, but perhaps an optional part of talk?

Summary