On Thu, May 6, 2010 at 5:21 PM, Michael DeHaan <mich...@puppetlabs.com> wrote:
>> I am working on an EC2 type/provider, here is an example of its usage:
>>
>> noder{'blah':
>> ensure => present,
>> user => 'user',
>> password => 'password',
>> image => 'ami-84db39ed',
>> desc => 'happy instance',
>> }
>>
>
> your noder example looks good ... you could add a virt_type and not
> use a lot of the fields when doing non-EC2/cloud.
>
> A big part of what I want to do is to not require using the images, so that's
> definitely going to be a new thing.
>
> (It also requires a new field "kernel_options" ...)
>
> If it's in a branch there though with a separate provider (link), we
> could easily have Carla fork it and extend it. Providers
> could raise errors if they are used with incompatible arguments.
>
> --Michael
>
Here's what I mean by virt type:
noder {
provider => 'libvirt',
virt_type => 'qemu'
}
The idea is that we could reuse the one provider to do all the libvirt
development, and EC2 could be a different provider.
(Optionally, we could create a libvirt library, and have providers for
EC2, xen, and qemu seperately, but they share way so much in common).
(Also for those that don't know, qemu is the virt type underlying KVM.
If kvm-intel or an equivalent kernel module is present, /dev/kvm
exists, and the OS is then accelerated.
Xen paravirt works a little differently, meaning it isn't accelerated,
but requires a specially modified OS. Xen fullvirt can use any OS,
but requires special hardware.
When using Xen, we'd also need to pass around "paravirt => true" or
"paravirt => false".
Virtualization is complicated. Fun, but complicated :)
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
