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 
> > (http://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
>  
>  


_______________________________________________
cobbler mailing list
cobbler@lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler

Reply via email to