[libvirt] [PATCH RFC V2] guests: Add support for openSUSE
Andrea Bolognani
abologna at redhat.com
Mon Dec 2 19:33:48 UTC 2019
On Mon, 2019-12-02 at 16:41 +0100, Fabiano Fidêncio wrote:
> Jim,
>
> Firstly, sorry it took so long for me to give it a try in your patch.
>
> Now, comments inline ...
>
> On Tue, Nov 26, 2019 at 1:52 AM Jim Fehlig <jfehlig at suse.com> wrote:
> > This change adds support for the latest openSUSE Leap and
> > openSUSE Tumbleweed guests.
> >
> > Signed-off-by: Jim Fehlig <jfehlig at suse.com>
> > ---
> >
> > This version of the patch overcomes the 'lci build' issues noted in V1
> > and works well for openSUSE Leap 15.1 and Tumbleweed. I'm still of the
> > opinion of only supporting the latest Leap since there is only a six
> > month support overlap between versions. Version x-1 is only supported
> > six months after x is released.
>
> I will leave this up to you and Andrea. I'd say, whatever floats your boat. :-)
That won't work if, as you said earlier, you can't seamlessly move
from eg. 15.1 to 15.2: either you can move from one minor version to
the next with a simple upgrade, as is the case for CentOS and Debian,
or you need to consider the two as separate entities, as is the case
for Fedora, otherwise libvirt-opensuse-15 will mean vastly different
things depending on whether you installed in the 15.1 timeframe or
in the 15.2 timeframe...
It's annoying, but I'm afraid we're going to have to include the
minor version number in the name even though we're only likely to
ever support one 42.x and one 15.x at any given time.
One more note about naming: I just remembered why I decided for
libvirt-ubuntu-18 instead of the more obvious libvirt-ubuntu-18.04
back then: the guest name is also used as the hostname, and I wanted
to avoid having extra dots in the latter. Perhaps that's overzealous
of me, but assuming we want to stick with that principle then we
should call this libvirt-opensuse-151, and later rename the
aforementioned to libvirt-ubuntu-1804 to be consistent.
> > 'lci update ... libvirt' fails in task "Configure hostname":
> >
> > fatal: [libvirt-opensuse-tumbleweed]: FAILED! => {"changed": false, "msg": "hostname module cannot be used on platform Linux (Opensuse-tumbleweed)"}
>
> It seems to be an Ansible bug: https://github.com/ansible/ansible/issues/42726
Is it possible that this failed simply because the hostname command
is not available? You mention this below.
> > Not sure why that is the case. But more importantly, even though it
> > doesn't fail, the "Update installed packages" task doesn't install any
> > of the packages required to build libvirt.
That step merely updates the packages that are already installed.
> > I suppose that agrees with
> > guests/REAMDME, but how then are the packages required to build $project
> > installed? How/when is the list of packages required to build $project
> > conveyed to $package_manager?
That happens later[1].
> > 'lcitool build libvirt-opensuse-tumbleweed libvirt' fails in the
> > "Gathering Facts" task:
> >
> > fatal: [libvirt-opensuse-tumbleweed]: UNREACHABLE! => {"changed": false, "msg": "Invalid/incorrect password: ", "unreachable": true}
>
> I didn't get this far, I'd firstly try to get the first part fixed as
> this whole thing is sequential ...
We can add Leap 15.1 first, and worry about tumbleweed later. It's
probably a good idea to add them in separate commits anyway.
> > Passing --debug to the command didn't help with determining what needed
> > the password. ssh? I can't find where the "Gathering Facts" task is
> > defined.
That's not a custom task, but rather something that Ansible does
automatically when it connects to a host.
> > The $root_password_file passed to /usr/bin/ansible-playbook
> > contains the correct password for the root user. /me needs to figure
> > out how to better debug this stuff :-).
I'm pretty sure 'lcitool build' failed simply because 'lcitool
update' failed before it, and more specifically didn't manage to get
far enough to set up a regular user to use for builds.
I agree debugging this kind of issue is not exactly trivial...
Unfortunately there's no easy solution to the problem either :(
> > +++ b/guests/configs/autoinst.xml
> > @@ -0,0 +1,75 @@
> > +<?xml version="1.0"?>
> > +<!DOCTYPE profile>
> > +<profile
> > + xmlns="http://www.suse.com/1.0/yast2ns"
> > + xmlns:config="http://www.suse.com/1.0/configns">
> > + <general>
> > + <mode>
> > + <confirm config:type="boolean">false</confirm>
>
> Here, please, also add:
> <second_stage config:type="boolean">false</second_stage>
>
> It'll avoid an unnecessary reboot in the VM.
I didn't test this, but it sounds reasonable. I'll give it an actual
go tomorrow :)
[...]
> > + <software>
> > + <install_recommended config:type="boolean">false</install_recommended>
> > + <products config:type="list">
> > + <product>openSUSE</product>
> > + </products>
> > + <patterns config:type="list">
> > + <pattern>base</pattern>
> > + <pattern>minimal_base</pattern>
> > + <pattern>yast2_basis</pattern>
> > + </patterns>
> > + <packages config:type="list">
>
> Here, please, also add:
> <package>hostname</package>
>
> Seems that lcitools rely on having hostname installed in the machine
> and "hostname" is used before actually installing the packages. Or,
> IOW, trying to install the package afterwards wouldn't work. (I gave
> it a try).
This also sounds good.
> > +++ b/guests/host_vars/libvirt-opensuse-15/docker.yml
> > @@ -0,0 +1,2 @@
> > +---
> > +docker_base: opensuse/leap:15
This should point to
opensuse/leap:15.1
instead.
> > +++ b/guests/host_vars/libvirt-opensuse-15/main.yml
> > @@ -0,0 +1,22 @@
> > +---
> > +projects:
> > + - libosinfo
> > + - libvirt
> > + - libvirt-cim
> > + - libvirt-dbus
> > + - libvirt-glib
> > + - libvirt-perl
> > + - libvirt-python
> > + - libvirt-sandbox
> > + - libvirt-tck
> > + - osinfo-db
> > + - osinfo-db-tools
> > + - virt-manager
> > + - virt-viewer
Since right now we're only aiming at building libvirt, we should only
list that project: it's a good starting point, and we can add more as
we make sure we can actually 'lcitool build' them successfully.
> > +package_format: 'rpm'
> > +package_manager: 'zypper'
> > +os_name: 'OpenSUSE'
> > +os_version: '15'
os_version should be '151' if we follow the naming scheme outlined
earlier.
[...]
> > +++ b/guests/lcitool
> > - name: Clean up packages after update
> > shell: '{{ package_manager }} clean packages -y && {{ package_manager }} autoremove -y'
> > args:
> > warn: no
> > when:
> > - package_format == 'rpm'
> > + - not os_name == "OpenSUSE"
This should be
os_name != 'OpenSUSE'
[...]
> > +++ b/guests/vars/mappings.yml
> > perl-Archive-Tar:
> > deb: perl
> > pkg: perl5
> > rpm: perl-Archive-Tar
> > + OpenSUSE: perl-Archive-Tar-Wrapper
This doesn't look right:
[test at libvirt-fedora-31 ~]$ rpm -ql perl-Archive-Tar
/usr/bin/ptar
/usr/bin/ptardiff
/usr/bin/ptargrep
/usr/share/doc/perl-Archive-Tar
/usr/share/doc/perl-Archive-Tar/CHANGES
/usr/share/doc/perl-Archive-Tar/README
/usr/share/man/man1/ptar.1.gz
/usr/share/man/man1/ptardiff.1.gz
/usr/share/man/man1/ptargrep.1.gz
/usr/share/man/man3/Archive::Tar.3pm.gz
/usr/share/man/man3/Archive::Tar::File.3pm.gz
/usr/share/perl5/vendor_perl/Archive
/usr/share/perl5/vendor_perl/Archive/Tar
/usr/share/perl5/vendor_perl/Archive/Tar.pm
/usr/share/perl5/vendor_perl/Archive/Tar/Constant.pm
/usr/share/perl5/vendor_perl/Archive/Tar/File.pm
[test at libvirt-fedora-31 ~]$
[test at libvirt-opensuse-15 ~]$ rpm -ql perl-Archive-Tar-Wrapper
/usr/lib/perl5/vendor_perl/5.26.1/Archive
/usr/lib/perl5/vendor_perl/5.26.1/Archive/Tar
/usr/lib/perl5/vendor_perl/5.26.1/Archive/Tar/Wrapper.pm
/usr/lib/perl5/vendor_perl/5.26.1/x86_64-linux-thread-multi
/usr/share/doc/packages/perl-Archive-Tar-Wrapper
/usr/share/doc/packages/perl-Archive-Tar-Wrapper/Changes
/usr/share/doc/packages/perl-Archive-Tar-Wrapper/README
/usr/share/man/man3/Archive::Tar::Wrapper.3pm.gz
[test at libvirt-opensuse-15 ~]$
> > python2-setuptools:
> > CentOS7: python2-setuptools
> > + OpenSUSE: python2-setuptools
We might be able to get away without installing Python 2 packages;
they certainly shouldn't be necessary to build libvirt.
> > python3-pip:
> > CentOS7: python3-pip
> > Debian9: python3-pip
> > + OpenSUSE: python3-pip
> > Ubuntu16: python3-pip
> > Ubuntu18: python3-pip
Installing pip isn't necessary either, since openSUSE Leap 15.1
contains Meson.
> > wireshark:
> > deb: wireshark-dev
> > Fedora: wireshark-devel
> > + OpenSUSE: wireshark-devel
> > cross-policy-deb: skip
This now makes more sense as
wireshark:
deb: wireshark-dev
rpm: wireshark-devel
CentOS:
cross-policy-deb: skip
> > xen:
> > Fedora: xen-devel
> > + OpenSUSE: xen-devel
> > x86_64-deb: libxen-dev
> > armv7l-deb: libxen-dev
> > aarch64-deb: libxen-dev
Same as above.
> Apart from the comments inline, I had to add the following patch in
> order to get Leap working:
>
> ```
> diff --git a/guests/playbooks/build/jobs/defaults.yml
> b/guests/playbooks/build/jobs/defaults.yml
> index 48cf643..eb4dfd5 100644
> --- a/guests/playbooks/build/jobs/defaults.yml
> +++ b/guests/playbooks/build/jobs/defaults.yml
> @@ -10,6 +10,7 @@ all_machines:
> - libvirt-freebsd-11
> - libvirt-freebsd-12
> - libvirt-freebsd-current
> + - libvirt-opensuse-15
> - libvirt-ubuntu-16
> - libvirt-ubuntu-18
> rpm_machines:
> diff --git a/guests/playbooks/build/projects/libvirt.yml
> b/guests/playbooks/build/projects/libvirt.yml
> index 4b3dfdf..3e3dbba 100644
> --- a/guests/playbooks/build/projects/libvirt.yml
> +++ b/guests/playbooks/build/projects/libvirt.yml
> @@ -19,6 +19,7 @@
> - libvirt-fedora-30
> - libvirt-fedora-31
> - libvirt-fedora-rawhide
> + - libvirt-opensuse-15
> - libvirt-ubuntu-16
> - libvirt-ubuntu-18
> - include: '{{ playbook_base }}/jobs/autotools-check-job.yml'
These changes are only necessary to make 'lcitool build' work, and
should go in a separate commit.
> diff --git a/guests/playbooks/update/tasks/paths.yml
> b/guests/playbooks/update/tasks/paths.yml
> index 770680e..c258ad2 100644
> --- a/guests/playbooks/update/tasks/paths.yml
> +++ b/guests/playbooks/update/tasks/paths.yml
> @@ -17,7 +17,7 @@
> - su
>
> - name: 'Look for files'
> - shell: 'find /etc /usr/local/etc -name {{ item }} 2>/dev/null'
> + shell: 'find /usr/local/etc -name {{ item }} 2>/dev/null || find
> /etc -name {{ item }} 2>/dev/null'
> register: find
> with_items:
> - sudoers
> diff --git a/guests/playbooks/update/tasks/users.yml
> b/guests/playbooks/update/tasks/users.yml
> index 0470686..bf149da 100644
> --- a/guests/playbooks/update/tasks/users.yml
> +++ b/guests/playbooks/update/tasks/users.yml
> @@ -18,12 +18,18 @@
> line: 'PermitRootLogin without-password'
> state: present
>
> +- name: '{{ flavor }}: Ensure group exists'
> + group:
> + name: '{{ flavor }}'
> + state: present
> +
> - name: '{{ flavor }}: Create user account'
> user:
> name: '{{ flavor }}'
> comment: '{{ flavor }}'
> password: '*'
> shell: '{{ bash }}'
> + group: '{{ flavor }}'
>
> - name: '{{ flavor }}: Set password'
> user:
> ```
>
> I know Andrea suggested to change the way we deal with finding sudoers
> but, IMHO, it shouldn't be a blocker for your patches. However, I'm
> *not* the maintainer of the project. :-)
I've posted these separately in
https://www.redhat.com/archives/libvir-list/2019-December/msg00065.html
and Fabiano already reviewed them! So consider them merged :)
> So, with those changes, Leap works and we can build libvirt.
>
> What I'd suggest:
> - Submit a patch just adding Leap (and then you'll have to have an
> agreement with Andrea about whether we'll support 15 or 15.x);
> - After that, let's try to figure out the issue with Tumbleweed and,
> only then, try to have it merged;
>
> Does that make sense? Andrea, Jim, are we on the same page here?
Yeah, we should get Leap 15.1 working first, and only then worry
about Tumbleweed.
Speaking of which: I've run into a fairly major problem with
the Leap 15.1 support enabled by this patch: while unattended
installation works as expected on my laptop (Fedora 31), when I try
the same steps on the CentOS CI production environment (CentOS 7.5)
it doesn't seem to find or recognize the autoinst.xml file: instead,
I get a "please make sure your installation medium is available"
message and the chance to input the information manually, which is
obviously not what we want :) I'll try to figure out what's going
wrong tomorrow.
[1] guests/playbooks/update/tasks/packages.yml
--
Andrea Bolognani / Red Hat / Virtualization
More information about the libvir-list
mailing list