5:54 p.m.
Change distro in the output formally known as virt-inspector to reflect the
actual distro. Possible values are now: fedora, rhel, centos, scientific,
debian.
Add new distrofamily entry which is one of: redhat, debian. Currently all
distros except 'debian' are in the redhat family.
This allows you to, for example, select a RHEL/CentOS/Scientific Linux specific
kernel for installation rather than assuming they're all the same.
---
perl/lib/Sys/Guestfs/Lib.pm | 58 ++++++++++++++++++++++++++++++++++---------
1 files changed, 46 insertions(+), 12 deletions(-)
diff --git a/perl/lib/Sys/Guestfs/Lib.pm b/perl/lib/Sys/Guestfs/Lib.pm
index 925c494..df3bbe1 100644
--- a/perl/lib/Sys/Guestfs/Lib.pm
+++ b/perl/lib/Sys/Guestfs/Lib.pm
@@ -475,8 +475,13 @@ Filesystem content, if we could determine it. One of:
"linux-grub",
=item osdistro
(For Linux root partitions only).
-Operating system distribution. One of: "fedora", "redhat",
-"debian".
+Operating system distribution. One of: "fedora", "rhel",
"centos",
+"scientific", "debian".
+
+=item osdistrofamily
+
+(For Linux root partitions only)
+Operating system distribution family. One of: "redhat", "debian".
=item osversion
@@ -609,20 +614,47 @@ sub _check_linux_root
# Look into /etc to see if we recognise the operating system.
if ($g->is_file ("/etc/redhat-release")) {
+ $r->{osdistrofamily} = "redhat";
+
$_ = $g->cat ("/etc/redhat-release");
if (/Fedora release (\d+\.\d+)/) {
$r->{osdistro} = "fedora";
$r->{osversion} = "$1"
- } elsif (/(Red Hat Enterprise Linux|CentOS|Scientific Linux).*release (\d+).*Update
(\d+)/) {
- $r->{osdistro} = "redhat";
- $r->{osversion} = "$2.$3";
- } elsif (/(Red Hat Enterprise Linux|CentOS|Scientific Linux).*release
(\d+(?:\.(\d+))?)/) {
- $r->{osdistro} = "redhat";
- $r->{osversion} = "$2";
- } else {
- $r->{osdistro} = "redhat";
+ }
+
+ elsif (/(Red Hat Enterprise Linux|CentOS|Scientific Linux)/) {
+ my $distro = $1;
+
+ if($distro eq "Red Hat Enterprise Linux") {
+ $r->{osdistro} = "rhel";
+ }
+
+ elsif($distro eq "CentOS") {
+ $r->{osdistro} = "centos";
+ }
+
+ elsif($distro eq "Scientific Linux") {
+ $r->{osdistro} = "scientific";
+ }
+
+ # Shouldn't be possible
+ else { die };
+
+ if (/$distro.*release (\d+).*Update (\d+)/) {
+ $r->{osversion} = "$1.$2";
+ }
+
+ elsif (/$distro.*release (\d+(?:\.(?:\d+))?)/) {
+ $r->{osversion} = "$1";
+ }
+ }
+
+ else {
+ $r->{osdistro} = "redhat-based";
}
} elsif ($g->is_file ("/etc/debian_version")) {
+ $r->{osdistrofamily} = "debian";
+
$_ = $g->cat ("/etc/debian_version");
if (/(\d+\.\d+)/) {
$r->{osdistro} = "debian";
@@ -883,6 +915,8 @@ sub _get_os_version
$r->{os} = $r->{root}->{fsos} if exists $r->{root}->{fsos};
$r->{distro} = $r->{root}->{osdistro} if exists
$r->{root}->{osdistro};
+ $r->{distrofamily} = $r->{root}->{osdistrofamily}
+ if exists $r->{root}->{osdistrofamily};
$r->{version} = $r->{root}->{osversion} if exists
$r->{root}->{osversion};
}
@@ -1063,8 +1097,8 @@ sub _check_for_applications
my $osn = $os->{os};
if ($osn eq "linux") {
- my $distro = $os->{distro};
- if (defined $distro && ($distro eq "redhat" || $distro eq
"fedora")) {
+ my $family = $os->{distrofamily};
+ if (defined $family && $family eq "redhat") {
my @lines = $g->command_lines
(["rpm",
"-q", "-a",
--
1.6.2.5
5:21 a.m.
On Thu, Jul 16, 2009 at 11:54:55PM +0100, Matthew Booth wrote:
Change distro in the output formally known as virt-inspector to
reflect the
actual distro. Possible values are now: fedora, rhel, centos, scientific,
debian.
Add new distrofamily entry which is one of: redhat, debian. Currently all
distros except 'debian' are in the redhat family.
This allows you to, for example, select a RHEL/CentOS/Scientific Linux specific
kernel for installation rather than assuming they're all the same.
IMHO doing this is a big mistake. This is what we did for virt-install
and hugely regret it. Things just don't fall into a nice hierarchy. We
are now looking at doing a flat list of distros + tagging/categorization
relationships to be defined.
http://www.redhat.com/archives/et-mgmt-tools/2009-June/msg00018.html
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 :|
6:06 a.m.
On 17/07/09 11:21, Daniel P. Berrange wrote:
IMHO doing this is a big mistake. This is what we did for
virt-install
and hugely regret it. Things just don't fall into a nice hierarchy. We
are now looking at doing a flat list of distros + tagging/categorization
relationships to be defined.
http://www.redhat.com/archives/et-mgmt-tools/2009-June/msg00018.html
Thanks, Dan.
What problems did you hit? I'm inclined to think I might get away with
it for virt-v2v because we also have so much other additional info about
the system. So far, 'redhat' pretty much means it uses rpm rather than
anything else.
Are you actually doing OS detection, or is this just for filling in
distro-specific defaults? What sort of data do you have on individual
distros?
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
6:21 a.m.
On Fri, Jul 17, 2009 at 12:06:31PM +0100, Matthew Booth wrote:
On 17/07/09 11:21, Daniel P. Berrange wrote:
> IMHO doing this is a big mistake. This is what we did for virt-install
> and hugely regret it. Things just don't fall into a nice hierarchy. We
> are now looking at doing a flat list of distros + tagging/categorization
> relationships to be defined.
>
> http://www.redhat.com/archives/et-mgmt-tools/2009-June/msg00018.html
Thanks, Dan.
What problems did you hit? I'm inclined to think I might get away with
it for virt-v2v because we also have so much other additional info about
the system. So far, 'redhat' pretty much means it uses rpm rather than
anything else.
How about instead of "distrofamily" we add flags to tell us what
we actually want to know:
uses_rpm
uses_dpkg
Rich.
--
Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
6:41 a.m.
On 17/07/09 12:21, Richard W.M. Jones wrote:
On Fri, Jul 17, 2009 at 12:06:31PM +0100, Matthew Booth wrote:
> On 17/07/09 11:21, Daniel P. Berrange wrote:
>> IMHO doing this is a big mistake. This is what we did for virt-install
>> and hugely regret it. Things just don't fall into a nice hierarchy. We
>> are now looking at doing a flat list of distros + tagging/categorization
>> relationships to be defined.
>>
>> http://www.redhat.com/archives/et-mgmt-tools/2009-June/msg00018.html
> Thanks, Dan.
>
> What problems did you hit? I'm inclined to think I might get away with
> it for virt-v2v because we also have so much other additional info about
> the system. So far, 'redhat' pretty much means it uses rpm rather than
> anything else.
How about instead of "distrofamily" we add flags to tell us what
we actually want to know:
uses_rpm
uses_dpkg
or, as this would be single-os specific:
package_management=rpm
package_management=dpkg
My only concern about that scheme is that at this point we have little
idea about what we need to know. I guess it won't be too hard to add it
as we go along.
I can make this change on Monday morning if you like.
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
4:12 a.m.
On Fri, Jul 17, 2009 at 12:41:04PM +0100, Matthew Booth wrote:
On 17/07/09 12:21, Richard W.M. Jones wrote:
>On Fri, Jul 17, 2009 at 12:06:31PM +0100, Matthew Booth wrote:
>>On 17/07/09 11:21, Daniel P. Berrange wrote:
>>>IMHO doing this is a big mistake. This is what we did for virt-install
>>>and hugely regret it. Things just don't fall into a nice hierarchy. We
>>>are now looking at doing a flat list of distros + tagging/categorization
>>>relationships to be defined.
>>>
>>> http://www.redhat.com/archives/et-mgmt-tools/2009-June/msg00018.html
>>Thanks, Dan.
>>
>>What problems did you hit? I'm inclined to think I might get away with
>>it for virt-v2v because we also have so much other additional info about
>>the system. So far, 'redhat' pretty much means it uses rpm rather than
>>anything else.
>
>How about instead of "distrofamily" we add flags to tell us what
>we actually want to know:
>
> uses_rpm
> uses_dpkg
or, as this would be single-os specific:
package_management=rpm
package_management=dpkg
Yep, this looks good to me, though perhaps name it 'package_format', unless
you are actually wanting to represent the basic package tool vs format.
This packaging stuff is a great example of the trouble of the distro
family idea. eg, if you wanted to track the package type, then you'd want
fedora + rhel together, since they both use rpm. If you wanted to track
package repository service, then you'd want fedora & rhel separate (aka,
YUM repo vs RHN). If you wanted to track package mgmt command line tool,
then you'd want fedora + rhel5 separate from rhel <= 4, (aka
'/usr/bin/yum'
vs '/usr/bin/up2date'). So even for the simple task of package mgmt, the
'distrofamily' is insufficiently expressive
My only concern about that scheme is that at this point we have
little
idea about what we need to know. I guess it won't be too hard to add it
as we go along.
I think this is a benefit ! You can trivially add new metadata tags for
specific things you discover you need to track, and not have to worry
about typing to squash them into an ill-fitting distro-family set.
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 :|
6:50 a.m.
On Fri, Jul 17, 2009 at 12:06:31PM +0100, Matthew Booth wrote:
On 17/07/09 11:21, Daniel P. Berrange wrote:
>IMHO doing this is a big mistake. This is what we did for virt-install
>and hugely regret it. Things just don't fall into a nice hierarchy. We
>are now looking at doing a flat list of distros + tagging/categorization
>relationships to be defined.
>
> http://www.redhat.com/archives/et-mgmt-tools/2009-June/msg00018.html
Thanks, Dan.
What problems did you hit? I'm inclined to think I might get away with
it for virt-v2v because we also have so much other additional info about
the system. So far, 'redhat' pretty much means it uses rpm rather than
anything else.
A hierarchy was insufficiently flexible. eg, you can't represent fact
that CentOS and RHEL are essentially identical. Can't represent that
RHEL-5.3 has VirtIO, but RHEL-5.2 does not. Can't represent the idea
of one distro being a newer version of another. THe core problem is
that different pieces of information you care about imply different
types of hierarchy or relationship, to the extent that you cannot have
a single hierarchy that works. The only conclusion I could come to is
that hiearchies are fundamentally the wrong approach, and that a flat
list of distros + metadata tagging/categorization was what we needed.
You can of course later construct arbitrary hierarchies at a UI level
from the metadata.
Are you actually doing OS detection, or is this just for filling in
distro-specific defaults? What sort of data do you have on individual
distros?
We detect the OS type from the install media using a variety of
heuristics. eg, looking for $URL/.treeinfo to identify Fedora
distros. Once we've determined the distro, we lookup various
bits of device info in the OS dictionary such as whether to
use virtio, enable ACPI/APIC, whether it can do Xen paravirt
CDROM device, the type of mouse to configure, preferred clock
sync mode, etc, etc
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 :|
5528
days inactive
5532
days old
6 comments
3 participants
participants (3)
-
Daniel P. Berrange -
Matthew Booth -
Richard W.M. Jones