Michael DeHaan wrote:
Based on recent list activity, and a talking with everyone at Summit
and IRC, here's my list of the top 4 things I'd like to see added to
cobbler in the near term:
A few updates on these ideas...
-- Virt support for deploying additional virt types
KVM, etc
Fullvirt Xen
Incidentally, this is going to happen a bit differently than I thought,
so if you want to deploy other types of virtualization in an automated
way, here's the deal ... It's good. Work is being done to make Xen
fullvirt be able to PXE itself, so you'll be able to get everything you
can get from Cobbler bare-metal PXE to work here -- presumably PXE menus
and all.
This is actually simpler and more powerful. However, if your
environment can't use PXE (not friends with the guy who sets up the DHCP
server, or some other software owns it?), this could cause problems.
Getting a next-server address set for the MAC's in question would need
to be done, I'm fairly sure the virt-install tools that allow you to set
up the machine for PXE will allow you to set a MAC address of tell you
what it will be.
koan will still exist for helping out with paravirt installs and setting
up redeployments. I'd like to see virt-install and virt-manager
become aware of cobbler and be able to install from Cobbler servers
automatically (pick the profile from a list), and we're looking into how
to best make that happen.
-- Extend the repo management code to deal with older non-yum content
(RHN), like mrepo can do, such that running mrepo as a seperate tool
for older distros is not required.
This is going to happen via the new "surfr" project, which cobbler can
later integrate at it gets further along. Should be goodness.
-- Build a netinstall CD from cobbler for environments that don't do
PXE. Tie the CD to a specific profile (or better, eventually,
provide a boot menu). Lots of folks need baremetal provisioning and
due to aspects beyond their control can't use PXE.
Just now starting to look at options here...
-- Support either om_shell or DNSMasq, to avoid the dhcp reload wait
time when manage_dhcp is enabled and systems are updated. (Some
folks I believe are looking at both of these?)
DNSMasq support is in the upstream code, as I've sent out in a previous
email. If you are using dnsmasq you do need to /sbin/service dnsmasq
reload (sighup) the service to make it apply changes, which also happens
automagically if you run "cobbler sync" -- but yes, you should get
hostname control for free -- which is something several people were
looking for.
I played around with omshell for dynamic control of ISC dhcpd (OMAPI)
and had some issues getting it to connect (no luck) -- but if someone
wants to submit a patch that contains their omshell knowledge, that
would be great. The cobbler triggers mechanism would also be good for
this... http://et.redhat.com/page/Cobbler_Triggers. All that would
be required would be writing a hook for the "system add" trigger that
sent the appropriate omshell command(s), and a corresponding one for
"system remove".
--Michael
