12:11 p.m.
Hi everyone,
At the team meeting today Jason Clift suggested that it would be great
to have some screencasts for the 3.1 release. I agree. So let's see if
we can make some!
To spread the load as much as possible, here's what I propose:
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).
2. From the scripts, we record the demos as .ogv using RecordMyDesktop
or GNOME Shell's built-in desktop recording
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!)
This way, we've broken down the creation of 5 screencasts into 15
different byte-sized tasks - script, video, voiceover - none of which
should take someone more that 20 minutes or half an hour - which
hopefully will make it easier to get them done together.
How does this plan sound?
If it sounds good, which features do you think we should screencast as
top priority?
Thanks!
Dave.
--
Dave Neary
Community Action and Impact
Open Source and Standards Team, Red Hat
Phone: +33 9 50 71 55 62
2:40 p.m.
On 07/05/2012 01:11 PM, Dave Neary wrote:
Hi everyone,
At the team meeting today Jason Clift suggested that it would be great
to have some screencasts for the 3.1 release. I agree. So let's see if
we can make some!
To spread the load as much as possible, here's what I propose:
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
of the features like Glusterfs integration might be to complex for a 5
to 10 min video.
2. From the scripts, we record the demos as .ogv using
RecordMyDesktop
or GNOME Shell's built-in desktop recording
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!)
This way, we've broken down the creation of 5 screencasts into 15
different byte-sized tasks - script, video, voiceover - none of which
should take someone more that 20 minutes or half an hour - which
hopefully will make it easier to get them done together.
How does this plan sound?
Sounding like a good overview now it is time to get into
the mud and
figure out how to implement that.
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.
Thanks
Robert
Thanks!
Dave.
3:07 p.m.
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
3:24 p.m.
----- Original Message -----
From: "Dave Neary" <dneary(a)redhat.com>
To: "Robert Middleswarth" <robert(a)middleswarth.net>
Cc: "arch" <arch(a)ovirt.org>, "users" <users(a)ovirt.org>
Sent: Thursday, July 5, 2012 4:07:32 PM
Subject: Re: [Users] Getting some 3.1 screencasts
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 ;-)
Everyone on this list (hopefully) has a good idea what oVirt can do ans se we tend to jump
to the new, sexy features like Gluster, but the majority of people won't know the
basics - they'll be shocked when they see a GUI with the amount of functionality oVirt
3.0 had let alone 3.1.
We've got a lot of experience demoing RHEV and it never ceases to amaze me how many
people don't even know we have the basics.
So don't forget or the basic features - creating a VM, making it highly available with
just a mouse click, live migration, etc.
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
_______________________________________________
Arch mailing list
Arch(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/arch
3:43 p.m.
On 07/05/2012 04:24 PM, Andrew Cathrow wrote:
----- Original Message -----
> From: "Dave Neary" <dneary(a)redhat.com>
> To: "Robert Middleswarth" <robert(a)middleswarth.net>
> Cc: "arch" <arch(a)ovirt.org>, "users"
<users(a)ovirt.org>
> Sent: Thursday, July 5, 2012 4:07:32 PM
> Subject: Re: [Users] Getting some 3.1 screencasts
>
> 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 ;-)
>
Everyone on this list (hopefully) has a good idea what oVirt can do ans se we tend to
jump to the new, sexy features like Gluster, but the majority of people won't know the
basics - they'll be shocked when they see a GUI with the amount of functionality oVirt
3.0 had let alone 3.1.
We've got a lot of experience demoing RHEV and it never ceases to amaze me how many
people don't even know we have the basics.
So don't forget or the basic features - creating a VM, making it highly available
with just a mouse click, live migration, etc.
Yes my list missed the basic one creating a VM and you are right the
basic's are what we want to start with. We also need to get it simple
unless we are looking at creating a movie that can work but you need to
do it in short segments demoing certain features in each video but it
can be hard to get right. Best to remember kiss when working with video's.
Thanks
Robert
> 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
>
>
> _______________________________________________
> Arch mailing list
> Arch(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/arch
>
3:32 p.m.
On 07/05/2012 04:07 PM, Dave Neary wrote:
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.
A few of those steps make the diff between an working
and not working
setup. This morning I upgraded to a newer beta and had to
engine-cleanup my setup. I forgot one of my own steps. Should have
read my own guide :) In fact I had to pull up my own guide to remember
the step I missed.
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.
Most projects don't have to bandwidth to hosts
there own video's and use
either Vimeo or Youtube. Youtube limits you to 10 min video so that is
a good max :) But 5 min is a good length.
>> 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.
It might not be sexy to some but to an admin like me it would be. A
utility to helps me collect the need info for a bug report and makes my
life easier would be very sexy to me. Also really useful for internal
use as we could point people to the video/howto for submitting bugs.
I was thinking stuff like "adding a new node/VM" or
"connecting
remotely to a VM" would be kind of simple, but useful.
I could see creating a
VM. But connecting to VNC might actually turn
some users off. Showing spice under might be because it is more integrated.
Cheers,
Dave.
4350
days inactive
4350
days old
5 comments
3 participants
participants (3)
-
Andrew Cathrow -
Dave Neary -
Robert Middleswarth