Add --list-os-options to virt-install and virt-convert
 

Add an option '--list-os-options' to virt-install and virt-convert to
dump the valid os-type/variant values from our internal OS dictionary
(then exit). Prior to this, the only way a user knew what to pass was
via the quite outdated man pages, or via virt-manager (which reads the
OS dictionary from virtinst).

On one side I'm hesitant about this: we are going to expand this OS
metadata in the future with a potentially more granular approach (ex.
RHEL5.1/2/3 instead of just RHEL5), and giving the illusion that this is
stable (and machine parseable) may make it harder to deviate later.

That said, this solution is clearly much more useful and sustainable
than the current situation, so until we work out something better I
think this patch is the way to go.

Example output:

$ ./virt-install --list-os-options
TYPE : VARIANT
--------------
linux : debianetch
linux : debianlenny
linux : fedora5
linux : fedora6
linux : fedora7
linux : fedora8
linux : fedora9
linux : fedora10
linux : fedora11
linux : generic24
linux : generic26
linux : virtio26
linux : rhel2.1
linux : rhel3
linux : rhel4
linux : rhel5
linux : sles10
linux : ubuntuhardy
other : generic
other : msdos
other : netware4
other : netware5
other : netware6
solaris : opensolaris
solaris : solaris10
solaris : solaris9
unix : freebsd6
unix : freebsd7
unix : openbsd4
windows : vista
windows : win2k
windows : win2k3
windows : win2k8
windows : winxp
windows : winxp64

Thanks,
Cole
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools

Add --list-os-options to virt-install and virt-convert
 

On Mon, Mar 02, 2009 at 06:00:54PM -0500, Cole Robinson wrote:
> Add an option '--list-os-options' to virt-install and virt-convert to
> dump the valid os-type/variant values from our internal OS dictionary
> (then exit). Prior to this, the only way a user knew what to pass was
> via the quite outdated man pages, or via virt-manager (which reads the
> OS dictionary from virtinst).
>
> On one side I'm hesitant about this: we are going to expand this OS
> metadata in the future with a potentially more granular approach (ex.
> RHEL5.1/2/3 instead of just RHEL5), and giving the illusion that this is
> stable (and machine parseable) may make it harder to deviate later.
>
> That said, this solution is clearly much more useful and sustainable
> than the current situation, so until we work out something better I
> think this patch is the way to go.

How about making the build process extract this list and stuff
them into the POD man page, so it is always up2date ?

Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@redhat.com
https://www.redhat.com/mailman/listinfo/et-mgmt-tools