[Users] Getting some 3.1 screencasts

Dave Neary dneary at redhat.com
Thu Jul 5 20:07:32 UTC 2012


Hi,

On 07/05/2012 09:40 PM, Robert Middleswarth wrote:
> On 07/05/2012 01:11 PM, Dave Neary wrote:
>> 1. We come up with a set (5-10) of demo stories we want to tell in the
>> wiki. These should contain:
>>  * The feature we want to demo
>>  * The "before recording" set-up that needs to be done
>>  * The steps to demo the feature
>>  * A quick script that someone can follow to explain what they're doing.
>>
>> I'd like a few of these scripts to be for existing oVirt features
>> (say, migrating a VM to a different node) and a few to be for features
>> which are new in 3.1 (see the release notes at
>> http://ovirt.org/wiki/Release_Notes_Draft for details there, we should
>> pick one or two nice visible features like all-in-one install).
>>

> How are we going to decide on these features we want to demo?  Also some

My thoughts were low-tech - everyone propose that we demo their 
favourite feature. I was going to see the page with what I thought were 
the most promising features from the release notes and the home page, 
and throw in a couple of ringers that people would disagree with to 
start discussion & debate ;-)

I'm guessing that the number of things we'll want to demo will be small 
enough that the priority will be obvious. We can always do more, as long 
as we respect the priority listand get the most important ones done 
before the release, if possible.

> of the features like Glusterfs integration might be to complex for a 5
> to 10 min video.

True. Although the actual "add Glusterfs as a storage node" demo could 
be literally 30s - but of course, we wouldn't be showing how to set up 
the Glusterfs cluster in that.

As I understand it, the steps are:

1. Turn on Gluster support in the Clusters preferences of the Engine
2. Ensure vdsm-gluster is installed on the node
3. Create a volume in the Engine preferences, add some bricks, and make 
it available to nodes.

I got all this from your tutorials, there may be small but important 
steps I've left out - but if we assume that someone has an engine, some 
nodes, and a Gluster set-up as prerequisites, then we can get it down to 
a 10 minute webcast.

I do take your point, though. In general anything longer than 5-10 
minutes (5 minutes is the sweet spot, anything longer than 15, people 
won't watch) is too long, and we should break it up into steps, each of 
which makes sense on its own.

>> 3. Finally, we do voice-overs to add a sound track to the demo (and if
>> we have any skilled sound engineers, some tasteful CC licenced
>> background music would be great!)

> Sounding like a good overview now it is time to get into the mud and
> figure out how to implement that.

Cool :) What I like to hear. For recording audio, I was thinking very 
simply, record a sound-track while talking along to the video. You'll 
need some kind of a script to make it go well, and I'd expect that it'll 
take 4 or 5 takes before you'll have something you're happy with, but if 
you cut down the demo to the bare bones, it can work really well.

>> If it sounds good, which features do you think we should screencast as
>> top priority?

> Well I think you have already hit one of the most useful ones.
>
> 1) VM migrations
>
> Other simple idea that might make useful video's are.
>
> 2) The Log Collector (engine-log-collector),  Maybe even showing the
> creation of a BZ report?
> 3)  Uploading ISO (engine-iso-uploader), May be a little simple but we
> could combine with getting the ISO for windows drivers?
> 4)  How to upload images (engine-image-uploader) or Migrating from
> another system using something like virt-v2v / virt-p2v
> 5)  Cloning a Virtual Machine from a Snapshot.
> 6)  Creating Templates
> 7)  Pinning Virtual Machines to specific physical CPUs
> 8)  Setup multiple networks showing how to activate and connecting to a
> hosts.
> 9)  Adding storage domains?  Building a data center?
> 10) Exporting VM for backup or moving to another data center.

I definitely like adding storage domains/new disks, uploading 
images/ISOs, creating new images from templates or snapshots, migrating 
from another system. Someone would need to explain to me why Log 
Collector and CPU pinning are cool, and I'm not sure if setting up 
multiple networks would make for a cool demo.

I was thinking stuff like "adding a new node/VM" or "connecting remotely 
to a VM" would be kind of simple, but useful.

Cheers,
Dave.

-- 
Dave Neary
Community Action and Impact
Open Source and Standards Team, Red Hat
Phone: +33 9 50 71 55 62





More information about the Arch mailing list