Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Fedora/Linux Management Tools (http://www.linux-archive.org/fedora-linux-management-tools/)
-   -   Add --list-os-options to virt-install and virt-convert (http://www.linux-archive.org/fedora-linux-management-tools/255926-add-list-os-options-virt-install-virt-convert.html)

Cole Robinson 03-02-2009 11:24 PM

Add --list-os-options to virt-install and virt-convert
 
Daniel P. Berrange wrote:
> 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 ?
>

That works too.

Do you think it should be in all relevant man pages (virt-convert,
virt-image, virt-install) or just have the other two link back to
virt-install?

- Cole

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

John Levon 03-02-2009 11:57 PM

Add --list-os-options to virt-install and virt-convert
 
On Mon, Mar 02, 2009 at 07:24:41PM -0500, Cole Robinson wrote:

> Do you think it should be in all relevant man pages (virt-convert,
> virt-image, virt-install) or just have the other two link back to
> virt-install?

Just the one please :)

Any thought been given to moving all of osdict into a system-installed
XML file? The parameters of how different operating systems behave are
only going to get more complex. Note that OVF will need a similar (in
fact, most likely more complex) database for the virtual platforms.

regards
john

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

"Daniel P. Berrange" 03-03-2009 07:43 AM

Add --list-os-options to virt-install and virt-convert
 
On Mon, Mar 02, 2009 at 07:57:38PM -0500, John Levon wrote:
> On Mon, Mar 02, 2009 at 07:24:41PM -0500, Cole Robinson wrote:
>
> > Do you think it should be in all relevant man pages (virt-convert,
> > virt-image, virt-install) or just have the other two link back to
> > virt-install?
>
> Just the one please :)
>
> Any thought been given to moving all of osdict into a system-installed
> XML file? The parameters of how different operating systems behave are
> only going to get more complex. Note that OVF will need a similar (in
> fact, most likely more complex) database for the virtual platforms.

Absolutely, this is the long term approach we want to take for a number
of reasons. There's quite a few things I don't like about how we are
currently handling it

- It is not possible for local admins to change / extend it, eg to
add new OS distribution release. It is guarenteed to be out of date
almost as soon as each new virtinst release ships, due to frequency
of new OS distros. This is particularly bad for RHEL with its 6 month
cycle between update releases

- It is tied into virt-install & apps based on it. This makes it hard
to use from Cobbler, oVirt, VMWare, or any other virt provisioning
tool that's not using virt-install python APIs

- It does not include enough information. Type + variant are not really
sufficient. RHEL-5 has updates where new capabilities appear like
virt IO. We really need at least a 4 level grouping for some OS, eg
family (Red Hat), distro (RHEL), release (RHEL5), update (RHEL-5.3).

- It ignores the installation URL information. When doing net installs
user has to specify URL to download.fedora.redhat.com and virtinstall
has the fragile probing to validate this. The OS metadata could easily
include the mirror URLs for any free distro


Todo a better job there's several things I want todo with this:

- An XML schema for defining all the information wrt to guest OS distros
that is relevant to virt management tools.

- A C library for querying the information in the XML file(s).

- Bindings of the C library into Python/Ruby etc as needed

- Ability for local admins to extend / override the information either
by editing the XML files directly, or a pretty GUI


The XML schema is the really important thing, but I think it'd be very
important to have a API around it and not expect apps to read the XML
directly. This is because to get sufficient flexibility without huge
amounts of duplication, I think we'll need to try and keep the XML doc
highly normalized, and not just a plain tree - think more of a structure
like RDF where there are many tree's cross-referencing each other.

I'm attaching an example XML doc I knocked up a few months ago, but I'm
not really happy with it as is. In particular I think rather than trying
todo a explicit 4 level (family, disto, release, update) hierarchy, it
should just be doing an arbitrary generic nested structure, without
imposing specific terminology on each level - there's just too much
difference between the OS out there.

The representation of supported drivers isn't all that great either - albeit
better than current way. I was trying to keep two lists - sets of configs
inheriting from each other, and refernce them from OS distros. This doesn't
capture the full horror of the combinations in the real world though. I
feel it might be better to try and maintain an explicit list of emulated
devices per (hypervisor, release), and an explicit list of supported
device drivers per (os distro, release), then compute the intersection.

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

Cole Robinson 03-03-2009 08:53 PM

Add --list-os-options to virt-install and virt-convert
 
John Levon wrote:
> On Mon, Mar 02, 2009 at 07:24:41PM -0500, Cole Robinson wrote:
>
>> Do you think it should be in all relevant man pages (virt-convert,
>> virt-image, virt-install) or just have the other two link back to
>> virt-install?
>
> Just the one please :)
>

Cool, 'python setup.py sdist' will now stuff the current osdict list in
virt-install.pod and remake the man files (I did this only for sdist, so
there isn't a build requirement on pod2man).

Thanks,
Cole

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


All times are GMT. The time now is 04:54 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.