On Monday, February 6, 2012 at 8:57 AM, Cole Robinson wrote:

On 02/06/2012 08:12 AM, Michael DeHaan wrote:
Hi again Cole!

Hmm … yes, I remember this discussion from years ago :)

First comments are that this is both a decent new approach (using the CLI
versus XML), and I'm also very concerned that you didn't test it yet, and that
there may be several subtle regressions we wouldn't pick up until it shipped,
because of workarounds around things libvirt didn't (used to) do.

If your target is latest RHEL5, I'm pretty confident that most of the
virtinst/libvirt workarounds are now obsolete. All things considered, RHEL5.7
has pretty modern libvirt and virtinst.

Not having a lot of time this AM to review…just a few quick questions.

We need to make sure all the disk and network options continue to work, which
were implemented when libvirt didn't provide those capabilities. Does it
support LVM and multiple network interfaces, etc in the exact same way (end
result wise)?

None of the disk or network handling here relies on libvirt's storage/network
management functionality, it should continue to work as before, modulo bugs.

Similarly, I need to know if any options are used are available in newer
distributions but not older, as Cobbler needing to work in say, EL 5, is
vitally important. Typically this has happened in the past, where libvirt was
not running at equal versions on different distros.

If your target is latest RHEL5, there are 2 problems.

- RHEL5 virt-install doesn't have the --boot option. This is used to install
xen PV guests. We could work around this by enabling install_location support
for PV, which xen + virt-install have supported in RHEL5 forever. But not sure
how that meshes with existing deployments getting a cobbler upgrade.

Hmm, who is using Xen PV out there?   Speak up if you are.

I'm willing to shoot it.

- RHEL5 virt-install doesn't had --disk driver_type= for qemu_driver_type
cobbler option. Not as big of a deal, users just can't specify that value on
RHEL5.

I don't think Cobbler users ever specified anything other than the default.
 

But in that vein, currently all koan image/qemu/xen guest creation is broken
on any RHEL5 since October, due to unconditional use of guest.set_autostart
API which isn't in RHEL5.

That's interesting as it does seem to confirm that nobody is using it.

Which seems to align with my thoughts that:

(A)  people don't upgrade too often
(B)  the field is still largely VMware :)

So, yeah.


As for image create, totally, it was added at the request of the oVirt team in
ancient days -- there's no need for it anymore. Please test it live and get
back to me? I don't think it's fair to throw it over the wall and ask the
community folks to test/fix it and this shouldn't
be too hard to do. When you get done, we can ask a few others to try it out
and exercise the corners further.

I'll test on f16 xen + kvm. But TBH I'm not that motivated to blow away a
machine to install RHEL5 and test the variety of combinations there (and I
can't use a VM since this needs testing for fullvirt)

I'd be happy to see if you could install successfully to a LVM partition with
"--virt-disk" or whatever set, and you could create a machine with two NICs.

That would probably be good enough.
 

I could reformat the patch to preserve the old code and only use the new code
if koan can't import virtinst. However from a long term maintenance point of
view, that would be making the already bad koan situation (more or less same
virtinst implementation copied across 2.5 files with varying assortment of
fixes) even worse, since it would add yet another same-but-not-quite
implementation of libvirt guest creation that could miss fixes, etc. But
certainly it would greatly minimize risk for old hosts (but then again if old
hosts really wanted to minimize risk would they be updating? :) /me trolls )

I don't really care so much about keeping the old code around.    I'm mostly
in Linus mode these days.

So if that works for you I'd be happy to adjust the patch.


Further discussion probably belongs on cobbler-devel, and when we get done you
can send me a github pull request to github.com/cobbler

Whoops, I was doing patches against fedorahosted cobbler.git. Someone should
push a commit there marking that repo as dead...

Yes, we should.    Noted… if I still have access, I'll do it, if not, will ask Scott
or James.  

And sorry about cobbler vs. cobbler-devel, I'll subscribe.

No problem, thanks! 

Thanks,
Cole