Pivotal/Trello/whatever backlog?

[ajlanghorn]

My own two-pence/cent/whatever, but does this project have a Pivotal/Trello/whatever backlog that's open to the world? I think it would be really useful as a to-do tracker.

[ajlanghorn]

bump @miketheman?

[miketheman]

We originally started a trello here: https://trello.com/opsschool But have been lax in defining what our next steps are. @avleen, myself and others should actually take some time and try to figure out what's next.

Do you have some ideas?

[avleen]

I think the big thing next is to define what the "next steps" are for the project.
In it's current state, it has definitely been helpful to a great number of people - the mentions on twitter and personal emails I've received are a testament to that. We could easily just say that we're done!

But I really want to see next steps, as do a lot of others :-)
My last great idea, which hasn't been actioned yet, was to create a bunch of VM images for VirtualBox. Each VM would have something(s) broken, and the user would have to figure out what. The initial testing of this was very positive and I think there was agreement that this would be a good approach to go forward.

What it would need:

1. Someone to make a bunch of chef recipes that break stuff. We have a chef repo at https://github.com/opsschool/virtualmachines. Each VM role should have multiple broken things. Just one broken thing would be too easy :-)
2. Some consistent way that people can interact with the system. This could be as simple as a shell script called isitworking.sh, which can be run and reports whether the broken things are working again or not.
3. The difficulty of breakage should get progressively higher. Both inside a single VM, and having different levels of VMs.

We can either do this as VirtualBox images, or we have VM resources which Rackspace donated to this project. However, using Rackspace would require us to set up more security and have an automated way to provision and deprovision machines, etc. Totally worth going, but maybe as Phase 2.

That is, if people still think this is a good idea!

[Hefeweizen]

Avleen,

I think this is a great idea. Learning a technology is not just about installing an application, but how to make it scale and how it functions under load. There's no lack of guides on how to install software, but there is little material available that helps build this other experience. I think this kind of work could help fill this need.

I believe Vagrant allows a fairly portable experience, and would advocate for it's use. Granted, we're training technologists, but there's something to the convenience of condensing the instructions to: save this Vagrantfile to a location, type "vagrant up".

I would ship clean machines, and then provide scripts/recipes/&c that break them. This allows five things:

• It's easier to package and deploy break scripts than to package and deploy broken VMs. Yes, the build of VMs would be automated, but file size difference is significant. Students on slow connections are more likely to wait for the download of 120Kb scripts than the download of 600Mb VMs. (and these downloads are per exercise).
• Let people experience a normal environment before challenging them; then, when it's broken less has to be explained about how it's broken because they can rely on their own experience of what a working environment looks like.
• It also allows a certain amount of improvisation by the student. If they want to investigate something off script, they have the freedom to do so.
• imagine a scenario that's too hard. Providing a clean VM allows the student to poke around and gracefully back-out to a useful state; they can build experience of what works before trying the scenario again. Providing a broken VM leaves the student with nothing; they'll delete and move on (maybe to another exercise, or they move on to World of Warcraft)
• Finally, it allows more scenarios. Not only can we ask the student to fix broken components, we can ask them to work on performance tuning components. The default configuration will allow a certain performance threshold; we can write scenarios asking the student to increase throughput/page requests/&c.

So, yes, it's a great idea but flip the deliverables. Do not provide broken machines with checks to see if they're working; provide working machines with easy ways to break them.

-- Jess

[jrgifford]

So my take would be to make use of the vagrant VMs ability to use a basebox - have them all use the same basebox, then customize it on a per-"problem" basis.

[ajlanghorn]

Or a Packer image, and then whatever your config management poison of choice is on top as a provisioner?

[castillar]

Picking this one up, you might have a look at the Labtainer project, which has an educational curriculum of labs for teaching security. Users pull down one VM and then all the labs run as Docker containers inside the VM. So you can do "labtainer firewall-lab" and have it spin up a little network with a firewall, host inside, and webserver, then work through problems. That might be a really useful model to work from, especially since you can download either the pre-made VM (3GB) or just the Docker and lab framework (ca. 25MB of Python) for something lighter-weight but more self-supported.