[libvirt] [jenkins-ci] guests: Add support for openSUSE Leap 15.1
Signed-off-by: Jim Fehlig <jfehlig@suse.com> --- guests/configs/autoinst.xml | 86 +++++++++++++++++++ .../libvirt-opensuse-15.1/docker.yml | 2 + .../libvirt-opensuse-15.1/install.yml | 2 + .../host_vars/libvirt-opensuse-15.1/main.yml | 22 +++++ guests/inventory | 1 + guests/lcitool | 2 + guests/vars/mappings.yml | 38 +++++++- 7 files changed, 151 insertions(+), 2 deletions(-) diff --git a/guests/configs/autoinst.xml b/guests/configs/autoinst.xml new file mode 100644 index 0000000..9b93a29 --- /dev/null +++ b/guests/configs/autoinst.xml @@ -0,0 +1,86 @@ +<?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> + </mode> + </general> + <partitioning config:type="list"> + <drive> + <device>/dev/vda</device> + <use>all</use> + <partitions config:type="list"> + <partition> + <filesystem config:type="symbol">swap</filesystem> + <size>500M</size> + <mount>swap</mount> + </partition> + <partition> + <filesystem config:type="symbol">ext4</filesystem> + <mount>/</mount> + <size>max</size> + </partition> + </partitions> + </drive> + </partitioning> + <timezone> + <hwclock>UTC</hwclock> + <timezone>UTC</timezone> + </timezone> + <add-on> + <add_on_products config:type="list"> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/oss/</media_url> + <name>repo-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/oss</media_url> + <name>repo-update</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/non-oss/</media_url> + <name>repo-non-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/non-oss/</media_url> + <name>repo-update-non-oss</name> + </listentry> + </add_on_products> + </add-on> + <software> + <install_recommended config:type="boolean">false</install_recommended> + <patterns config:type="list"> + <pattern>base</pattern> + <pattern>minimal_base</pattern> + <pattern>yast2_basis</pattern> + </patterns> + </software> + <networking> + <keep_install_network config:type="boolean">true</keep_install_network> + </networking> + <users config:type="list"> + <user> + <username>root</username> + <user_password>root</user_password> + <encrypted config:type="boolean">false</encrypted> + <uid>0</uid> + <gid>0</gid> + <home>/root</home> + <shell>/bin/bash</shell> + </user> + </users> + <services-manager> + <default_target>multi-user</default_target> + <services> + <enable config:type="list"> + <service>sshd</service> + </enable> + </services> + </services-manager> + <firewall> + <enable_firewall>true</enable_firewall> + </firewall> +</profile> diff --git a/guests/host_vars/libvirt-opensuse-15.1/docker.yml b/guests/host_vars/libvirt-opensuse-15.1/docker.yml new file mode 100644 index 0000000..1fcbc38 --- /dev/null +++ b/guests/host_vars/libvirt-opensuse-15.1/docker.yml @@ -0,0 +1,2 @@ +--- +docker_base: openSUSE:15.1 diff --git a/guests/host_vars/libvirt-opensuse-15.1/install.yml b/guests/host_vars/libvirt-opensuse-15.1/install.yml new file mode 100644 index 0000000..d0fdbe5 --- /dev/null +++ b/guests/host_vars/libvirt-opensuse-15.1/install.yml @@ -0,0 +1,2 @@ +--- +install_url: http://download.opensuse.org/distribution/leap/15.1/repo/oss/ diff --git a/guests/host_vars/libvirt-opensuse-15.1/main.yml b/guests/host_vars/libvirt-opensuse-15.1/main.yml new file mode 100644 index 0000000..cdd4509 --- /dev/null +++ b/guests/host_vars/libvirt-opensuse-15.1/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 + +package_format: 'rpm' +package_manager: 'zypper' +os_name: 'openSUSE' +os_version: '15.1' + +ansible_python_interpreter: /usr/bin/python3 diff --git a/guests/inventory b/guests/inventory index 3b15513..c86f8cc 100644 --- a/guests/inventory +++ b/guests/inventory @@ -8,5 +8,6 @@ libvirt-fedora-rawhide libvirt-freebsd-11 libvirt-freebsd-12 libvirt-freebsd-current +libvirt-opensuse-15.1 libvirt-ubuntu-16 libvirt-ubuntu-18 diff --git a/guests/lcitool b/guests/lcitool index a630971..39e6853 100755 --- a/guests/lcitool +++ b/guests/lcitool @@ -531,6 +531,8 @@ class Application: install_config = "preseed.cfg" elif facts["os_name"] in ["CentOS", "Fedora"]: install_config = "kickstart.cfg" + elif facts["os_name"] == "openSUSE": + install_config = "autoinst.xml" else: raise Exception( "Host {} doesn't support installation".format(host) diff --git a/guests/vars/mappings.yml b/guests/vars/mappings.yml index bd9b161..ca8eb84 100644 --- a/guests/vars/mappings.yml +++ b/guests/vars/mappings.yml @@ -19,10 +19,10 @@ # - deb, pkg, rpm # # Valid OS names are: -# - CentOS, Debian, Fedora, FreeBSD, Ubuntu +# - CentOS, Debian, Fedora, FreeBSD, openSUSE, Ubuntu # # Valid OS versions are: -# - CentOS7, Debian9, FedoraRawhide, Ubuntu18 and so on +# - CentOS7, Debian9, FedoraRawhide, openSUSE15.1, Ubuntu18 and so on # # The arch specific rules use a prefix "$ARCH-" where $ARCH # is a libvirt arch name. @@ -70,6 +70,7 @@ mappings: apparmor: deb: libapparmor-dev + openSUSE: libapparmor-devel cross-policy-deb: foreign augeas: @@ -117,6 +118,7 @@ mappings: cppi: Fedora: cppi FreeBSD: cppi + openSUSE: cppi cyrus-sasl: deb: libsasl2-dev @@ -127,6 +129,7 @@ mappings: dbus-daemon: default: dbus Fedora: dbus-daemon + openSUSE: dbus-1 device-mapper: deb: libdevmapper-dev @@ -196,6 +199,7 @@ mappings: deb: libglusterfs-dev rpm: glusterfs-api-devel Debian9: glusterfs-common + openSUSE: glusterfs-devel Ubuntu16: glusterfs-common Ubuntu18: glusterfs-common cross-policy-deb: foreign @@ -204,6 +208,7 @@ mappings: deb: libgnutls28-dev pkg: gnutls rpm: gnutls-devel + openSUSE: libgnutls-devel cross-policy-deb: foreign go: @@ -228,6 +233,7 @@ mappings: gtk-update-icon-cache: default: gtk-update-icon-cache + openSUSE: gtk3-tools Ubuntu16: libgtk2.0-bin gtk-vnc2: @@ -248,14 +254,17 @@ mappings: ip: deb: iproute2 rpm: iproute + openSUSE: iproute2 iscsiadm: deb: open-iscsi rpm: iscsi-initiator-utils + openSUSE: open-iscsi isoinfo: default: genisoimage FreeBSD: cdrkit + openSUSE: mkisofs java: deb: openjdk-11-jre-headless @@ -289,6 +298,7 @@ mappings: libaudit: deb: libaudit-dev rpm: audit-libs-devel + openSUSE: audit-devel cross-policy-deb: foreign libblkid: @@ -320,6 +330,7 @@ mappings: deb: libdbus-1-dev pkg: dbus rpm: dbus-devel + openSUSE: dbus-1-devel cross-policy-deb: foreign libgovirt: @@ -347,6 +358,7 @@ mappings: rpm: numactl-devel armv6l-deb: armv7l-deb: + openSUSE: libnuma-devel cross-policy-deb: foreign libparted: @@ -370,6 +382,7 @@ mappings: deb: librbd-dev Fedora: librbd-devel CentOS7: librbd1-devel + openSUSE: librbd-devel cross-policy-deb: foreign libselinux: @@ -436,6 +449,7 @@ mappings: deb: locales Fedora: glibc-langpack-en FreeBSD: + openSUSE: glibc-locale lsof: default: lsof @@ -458,6 +472,7 @@ mappings: ninja: default: ninja-build FreeBSD: ninja + openSUSE: ninja mingw32-curl: Fedora: mingw32-curl @@ -639,6 +654,7 @@ mappings: netcf: deb: libnetcf-dev rpm: netcf-devel + openSUSE: cross-policy-deb: skip net-tools: @@ -678,6 +694,7 @@ mappings: deb: perl pkg: perl5 rpm: perl-Archive-Tar + openSUSE: perl-Archive-Tar-Wrapper perl-CPAN-Changes: deb: libcpan-changes-perl @@ -709,6 +726,7 @@ mappings: deb: libio-compress-perl pkg: p5-IO-Compress rpm: perl-IO-Compress-Bzip2 + openSUSE: perl-Compress-Bzip2 perl-IO-String: deb: libio-string-perl @@ -747,6 +765,7 @@ mappings: deb: libtest-lwp-useragent-perl pkg: p5-Test-LWP-UserAgent Fedora: perl-Test-LWP-UserAgent + openSUSE: perl-Test-LWP-UserAgent perl-Test-Pod: deb: libtest-pod-perl @@ -809,20 +828,24 @@ mappings: deb: python-dev pkg: python2 rpm: python2-devel + openSUSE: python-devel cross-policy-deb: foreign python2-lxml: default: python-lxml Fedora: python2-lxml FreeBSD: py27-lxml + openSUSE: python2-lxml python2-nose: default: python-nose Fedora: python2-nose FreeBSD: py27-nose + openSUSE: python2-nose python2-setuptools: CentOS7: python2-setuptools + openSUSE: python2-setuptools python3: default: python3 @@ -831,6 +854,7 @@ mappings: default: python3-dbus FreeBSD: py36-dbus CentOS7: python36-dbus + openSUSE: python3-dbus-python python3-devel: deb: python3-dev @@ -838,17 +862,20 @@ mappings: Fedora: python3-devel CentOS7: python36-devel cross-policy-deb: foreign + openSUSE: python3-devel python3-gi: deb: python3-gi pkg: py36-gobject3 rpm: python3-gobject CentOS7: python36-gobject + openSUSE: python3-gobject python3-libxml2: default: python3-libxml2 FreeBSD: py36-libxml2 CentOS7: + openSUSE: python3-libxml2-python Ubuntu16: python3-lxml: @@ -864,6 +891,7 @@ mappings: python3-pip: CentOS7: python3-pip Debian9: python3-pip + openSUSE: python3-pip Ubuntu16: python3-pip Ubuntu18: python3-pip @@ -929,6 +957,7 @@ mappings: deb: libspice-client-gtk-3.0-dev pkg: spice-gtk rpm: spice-gtk3-devel + openSUSE: spice-gtk-devel cross-policy-deb: foreign strace: @@ -942,6 +971,7 @@ mappings: deb: iproute2 rpm: iproute-tc CentOS7: iproute + openSUSE: iproute2 unzip: default: unzip @@ -964,10 +994,12 @@ mappings: wireshark: deb: wireshark-dev Fedora: wireshark-devel + openSUSE: wireshark-devel cross-policy-deb: skip xen: Fedora: xen-devel + openSUSE: xen-devel x86_64-deb: libxen-dev armv7l-deb: libxen-dev aarch64-deb: libxen-dev @@ -994,6 +1026,7 @@ mappings: xz-static: deb: liblzma-dev Fedora: xz-static + openSUSE: xz-static-devel cross-policy-deb: foreign yajl: @@ -1015,6 +1048,7 @@ mappings: zlib-static: deb: zlib1g-dev rpm: zlib-static + openSUSE: zlib-devel-static cross-policy-deb: foreign -- 2.23.0
On 11/18/19 5:21 PM, Jim Fehlig wrote:
Signed-off-by: Jim Fehlig <jfehlig@suse.com> --- guests/configs/autoinst.xml | 86 +++++++++++++++++++ .../libvirt-opensuse-15.1/docker.yml | 2 + .../libvirt-opensuse-15.1/install.yml | 2 + .../host_vars/libvirt-opensuse-15.1/main.yml | 22 +++++ guests/inventory | 1 + guests/lcitool | 2 + guests/vars/mappings.yml | 38 +++++++- 7 files changed, 151 insertions(+), 2 deletions(-)
diff --git a/guests/configs/autoinst.xml b/guests/configs/autoinst.xml new file mode 100644 index 0000000..9b93a29 --- /dev/null +++ b/guests/configs/autoinst.xml @@ -0,0 +1,86 @@ +<?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> + </mode> + </general> + <partitioning config:type="list"> + <drive> + <device>/dev/vda</device> + <use>all</use> + <partitions config:type="list"> + <partition> + <filesystem config:type="symbol">swap</filesystem> + <size>500M</size> + <mount>swap</mount> + </partition> + <partition> + <filesystem config:type="symbol">ext4</filesystem> + <mount>/</mount> + <size>max</size> + </partition> + </partitions> + </drive> + </partitioning> + <timezone> + <hwclock>UTC</hwclock> + <timezone>UTC</timezone> + </timezone> + <add-on> + <add_on_products config:type="list"> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/oss/</media_url> + <name>repo-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/oss</media_url> + <name>repo-update</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/non-oss/</media_url> + <name>repo-non-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/non-oss/</media_url> + <name>repo-update-non-oss</name> + </listentry> + </add_on_products> + </add-on> + <software> + <install_recommended config:type="boolean">false</install_recommended> + <patterns config:type="list"> + <pattern>base</pattern> + <pattern>minimal_base</pattern> + <pattern>yast2_basis</pattern> + </patterns> + </software> + <networking> + <keep_install_network config:type="boolean">true</keep_install_network> + </networking> + <users config:type="list"> + <user> + <username>root</username> + <user_password>root</user_password> + <encrypted config:type="boolean">false</encrypted> + <uid>0</uid> + <gid>0</gid> + <home>/root</home> + <shell>/bin/bash</shell> + </user> + </users> + <services-manager> + <default_target>multi-user</default_target> + <services> + <enable config:type="list"> + <service>sshd</service> + </enable> + </services> + </services-manager> + <firewall> + <enable_firewall>true</enable_firewall>
This should be 'false', or perhaps excluded altogether. BTW, with this patch applied (and some workarounds for problems on my end) I'm able to successfully install the guest with 'lcitool install', but update needs some work # ./lcitool update libvirt-opensuse-151 libvirt PLAY [all] ***************************************************************************************************** included: /home/jfehlig/virt/upstream/libvirt-jenkins-ci/guests/playbooks/update/tasks/bootstrap.yml for libvirt-opensuse-151 TASK [set_fact] ************************************************************************************************ ok: [libvirt-opensuse-151] TASK [Bootstrap Ansible] *************************************************************************************** changed: [libvirt-opensuse-151] PLAY [all] ***************************************************************************************************** TASK [Gathering Facts] ***************************************************************************************** ok: [libvirt-opensuse-151] included: /home/jfehlig/virt/upstream/libvirt-jenkins-ci/guests/playbooks/update/tasks/base.yml for libvirt-opensuse-151 TASK [Update installed packages] ******************************************************************************* ok: [libvirt-opensuse-151] TASK [Clean up packages after update] ************************************************************************** fatal: [libvirt-opensuse-151]: FAILED! => {"changed": true, "cmd": "zypper clean packages -y && zypper autoremove -y", "delta": "0:00:00.069846", "end": "2019-11-19 00:29:38.579176", "msg": "non-zero return code", "rc": 2, "start": "2019-11-19 00:29:38.509330", "stderr": "Repository 'packages' not found by its alias, number, or URI.\nRepository '-y' not found by its alias, number, or URI.\nUnknown command 'autoremove'", "stderr_lines": ["Repository 'packages' not found by its alias, number, or URI.", "Repository '-y' not found by its alias, number, or URI.", "Unknown command 'autoremove'"], "stdout": "Use 'zypper repos' to get the list of defined repositories.\nAll repositories have been cleaned up.\nType 'zypper help' to get a list of global options and commands.\n\nIn case 'autoremove' is not a typo it's probably not a built-in command, but provided as a subcommand or plug-in (see 'zypper help subcommand').\nIn this case a specific package providing the subcommand needs to be installed first. Those packages are often named 'zypper-autoremove' or 'zypper-autoremove-plugin'.", "stdout_lines": ["Use 'zypper repos' to get the list of defined repositories.", "All repositories have been cleaned up.", "Type 'zypper help' to get a list of global options and commands.", "", "In case 'autoremove' is not a typo it's probably not a built-in command, but provided as a subcommand or plug-in (see 'zypper help subcommand').", "In this case a specific package providing the subcommand needs to be installed first. Those packages are often named 'zypper-autoremove' or 'zypper-autoremove-plugin'."]} PLAY RECAP ***************************************************************************************************** libvirt-opensuse-151 : ok=6 changed=1 unreachable=0 failed=1 skipped=9 rescued=0 ignored=0 ./lcitool: Failed to run update on 'libvirt-opensuse-151': Command '['/usr/bin/ansible-playbook', '--limit', 'libvirt-opensuse-151', '--extra-vars', '{"selected_projects": ["libvirt"], "git_remote": "default", "root_password_file": "/root/.config/lcitool/root-password", "playbook_base": "/home/jfehlig/virt/upstream/libvirt-jenkins-ci/guests/playbooks/update", "base": "/home/jfehlig/virt/upstream/libvirt-jenkins-ci/guests", "git_branch": "master", "flavor": "test"}', '/home/jfehlig/virt/upstream/libvirt-jenkins-ci/guests/playbooks/update/main.yml']' returned non-zero exit status 2 Looks like I'll need to do some work in the package manager code for zypper. Regards, Jim
Jim, On Tue, Nov 19, 2019 at 1:40 AM Jim Fehlig <jfehlig@suse.com> wrote:
On 11/18/19 5:21 PM, Jim Fehlig wrote:
Signed-off-by: Jim Fehlig <jfehlig@suse.com> --- guests/configs/autoinst.xml | 86 +++++++++++++++++++ .../libvirt-opensuse-15.1/docker.yml | 2 + .../libvirt-opensuse-15.1/install.yml | 2 + .../host_vars/libvirt-opensuse-15.1/main.yml | 22 +++++ guests/inventory | 1 + guests/lcitool | 2 + guests/vars/mappings.yml | 38 +++++++- 7 files changed, 151 insertions(+), 2 deletions(-)
diff --git a/guests/configs/autoinst.xml b/guests/configs/autoinst.xml new file mode 100644 index 0000000..9b93a29 --- /dev/null +++ b/guests/configs/autoinst.xml @@ -0,0 +1,86 @@ +<?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> + </mode> + </general> + <partitioning config:type="list"> + <drive> + <device>/dev/vda</device> + <use>all</use> + <partitions config:type="list"> + <partition> + <filesystem config:type="symbol">swap</filesystem> + <size>500M</size> + <mount>swap</mount> + </partition> + <partition> + <filesystem config:type="symbol">ext4</filesystem> + <mount>/</mount> + <size>max</size> + </partition> + </partitions> + </drive> + </partitioning> + <timezone> + <hwclock>UTC</hwclock> + <timezone>UTC</timezone> + </timezone> + <add-on> + <add_on_products config:type="list"> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/oss/</media_url> + <name>repo-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/oss</media_url> + <name>repo-update</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/non-oss/</media_url> + <name>repo-non-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/non-oss/</media_url> + <name>repo-update-non-oss</name> + </listentry> + </add_on_products> + </add-on> + <software> + <install_recommended config:type="boolean">false</install_recommended> + <patterns config:type="list"> + <pattern>base</pattern> + <pattern>minimal_base</pattern> + <pattern>yast2_basis</pattern> + </patterns> + </software> + <networking> + <keep_install_network config:type="boolean">true</keep_install_network> + </networking> + <users config:type="list"> + <user> + <username>root</username> + <user_password>root</user_password> + <encrypted config:type="boolean">false</encrypted> + <uid>0</uid> + <gid>0</gid> + <home>/root</home> + <shell>/bin/bash</shell> + </user> + </users> + <services-manager> + <default_target>multi-user</default_target> + <services> + <enable config:type="list"> + <service>sshd</service> + </enable> + </services> + </services-manager> + <firewall> + <enable_firewall>true</enable_firewall>
This should be 'false', or perhaps excluded altogether.
BTW, with this patch applied (and some workarounds for problems on my end) I'm able to successfully install the guest with 'lcitool install', but update needs some work
# ./lcitool update libvirt-opensuse-151 libvirt
PLAY [all] ***************************************************************************************************** included: /home/jfehlig/virt/upstream/libvirt-jenkins-ci/guests/playbooks/update/tasks/bootstrap.yml for libvirt-opensuse-151
TASK [set_fact] ************************************************************************************************ ok: [libvirt-opensuse-151]
TASK [Bootstrap Ansible] *************************************************************************************** changed: [libvirt-opensuse-151]
PLAY [all] *****************************************************************************************************
TASK [Gathering Facts] ***************************************************************************************** ok: [libvirt-opensuse-151] included: /home/jfehlig/virt/upstream/libvirt-jenkins-ci/guests/playbooks/update/tasks/base.yml for libvirt-opensuse-151
TASK [Update installed packages] ******************************************************************************* ok: [libvirt-opensuse-151]
TASK [Clean up packages after update] ************************************************************************** fatal: [libvirt-opensuse-151]: FAILED! => {"changed": true, "cmd": "zypper clean packages -y && zypper autoremove -y", "delta": "0:00:00.069846", "end": "2019-11-19 00:29:38.579176", "msg": "non-zero return code", "rc": 2, "start": "2019-11-19 00:29:38.509330", "stderr": "Repository 'packages' not found by its alias, number, or URI.\nRepository '-y' not found by its alias, number, or URI.\nUnknown command 'autoremove'", "stderr_lines": ["Repository 'packages' not found by its alias, number, or URI.", "Repository '-y' not found by its alias, number, or URI.", "Unknown command 'autoremove'"], "stdout": "Use 'zypper repos' to get the list of defined repositories.\nAll repositories have been cleaned up.\nType 'zypper help' to get a list of global options and commands.\n\nIn case 'autoremove' is not a typo it's probably not a built-in command, but provided as a subcommand or plug-in (see 'zypper help subcommand').\nIn this case a specific package providing the subcommand needs to be installed first. Those packages are often named 'zypper-autoremove' or 'zypper-autoremove-plugin'.", "stdout_lines": ["Use 'zypper repos' to get the list of defined repositories.", "All repositories have been cleaned up.", "Type 'zypper help' to get a list of global options and commands.", "", "In case 'autoremove' is not a typo it's probably not a built-in command, but provided as a subcommand or plug-in (see 'zypper help subcommand').", "In this case a specific package providing the subcommand needs to be installed first. Those packages are often named 'zypper-autoremove' or 'zypper-autoremove-plugin'."]}
PLAY RECAP ***************************************************************************************************** libvirt-opensuse-151 : ok=6 changed=1 unreachable=0 failed=1 skipped=9 rescued=0 ignored=0
./lcitool: Failed to run update on 'libvirt-opensuse-151': Command '['/usr/bin/ansible-playbook', '--limit', 'libvirt-opensuse-151', '--extra-vars', '{"selected_projects": ["libvirt"], "git_remote": "default", "root_password_file": "/root/.config/lcitool/root-password", "playbook_base": "/home/jfehlig/virt/upstream/libvirt-jenkins-ci/guests/playbooks/update", "base": "/home/jfehlig/virt/upstream/libvirt-jenkins-ci/guests", "git_branch": "master", "flavor": "test"}', '/home/jfehlig/virt/upstream/libvirt-jenkins-ci/guests/playbooks/update/main.yml']' returned non-zero exit status 2
Looks like I'll need to do some work in the package manager code for zypper.
Yes, what's happening here is that lcitools doesn't know about openSUSE commands for updating, installing, and cleaning up the packages. For pointers, please, take a look at: - For the VMs: - guests/playbooks/update/tasks/base.yml:52 - For the containers: - guests/lcitool:726 I'll play a little bit with this during the day and will let you know the results of my tests. Best Regards, -- Fabiano Fidêncio
On Tue, 2019-11-19 at 00:21 +0000, Jim Fehlig wrote:
Signed-off-by: Jim Fehlig <jfehlig@suse.com> --- guests/configs/autoinst.xml | 86 +++++++++++++++++++ .../libvirt-opensuse-15.1/docker.yml | 2 + .../libvirt-opensuse-15.1/install.yml | 2 + .../host_vars/libvirt-opensuse-15.1/main.yml | 22 +++++ guests/inventory | 1 + guests/lcitool | 2 + guests/vars/mappings.yml | 38 +++++++- 7 files changed, 151 insertions(+), 2 deletions(-)
First of all, thank you for following through with your promise of looking into this! I'm looking forward to being able to merge your changes and finally have proper openSUSE support in our CI :) [...]
+++ b/guests/configs/autoinst.xml + <partitioning config:type="list"> + <drive> + <device>/dev/vda</device> + <use>all</use> + <partitions config:type="list"> + <partition> + <filesystem config:type="symbol">swap</filesystem> + <size>500M</size> + <mount>swap</mount>
We give other guests only 256 MiB of swap, so do the same here to be consistent. Building libvirt and friends is CPU-bound rather than memory-bound anyway, so more than that leeway is not necessary. [...]
+ <add-on> + <add_on_products config:type="list"> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/oss/</media_url> + <name>repo-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/oss</media_url> + <name>repo-update</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/non-oss/</media_url> + <name>repo-non-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/non-oss/</media_url> + <name>repo-update-non-oss</name> + </listentry>
Do we actually need the non-OSS repositories to be updated? I would hope not! But I'm not familiar with how openSUSE organizes its repositories, so I'm going by name only :) [...]
+ <firewall> + <enable_firewall>true</enable_firewall> + </firewall>
As you mention somewhere else, we probably don't need this. [...]
+++ b/guests/host_vars/libvirt-opensuse-15.1/main.yml +package_format: 'rpm' +package_manager: 'zypper' +os_name: 'openSUSE' +os_version: '15.1'
So, about the naming. What I would have done here is os_name: 'OpenSUSE' os_version: '15' The intial capital letter in os_name goes against the actual branding for openSUSE so I'm not perfectly happy with it, but on the other hand it's very useful when defining mappings because package formats all start with a lowercase letter and all OS names start with an uppercase letter. So I would try to stick with that convention. As for os_version, if you look at all existing entries we use the major version number only: eg. we have CentOS7 instead of CentOS7.7 and FreeBSD12 instead of FreeBSD12.1: this makes sense because, as the guest gets updated over time, it will naturally pick up the latest minor release. Will this work for openSUSE too? (Ubuntu is a slight exception in that the major version itself contains a dot, so we just shortened 18.04 to 18 because we know that there's never going to be two LTS releases per year.)
+++ b/guests/host_vars/libvirt-opensuse-15.1/docker.yml @@ -0,0 +1,2 @@ +--- +docker_base: openSUSE:15.1
I believe these images are now deprecated, and opensuse/leap should be used instead. Looking at https://hub.docker.com/r/opensuse/leap/tags I see that the '15.1', '15' and 'latest' tags point to the same set of digests, so that seems to confirm that we can use just 15 as the version number and have docker_base: opensuse/leap:15 in this file. [...]
+++ b/guests/inventory @@ -8,5 +8,6 @@ libvirt-fedora-rawhide libvirt-freebsd-11 libvirt-freebsd-12 libvirt-freebsd-current +libvirt-opensuse-15.1
Based on the points above, I think this could and should be libvirt-opensuse-15 [...]
@@ -127,6 +129,7 @@ mappings: dbus-daemon: default: dbus Fedora: dbus-daemon + openSUSE: dbus-1
You see how weird this looks, due to the first letter being lower case? :) I'm not going to review the mappings in detail right now because I simply lack the time. Once 'lcitool update' works for you without errors, I'll look into it. Fabiano already pointed out where you need to look to sort out the issues you've been experiencing, so I'll leave you to it now :) -- Andrea Bolognani / Red Hat / Virtualization
On Tue, Nov 19, 2019 at 11:33 AM Andrea Bolognani <abologna@redhat.com> wrote:
On Tue, 2019-11-19 at 00:21 +0000, Jim Fehlig wrote:
Signed-off-by: Jim Fehlig <jfehlig@suse.com> --- guests/configs/autoinst.xml | 86 +++++++++++++++++++ .../libvirt-opensuse-15.1/docker.yml | 2 + .../libvirt-opensuse-15.1/install.yml | 2 + .../host_vars/libvirt-opensuse-15.1/main.yml | 22 +++++ guests/inventory | 1 + guests/lcitool | 2 + guests/vars/mappings.yml | 38 +++++++- 7 files changed, 151 insertions(+), 2 deletions(-)
First of all, thank you for following through with your promise of looking into this! I'm looking forward to being able to merge your changes and finally have proper openSUSE support in our CI :)
[...]
+++ b/guests/configs/autoinst.xml + <partitioning config:type="list"> + <drive> + <device>/dev/vda</device> + <use>all</use> + <partitions config:type="list"> + <partition> + <filesystem config:type="symbol">swap</filesystem> + <size>500M</size> + <mount>swap</mount>
We give other guests only 256 MiB of swap, so do the same here to be consistent. Building libvirt and friends is CPU-bound rather than memory-bound anyway, so more than that leeway is not necessary.
[...]
+ <add-on> + <add_on_products config:type="list"> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/oss/</media_url> + <name>repo-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/oss</media_url> + <name>repo-update</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/non-oss/</media_url> + <name>repo-non-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/non-oss/</media_url> + <name>repo-update-non-oss</name> + </listentry>
Do we actually need the non-OSS repositories to be updated? I would hope not! But I'm not familiar with how openSUSE organizes its repositories, so I'm going by name only :)
[...]
+ <firewall> + <enable_firewall>true</enable_firewall> + </firewall>
As you mention somewhere else, we probably don't need this.
[...]
+++ b/guests/host_vars/libvirt-opensuse-15.1/main.yml +package_format: 'rpm' +package_manager: 'zypper' +os_name: 'openSUSE' +os_version: '15.1'
So, about the naming.
What I would have done here is
os_name: 'OpenSUSE' os_version: '15'
The intial capital letter in os_name goes against the actual branding for openSUSE so I'm not perfectly happy with it, but on the other hand it's very useful when defining mappings because package formats all start with a lowercase letter and all OS names start with an uppercase letter. So I would try to stick with that convention.
As for os_version, if you look at all existing entries we use the major version number only: eg. we have CentOS7 instead of CentOS7.7 and FreeBSD12 instead of FreeBSD12.1: this makes sense because, as the guest gets updated over time, it will naturally pick up the latest minor release. Will this work for openSUSE too?
(Ubuntu is a slight exception in that the major version itself contains a dot, so we just shortened 18.04 to 18 because we know that there's never going to be two LTS releases per year.)
+++ b/guests/host_vars/libvirt-opensuse-15.1/docker.yml @@ -0,0 +1,2 @@ +--- +docker_base: openSUSE:15.1
I believe these images are now deprecated, and opensuse/leap should be used instead.
Looking at
https://hub.docker.com/r/opensuse/leap/tags
I see that the '15.1', '15' and 'latest' tags point to the same set of digests, so that seems to confirm that we can use just 15 as the version number and have
docker_base: opensuse/leap:15
in this file.
[...]
+++ b/guests/inventory @@ -8,5 +8,6 @@ libvirt-fedora-rawhide libvirt-freebsd-11 libvirt-freebsd-12 libvirt-freebsd-current +libvirt-opensuse-15.1
Based on the points above, I think this could and should be
libvirt-opensuse-15
[...]
@@ -127,6 +129,7 @@ mappings: dbus-daemon: default: dbus Fedora: dbus-daemon + openSUSE: dbus-1
You see how weird this looks, due to the first letter being lower case? :)
I'm not going to review the mappings in detail right now because I simply lack the time. Once 'lcitool update' works for you without errors, I'll look into it.
Fabiano already pointed out where you need to look to sort out the issues you've been experiencing, so I'll leave you to it now :)
Apart from what I pointed out, I've also faced a few issues when trying out your patch: - grub stays in a loop, forever; - I've worked this around by not setting "--graphics none --console pty" and removing "console=ttyS0" from the extra_arg line; - It really has to be solved in a better way ;-) - Update installed packages: - I've added: ``` +- name: Update installed packages + command: '{{ package_manager }} update -y' + args: + warn: no + when: + - os_name == 'openSUSE' ``` - Clean up packages after update: - I've added: ``` - 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" + +- name: Clean up packages after update + shell: '{{ package_manager }} clean -y' + args: + warn: no + when: + - os_name = "openSUSE" + ``` - Missing mappings: - qemu-img: - Seems that the package doesn't exist in openSUSE. So, please, just do something like: ``` qemu-img: default: qemu-utils rpm: qemu-img + openSUSE: ``` - zfs: - Same as above - yajl: - It seems to be called libyajl-devel for openSUSE - Look for files - There's a "Look for files" rule (in guests/playbooks/update/tasks/paths.yml) which will just bail out as /usr/local/etc doesn't exist in openSUSE. It has to be tweaked as well; - Configure ccache: - This is a rule in guests/playbooks/update/tasks/users.yml, which takes into consideration that when the test user is created, we'll have a test group created as well, which doesn't happen on openSUSE. So, it also need some tweak; I didn't write a patch for those, sorry, but I hope it gives you some idea on the problems I faced (and that you'll face) and how to solve then. Once those are solved/worked around, you'll be able to run the "update" command and then, finally, you'll be able to expand guests/playbooks/build/projects/ in order to add openSUSE there and check whether we can successfully build the projects using openSUSE. Here I'm assuming your main goal is libvirt. Once that's done, I can do the work for libosinfo, osinfo-db-tools, and osinfo-db. Best Regards, -- Fabiano Fidêncio
On 11/19/19 6:52 AM, Fabiano Fidêncio wrote:
On Tue, Nov 19, 2019 at 11:33 AM Andrea Bolognani <abologna@redhat.com> wrote:
On Tue, 2019-11-19 at 00:21 +0000, Jim Fehlig wrote:
Signed-off-by: Jim Fehlig <jfehlig@suse.com> --- guests/configs/autoinst.xml | 86 +++++++++++++++++++ .../libvirt-opensuse-15.1/docker.yml | 2 + .../libvirt-opensuse-15.1/install.yml | 2 + .../host_vars/libvirt-opensuse-15.1/main.yml | 22 +++++ guests/inventory | 1 + guests/lcitool | 2 + guests/vars/mappings.yml | 38 +++++++- 7 files changed, 151 insertions(+), 2 deletions(-)
First of all, thank you for following through with your promise of looking into this! I'm looking forward to being able to merge your changes and finally have proper openSUSE support in our CI :)
[...]
+++ b/guests/configs/autoinst.xml + <partitioning config:type="list"> + <drive> + <device>/dev/vda</device> + <use>all</use> + <partitions config:type="list"> + <partition> + <filesystem config:type="symbol">swap</filesystem> + <size>500M</size> + <mount>swap</mount>
We give other guests only 256 MiB of swap, so do the same here to be consistent. Building libvirt and friends is CPU-bound rather than memory-bound anyway, so more than that leeway is not necessary.
[...]
+ <add-on> + <add_on_products config:type="list"> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/oss/</media_url> + <name>repo-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/oss</media_url> + <name>repo-update</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/non-oss/</media_url> + <name>repo-non-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/non-oss/</media_url> + <name>repo-update-non-oss</name> + </listentry>
Do we actually need the non-OSS repositories to be updated? I would hope not! But I'm not familiar with how openSUSE organizes its repositories, so I'm going by name only :)
[...]
+ <firewall> + <enable_firewall>true</enable_firewall> + </firewall>
As you mention somewhere else, we probably don't need this.
[...]
+++ b/guests/host_vars/libvirt-opensuse-15.1/main.yml +package_format: 'rpm' +package_manager: 'zypper' +os_name: 'openSUSE' +os_version: '15.1'
So, about the naming.
What I would have done here is
os_name: 'OpenSUSE' os_version: '15'
The intial capital letter in os_name goes against the actual branding for openSUSE so I'm not perfectly happy with it, but on the other hand it's very useful when defining mappings because package formats all start with a lowercase letter and all OS names start with an uppercase letter. So I would try to stick with that convention.
As for os_version, if you look at all existing entries we use the major version number only: eg. we have CentOS7 instead of CentOS7.7 and FreeBSD12 instead of FreeBSD12.1: this makes sense because, as the guest gets updated over time, it will naturally pick up the latest minor release. Will this work for openSUSE too?
(Ubuntu is a slight exception in that the major version itself contains a dot, so we just shortened 18.04 to 18 because we know that there's never going to be two LTS releases per year.)
+++ b/guests/host_vars/libvirt-opensuse-15.1/docker.yml @@ -0,0 +1,2 @@ +--- +docker_base: openSUSE:15.1
I believe these images are now deprecated, and opensuse/leap should be used instead.
Looking at
https://hub.docker.com/r/opensuse/leap/tags
I see that the '15.1', '15' and 'latest' tags point to the same set of digests, so that seems to confirm that we can use just 15 as the version number and have
docker_base: opensuse/leap:15
in this file.
[...]
+++ b/guests/inventory @@ -8,5 +8,6 @@ libvirt-fedora-rawhide libvirt-freebsd-11 libvirt-freebsd-12 libvirt-freebsd-current +libvirt-opensuse-15.1
Based on the points above, I think this could and should be
libvirt-opensuse-15
[...]
@@ -127,6 +129,7 @@ mappings: dbus-daemon: default: dbus Fedora: dbus-daemon + openSUSE: dbus-1
You see how weird this looks, due to the first letter being lower case? :)
I'm not going to review the mappings in detail right now because I simply lack the time. Once 'lcitool update' works for you without errors, I'll look into it.
Fabiano already pointed out where you need to look to sort out the issues you've been experiencing, so I'll leave you to it now :)
Apart from what I pointed out, I've also faced a few issues when trying out your patch: - grub stays in a loop, forever; - I've worked this around by not setting "--graphics none --console pty" and removing "console=ttyS0" from the extra_arg line; - It really has to be solved in a better way ;-)
I've wasted way too much time trying to debug this problem. It definitely seems like an issue in our grub 2.02 package. I've reached out to the maintainer for help.
- Update installed packages: - I've added: ``` +- name: Update installed packages + command: '{{ package_manager }} update -y' + args: + warn: no + when: + - os_name == 'openSUSE' ```
- Clean up packages after update: - I've added: ``` - 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" + +- name: Clean up packages after update + shell: '{{ package_manager }} clean -y' + args: + warn: no + when: + - os_name = "openSUSE" + ```
- Missing mappings: - qemu-img: - Seems that the package doesn't exist in openSUSE. So, please, just do something like:
It is included in the qemu-tools package.
``` qemu-img: default: qemu-utils rpm: qemu-img + openSUSE:
So this should be OpenSUSE: qemu-tools (using the uppercase 'O' as Andreas suggested :-)) ?
``` - zfs: - Same as above - yajl: - It seems to be called libyajl-devel for openSUSE
- Look for files - There's a "Look for files" rule (in guests/playbooks/update/tasks/paths.yml) which will just bail out as /usr/local/etc doesn't exist in openSUSE. It has to be tweaked as well;
- Configure ccache: - This is a rule in guests/playbooks/update/tasks/users.yml, which takes into consideration that when the test user is created, we'll have a test group created as well, which doesn't happen on openSUSE. So, it also need some tweak;
I didn't write a patch for those, sorry, but I hope it gives you some idea on the problems I faced (and that you'll face) and how to solve then.
Once those are solved/worked around, you'll be able to run the "update" command and then, finally, you'll be able to expand guests/playbooks/build/projects/ in order to add openSUSE there and check whether we can successfully build the projects using openSUSE.
Thanks for all this info! I'll work on incorporating your comments as I have some time slices. It may take a few days.
Here I'm assuming your main goal is libvirt. Once that's done, I can do the work for libosinfo, osinfo-db-tools, and osinfo-db.
I assumed libvirt would be the harder one since it has a lot of build dependencies, so I started with it first. I'm guessing the other projects will be easy once the libvirt one is working. Regards, Jim
On Wed, Nov 20, 2019 at 12:11 AM Jim Fehlig <jfehlig@suse.com> wrote:
On 11/19/19 6:52 AM, Fabiano Fidêncio wrote:
On Tue, Nov 19, 2019 at 11:33 AM Andrea Bolognani <abologna@redhat.com> wrote:
On Tue, 2019-11-19 at 00:21 +0000, Jim Fehlig wrote:
Signed-off-by: Jim Fehlig <jfehlig@suse.com> --- guests/configs/autoinst.xml | 86 +++++++++++++++++++ .../libvirt-opensuse-15.1/docker.yml | 2 + .../libvirt-opensuse-15.1/install.yml | 2 + .../host_vars/libvirt-opensuse-15.1/main.yml | 22 +++++ guests/inventory | 1 + guests/lcitool | 2 + guests/vars/mappings.yml | 38 +++++++- 7 files changed, 151 insertions(+), 2 deletions(-)
First of all, thank you for following through with your promise of looking into this! I'm looking forward to being able to merge your changes and finally have proper openSUSE support in our CI :)
[...]
+++ b/guests/configs/autoinst.xml + <partitioning config:type="list"> + <drive> + <device>/dev/vda</device> + <use>all</use> + <partitions config:type="list"> + <partition> + <filesystem config:type="symbol">swap</filesystem> + <size>500M</size> + <mount>swap</mount>
We give other guests only 256 MiB of swap, so do the same here to be consistent. Building libvirt and friends is CPU-bound rather than memory-bound anyway, so more than that leeway is not necessary.
[...]
+ <add-on> + <add_on_products config:type="list"> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/oss/</media_url> + <name>repo-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/oss</media_url> + <name>repo-update</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/non-oss/</media_url> + <name>repo-non-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/non-oss/</media_url> + <name>repo-update-non-oss</name> + </listentry>
Do we actually need the non-OSS repositories to be updated? I would hope not! But I'm not familiar with how openSUSE organizes its repositories, so I'm going by name only :)
[...]
+ <firewall> + <enable_firewall>true</enable_firewall> + </firewall>
As you mention somewhere else, we probably don't need this.
[...]
+++ b/guests/host_vars/libvirt-opensuse-15.1/main.yml +package_format: 'rpm' +package_manager: 'zypper' +os_name: 'openSUSE' +os_version: '15.1'
So, about the naming.
What I would have done here is
os_name: 'OpenSUSE' os_version: '15'
The intial capital letter in os_name goes against the actual branding for openSUSE so I'm not perfectly happy with it, but on the other hand it's very useful when defining mappings because package formats all start with a lowercase letter and all OS names start with an uppercase letter. So I would try to stick with that convention.
As for os_version, if you look at all existing entries we use the major version number only: eg. we have CentOS7 instead of CentOS7.7 and FreeBSD12 instead of FreeBSD12.1: this makes sense because, as the guest gets updated over time, it will naturally pick up the latest minor release. Will this work for openSUSE too?
(Ubuntu is a slight exception in that the major version itself contains a dot, so we just shortened 18.04 to 18 because we know that there's never going to be two LTS releases per year.)
+++ b/guests/host_vars/libvirt-opensuse-15.1/docker.yml @@ -0,0 +1,2 @@ +--- +docker_base: openSUSE:15.1
I believe these images are now deprecated, and opensuse/leap should be used instead.
Looking at
https://hub.docker.com/r/opensuse/leap/tags
I see that the '15.1', '15' and 'latest' tags point to the same set of digests, so that seems to confirm that we can use just 15 as the version number and have
docker_base: opensuse/leap:15
in this file.
[...]
+++ b/guests/inventory @@ -8,5 +8,6 @@ libvirt-fedora-rawhide libvirt-freebsd-11 libvirt-freebsd-12 libvirt-freebsd-current +libvirt-opensuse-15.1
Based on the points above, I think this could and should be
libvirt-opensuse-15
[...]
@@ -127,6 +129,7 @@ mappings: dbus-daemon: default: dbus Fedora: dbus-daemon + openSUSE: dbus-1
You see how weird this looks, due to the first letter being lower case? :)
I'm not going to review the mappings in detail right now because I simply lack the time. Once 'lcitool update' works for you without errors, I'll look into it.
Fabiano already pointed out where you need to look to sort out the issues you've been experiencing, so I'll leave you to it now :)
Apart from what I pointed out, I've also faced a few issues when trying out your patch: - grub stays in a loop, forever; - I've worked this around by not setting "--graphics none --console pty" and removing "console=ttyS0" from the extra_arg line; - It really has to be solved in a better way ;-)
I've wasted way too much time trying to debug this problem. It definitely seems like an issue in our grub 2.02 package. I've reached out to the maintainer for help.
Aha! Yes, that's possible. I've tried to tweak the <append/> part of the general config in the autoyast, but also didn't make it work. :-/
- Update installed packages: - I've added: ``` +- name: Update installed packages + command: '{{ package_manager }} update -y' + args: + warn: no + when: + - os_name == 'openSUSE' ```
- Clean up packages after update: - I've added: ``` - 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" + +- name: Clean up packages after update + shell: '{{ package_manager }} clean -y' + args: + warn: no + when: + - os_name = "openSUSE" + ```
- Missing mappings: - qemu-img: - Seems that the package doesn't exist in openSUSE. So, please, just do something like:
It is included in the qemu-tools package.
``` qemu-img: default: qemu-utils rpm: qemu-img + openSUSE:
So this should be
OpenSUSE: qemu-tools
(using the uppercase 'O' as Andreas suggested :-)) ?
Yes!
``` - zfs: - Same as above - yajl: - It seems to be called libyajl-devel for openSUSE
- Look for files - There's a "Look for files" rule (in guests/playbooks/update/tasks/paths.yml) which will just bail out as /usr/local/etc doesn't exist in openSUSE. It has to be tweaked as well;
- Configure ccache: - This is a rule in guests/playbooks/update/tasks/users.yml, which takes into consideration that when the test user is created, we'll have a test group created as well, which doesn't happen on openSUSE. So, it also need some tweak;
I didn't write a patch for those, sorry, but I hope it gives you some idea on the problems I faced (and that you'll face) and how to solve then.
Once those are solved/worked around, you'll be able to run the "update" command and then, finally, you'll be able to expand guests/playbooks/build/projects/ in order to add openSUSE there and check whether we can successfully build the projects using openSUSE.
Thanks for all this info! I'll work on incorporating your comments as I have some time slices. It may take a few days.
No problem. Feel free to reach me out either here or on IRC in case you need some help / pair debugging / rubber duck session! :-)
Here I'm assuming your main goal is libvirt. Once that's done, I can do the work for libosinfo, osinfo-db-tools, and osinfo-db.
I assumed libvirt would be the harder one since it has a lot of build dependencies, so I started with it first. I'm guessing the other projects will be easy once the libvirt one is working.
For sure libvirt is the harder one. The other should be fairly easy to add, indeed. I just don't see a reason for you to spend time adding packages that you don't work directly with (although, I will *not* complain if you do so ;-)). Best Regards, -- Fabiano Fidêncio
On 11/19/19 6:52 AM, Fabiano Fidêncio wrote:
On Tue, Nov 19, 2019 at 11:33 AM Andrea Bolognani <abologna@redhat.com> wrote:
On Tue, 2019-11-19 at 00:21 +0000, Jim Fehlig wrote:
Signed-off-by: Jim Fehlig <jfehlig@suse.com> --- guests/configs/autoinst.xml | 86 +++++++++++++++++++ .../libvirt-opensuse-15.1/docker.yml | 2 + .../libvirt-opensuse-15.1/install.yml | 2 + .../host_vars/libvirt-opensuse-15.1/main.yml | 22 +++++ guests/inventory | 1 + guests/lcitool | 2 + guests/vars/mappings.yml | 38 +++++++- 7 files changed, 151 insertions(+), 2 deletions(-)
First of all, thank you for following through with your promise of looking into this! I'm looking forward to being able to merge your changes and finally have proper openSUSE support in our CI :)
[...]
+++ b/guests/configs/autoinst.xml + <partitioning config:type="list"> + <drive> + <device>/dev/vda</device> + <use>all</use> + <partitions config:type="list"> + <partition> + <filesystem config:type="symbol">swap</filesystem> + <size>500M</size> + <mount>swap</mount>
We give other guests only 256 MiB of swap, so do the same here to be consistent. Building libvirt and friends is CPU-bound rather than memory-bound anyway, so more than that leeway is not necessary.
[...]
+ <add-on> + <add_on_products config:type="list"> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/oss/</media_url> + <name>repo-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/oss</media_url> + <name>repo-update</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/non-oss/</media_url> + <name>repo-non-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/non-oss/</media_url> + <name>repo-update-non-oss</name> + </listentry>
Do we actually need the non-OSS repositories to be updated? I would hope not! But I'm not familiar with how openSUSE organizes its repositories, so I'm going by name only :)
[...]
+ <firewall> + <enable_firewall>true</enable_firewall> + </firewall>
As you mention somewhere else, we probably don't need this.
[...]
+++ b/guests/host_vars/libvirt-opensuse-15.1/main.yml +package_format: 'rpm' +package_manager: 'zypper' +os_name: 'openSUSE' +os_version: '15.1'
So, about the naming.
What I would have done here is
os_name: 'OpenSUSE' os_version: '15'
The intial capital letter in os_name goes against the actual branding for openSUSE so I'm not perfectly happy with it, but on the other hand it's very useful when defining mappings because package formats all start with a lowercase letter and all OS names start with an uppercase letter. So I would try to stick with that convention.
As for os_version, if you look at all existing entries we use the major version number only: eg. we have CentOS7 instead of CentOS7.7 and FreeBSD12 instead of FreeBSD12.1: this makes sense because, as the guest gets updated over time, it will naturally pick up the latest minor release. Will this work for openSUSE too?
(Ubuntu is a slight exception in that the major version itself contains a dot, so we just shortened 18.04 to 18 because we know that there's never going to be two LTS releases per year.)
+++ b/guests/host_vars/libvirt-opensuse-15.1/docker.yml @@ -0,0 +1,2 @@ +--- +docker_base: openSUSE:15.1
I believe these images are now deprecated, and opensuse/leap should be used instead.
Looking at
https://hub.docker.com/r/opensuse/leap/tags
I see that the '15.1', '15' and 'latest' tags point to the same set of digests, so that seems to confirm that we can use just 15 as the version number and have
docker_base: opensuse/leap:15
in this file.
[...]
+++ b/guests/inventory @@ -8,5 +8,6 @@ libvirt-fedora-rawhide libvirt-freebsd-11 libvirt-freebsd-12 libvirt-freebsd-current +libvirt-opensuse-15.1
Based on the points above, I think this could and should be
libvirt-opensuse-15
[...]
@@ -127,6 +129,7 @@ mappings: dbus-daemon: default: dbus Fedora: dbus-daemon + openSUSE: dbus-1
You see how weird this looks, due to the first letter being lower case? :)
I'm not going to review the mappings in detail right now because I simply lack the time. Once 'lcitool update' works for you without errors, I'll look into it.
Fabiano already pointed out where you need to look to sort out the issues you've been experiencing, so I'll leave you to it now :)
Apart from what I pointed out, I've also faced a few issues when trying out your patch: - grub stays in a loop, forever; - I've worked this around by not setting "--graphics none --console pty" and removing "console=ttyS0" from the extra_arg line; - It really has to be solved in a better way ;-)
I've fixed this in V2 [0] via grub configuration in the autoyast file. I've also updated the autoyast file to work with any current version of openSUSE.
- Update installed packages: - I've added: ``` +- name: Update installed packages + command: '{{ package_manager }} update -y' + args: + warn: no + when: + - os_name == 'openSUSE' ```
- Clean up packages after update: - I've added: ``` - 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" + +- name: Clean up packages after update + shell: '{{ package_manager }} clean -y' + args: + warn: no + when: + - os_name = "openSUSE" + ```
I've added these with minor tweaks.
- Missing mappings: - qemu-img: - Seems that the package doesn't exist in openSUSE. So, please, just do something like: ``` qemu-img: default: qemu-utils rpm: qemu-img + openSUSE: ``` - zfs: - Same as above - yajl: - It seems to be called libyajl-devel for openSUSE
Mappings are fixed.
- Look for files - There's a "Look for files" rule (in guests/playbooks/update/tasks/paths.yml) which will just bail out as /usr/local/etc doesn't exist in openSUSE. It has to be tweaked as well;
It is not clear to me what can be done in the yml file. How far can I bend the rules? :-) E.g. would something like the following work? shell: 'find /usr/local/etc -name {{ item }} 2>/dev/null || find /etc -name {{ item }} 2>/dev/null'
- Configure ccache: - This is a rule in guests/playbooks/update/tasks/users.yml, which takes into consideration that when the test user is created, we'll have a test group created as well, which doesn't happen on openSUSE. So, it also need some tweak;
I can add the test group via the autoyast file. Does the group require any specific properties? gid? System group? Regards, Jim [0] https://www.redhat.com/archives/libvir-list/2019-November/msg01240.html
On Tue, Nov 26, 2019 at 2:21 AM Jim Fehlig <jfehlig@suse.com> wrote:
On 11/19/19 6:52 AM, Fabiano Fidêncio wrote:
On Tue, Nov 19, 2019 at 11:33 AM Andrea Bolognani <abologna@redhat.com> wrote:
On Tue, 2019-11-19 at 00:21 +0000, Jim Fehlig wrote:
Signed-off-by: Jim Fehlig <jfehlig@suse.com> --- guests/configs/autoinst.xml | 86 +++++++++++++++++++ .../libvirt-opensuse-15.1/docker.yml | 2 + .../libvirt-opensuse-15.1/install.yml | 2 + .../host_vars/libvirt-opensuse-15.1/main.yml | 22 +++++ guests/inventory | 1 + guests/lcitool | 2 + guests/vars/mappings.yml | 38 +++++++- 7 files changed, 151 insertions(+), 2 deletions(-)
First of all, thank you for following through with your promise of looking into this! I'm looking forward to being able to merge your changes and finally have proper openSUSE support in our CI :)
[...]
+++ b/guests/configs/autoinst.xml + <partitioning config:type="list"> + <drive> + <device>/dev/vda</device> + <use>all</use> + <partitions config:type="list"> + <partition> + <filesystem config:type="symbol">swap</filesystem> + <size>500M</size> + <mount>swap</mount>
We give other guests only 256 MiB of swap, so do the same here to be consistent. Building libvirt and friends is CPU-bound rather than memory-bound anyway, so more than that leeway is not necessary.
[...]
+ <add-on> + <add_on_products config:type="list"> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/oss/</media_url> + <name>repo-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/oss</media_url> + <name>repo-update</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/non-oss/</media_url> + <name>repo-non-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/non-oss/</media_url> + <name>repo-update-non-oss</name> + </listentry>
Do we actually need the non-OSS repositories to be updated? I would hope not! But I'm not familiar with how openSUSE organizes its repositories, so I'm going by name only :)
[...]
+ <firewall> + <enable_firewall>true</enable_firewall> + </firewall>
As you mention somewhere else, we probably don't need this.
[...]
+++ b/guests/host_vars/libvirt-opensuse-15.1/main.yml +package_format: 'rpm' +package_manager: 'zypper' +os_name: 'openSUSE' +os_version: '15.1'
So, about the naming.
What I would have done here is
os_name: 'OpenSUSE' os_version: '15'
The intial capital letter in os_name goes against the actual branding for openSUSE so I'm not perfectly happy with it, but on the other hand it's very useful when defining mappings because package formats all start with a lowercase letter and all OS names start with an uppercase letter. So I would try to stick with that convention.
As for os_version, if you look at all existing entries we use the major version number only: eg. we have CentOS7 instead of CentOS7.7 and FreeBSD12 instead of FreeBSD12.1: this makes sense because, as the guest gets updated over time, it will naturally pick up the latest minor release. Will this work for openSUSE too?
(Ubuntu is a slight exception in that the major version itself contains a dot, so we just shortened 18.04 to 18 because we know that there's never going to be two LTS releases per year.)
+++ b/guests/host_vars/libvirt-opensuse-15.1/docker.yml @@ -0,0 +1,2 @@ +--- +docker_base: openSUSE:15.1
I believe these images are now deprecated, and opensuse/leap should be used instead.
Looking at
https://hub.docker.com/r/opensuse/leap/tags
I see that the '15.1', '15' and 'latest' tags point to the same set of digests, so that seems to confirm that we can use just 15 as the version number and have
docker_base: opensuse/leap:15
in this file.
[...]
+++ b/guests/inventory @@ -8,5 +8,6 @@ libvirt-fedora-rawhide libvirt-freebsd-11 libvirt-freebsd-12 libvirt-freebsd-current +libvirt-opensuse-15.1
Based on the points above, I think this could and should be
libvirt-opensuse-15
[...]
@@ -127,6 +129,7 @@ mappings: dbus-daemon: default: dbus Fedora: dbus-daemon + openSUSE: dbus-1
You see how weird this looks, due to the first letter being lower case? :)
I'm not going to review the mappings in detail right now because I simply lack the time. Once 'lcitool update' works for you without errors, I'll look into it.
Fabiano already pointed out where you need to look to sort out the issues you've been experiencing, so I'll leave you to it now :)
Apart from what I pointed out, I've also faced a few issues when trying out your patch: - grub stays in a loop, forever; - I've worked this around by not setting "--graphics none --console pty" and removing "console=ttyS0" from the extra_arg line; - It really has to be solved in a better way ;-)
I've fixed this in V2 [0] via grub configuration in the autoyast file. I've also updated the autoyast file to work with any current version of openSUSE.
Cool. I'll give it a try later Today!
- Update installed packages: - I've added: ``` +- name: Update installed packages + command: '{{ package_manager }} update -y' + args: + warn: no + when: + - os_name == 'openSUSE' ```
- Clean up packages after update: - I've added: ``` - 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" + +- name: Clean up packages after update + shell: '{{ package_manager }} clean -y' + args: + warn: no + when: + - os_name = "openSUSE" + ```
I've added these with minor tweaks.
- Missing mappings: - qemu-img: - Seems that the package doesn't exist in openSUSE. So, please, just do something like: ``` qemu-img: default: qemu-utils rpm: qemu-img + openSUSE: ``` - zfs: - Same as above - yajl: - It seems to be called libyajl-devel for openSUSE
Mappings are fixed.
- Look for files - There's a "Look for files" rule (in guests/playbooks/update/tasks/paths.yml) which will just bail out as /usr/local/etc doesn't exist in openSUSE. It has to be tweaked as well;
It is not clear to me what can be done in the yml file. How far can I bend the rules? :-) E.g. would something like the following work?
shell: 'find /usr/local/etc -name {{ item }} 2>/dev/null || find /etc -name {{ item }} 2>/dev/null'
I do believe that's the way to go.
- Configure ccache: - This is a rule in guests/playbooks/update/tasks/users.yml, which takes into consideration that when the test user is created, we'll have a test group created as well, which doesn't happen on openSUSE. So, it also need some tweak;
I can add the test group via the autoyast file. Does the group require any specific properties? gid? System group?
AFAIU we just need the group to be there. So, no, no specific properties.
Regards, Jim
[0] https://www.redhat.com/archives/libvir-list/2019-November/msg01240.html
On Tue, 2019-11-26 at 08:17 +0100, Fabiano Fidêncio wrote:
On Tue, Nov 26, 2019 at 2:21 AM Jim Fehlig <jfehlig@suse.com> wrote:
On 11/19/19 6:52 AM, Fabiano Fidêncio wrote:
- Look for files - There's a "Look for files" rule (in guests/playbooks/update/tasks/paths.yml) which will just bail out as /usr/local/etc doesn't exist in openSUSE. It has to be tweaked as well;
It is not clear to me what can be done in the yml file. How far can I bend the rules? :-) E.g. would something like the following work?
shell: 'find /usr/local/etc -name {{ item }} 2>/dev/null || find /etc -name {{ item }} 2>/dev/null'
I do believe that's the way to go.
Actually the way we currently call to find is kinda yucky (I can say that because I've introduced it :) and I'd much rather we handled sudoers the same way we handle grub.cfg[0], that is, using Ansible's native facilities instead of embedded shell scripting.
- Configure ccache: - This is a rule in guests/playbooks/update/tasks/users.yml, which takes into consideration that when the test user is created, we'll have a test group created as well, which doesn't happen on openSUSE. So, it also need some tweak;
I can add the test group via the autoyast file. Does the group require any specific properties? gid? System group?
AFAIU we just need the group to be there. So, no, no specific properties.
Just create the group using the appropriate Ansible module[1] before creating the user that's supposed to be in it. You should make sure doing so doesn't cause any regression for other operating systems, but I don't see why it would. [0] playbooks/update/tasks/bootloader.yml [1] https://docs.ansible.com/ansible/latest/modules/group_module.html -- Andrea Bolognani / Red Hat / Virtualization
On 11/19/19 3:32 AM, Andrea Bolognani wrote:
On Tue, 2019-11-19 at 00:21 +0000, Jim Fehlig wrote:
Signed-off-by: Jim Fehlig <jfehlig@suse.com> --- guests/configs/autoinst.xml | 86 +++++++++++++++++++ .../libvirt-opensuse-15.1/docker.yml | 2 + .../libvirt-opensuse-15.1/install.yml | 2 + .../host_vars/libvirt-opensuse-15.1/main.yml | 22 +++++ guests/inventory | 1 + guests/lcitool | 2 + guests/vars/mappings.yml | 38 +++++++- 7 files changed, 151 insertions(+), 2 deletions(-)
First of all, thank you for following through with your promise of looking into this! I'm looking forward to being able to merge your changes and finally have proper openSUSE support in our CI :)
Thanks for the help!
[...]
+++ b/guests/configs/autoinst.xml + <partitioning config:type="list"> + <drive> + <device>/dev/vda</device> + <use>all</use> + <partitions config:type="list"> + <partition> + <filesystem config:type="symbol">swap</filesystem> + <size>500M</size> + <mount>swap</mount>
We give other guests only 256 MiB of swap, so do the same here to be consistent. Building libvirt and friends is CPU-bound rather than memory-bound anyway, so more than that leeway is not necessary.
[...]
+ <add-on> + <add_on_products config:type="list"> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/oss/</media_url> + <name>repo-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/oss</media_url> + <name>repo-update</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/non-oss/</media_url> + <name>repo-non-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/non-oss/</media_url> + <name>repo-update-non-oss</name> + </listentry>
Do we actually need the non-OSS repositories to be updated? I would hope not! But I'm not familiar with how openSUSE organizes its repositories, so I'm going by name only :)
Probably not needed. I'll try to trim this after working through other issues.
[...]
+ <firewall> + <enable_firewall>true</enable_firewall> + </firewall>
As you mention somewhere else, we probably don't need this.
[...]
+++ b/guests/host_vars/libvirt-opensuse-15.1/main.yml +package_format: 'rpm' +package_manager: 'zypper' +os_name: 'openSUSE' +os_version: '15.1'
So, about the naming.
What I would have done here is
os_name: 'OpenSUSE' os_version: '15'
The intial capital letter in os_name goes against the actual branding for openSUSE so I'm not perfectly happy with it, but on the other hand it's very useful when defining mappings because package formats all start with a lowercase letter and all OS names start with an uppercase letter. So I would try to stick with that convention.
Ok, no problem.
As for os_version, if you look at all existing entries we use the major version number only: eg. we have CentOS7 instead of CentOS7.7 and FreeBSD12 instead of FreeBSD12.1: this makes sense because, as the guest gets updated over time, it will naturally pick up the latest minor release. Will this work for openSUSE too?
I suppose so. Although for example Leap 15.2 will have a different kernel (5.3. vs 4.12), different install path (http://download.opensuse.org/distribution/leap/15.2/repo/oss/), etc. Is that okay?
(Ubuntu is a slight exception in that the major version itself contains a dot, so we just shortened 18.04 to 18 because we know that there's never going to be two LTS releases per year.)
+++ b/guests/host_vars/libvirt-opensuse-15.1/docker.yml @@ -0,0 +1,2 @@ +--- +docker_base: openSUSE:15.1
I believe these images are now deprecated, and opensuse/leap should be used instead.
Looking at
https://hub.docker.com/r/opensuse/leap/tags
I see that the '15.1', '15' and 'latest' tags point to the same set of digests, so that seems to confirm that we can use just 15 as the version number and have
docker_base: opensuse/leap:15
in this file.
Sorry, I didn't even look at this. I simply put something in there with a mental note to check on it later. Thanks for checking on it sooner :-).
[...]
+++ b/guests/inventory @@ -8,5 +8,6 @@ libvirt-fedora-rawhide libvirt-freebsd-11 libvirt-freebsd-12 libvirt-freebsd-current +libvirt-opensuse-15.1
Based on the points above, I think this could and should be
libvirt-opensuse-15
[...]
@@ -127,6 +129,7 @@ mappings: dbus-daemon: default: dbus Fedora: dbus-daemon + openSUSE: dbus-1
You see how weird this looks, due to the first letter being lower case? :)
I'm not going to review the mappings in detail right now because I simply lack the time. Once 'lcitool update' works for you without errors, I'll look into it.
Sounds good.
Fabiano already pointed out where you need to look to sort out the issues you've been experiencing, so I'll leave you to it now :)
Thanks to you both! Regards, Jim
On Wed, Nov 20, 2019 at 12:01 AM Jim Fehlig <jfehlig@suse.com> wrote:
On 11/19/19 3:32 AM, Andrea Bolognani wrote:
On Tue, 2019-11-19 at 00:21 +0000, Jim Fehlig wrote:
Signed-off-by: Jim Fehlig <jfehlig@suse.com> --- guests/configs/autoinst.xml | 86 +++++++++++++++++++ .../libvirt-opensuse-15.1/docker.yml | 2 + .../libvirt-opensuse-15.1/install.yml | 2 + .../host_vars/libvirt-opensuse-15.1/main.yml | 22 +++++ guests/inventory | 1 + guests/lcitool | 2 + guests/vars/mappings.yml | 38 +++++++- 7 files changed, 151 insertions(+), 2 deletions(-)
First of all, thank you for following through with your promise of looking into this! I'm looking forward to being able to merge your changes and finally have proper openSUSE support in our CI :)
Thanks for the help!
[...]
+++ b/guests/configs/autoinst.xml + <partitioning config:type="list"> + <drive> + <device>/dev/vda</device> + <use>all</use> + <partitions config:type="list"> + <partition> + <filesystem config:type="symbol">swap</filesystem> + <size>500M</size> + <mount>swap</mount>
We give other guests only 256 MiB of swap, so do the same here to be consistent. Building libvirt and friends is CPU-bound rather than memory-bound anyway, so more than that leeway is not necessary.
[...]
+ <add-on> + <add_on_products config:type="list"> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/oss/</media_url> + <name>repo-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/oss</media_url> + <name>repo-update</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/distribution/leap/15.1/repo/non-oss/</media_url> + <name>repo-non-oss</name> + </listentry> + <listentry> + <media_url>http://download.opensuse.org/update/leap/15.1/non-oss/</media_url> + <name>repo-update-non-oss</name> + </listentry>
Do we actually need the non-OSS repositories to be updated? I would hope not! But I'm not familiar with how openSUSE organizes its repositories, so I'm going by name only :)
Probably not needed. I'll try to trim this after working through other issues.
[...]
+ <firewall> + <enable_firewall>true</enable_firewall> + </firewall>
As you mention somewhere else, we probably don't need this.
[...]
+++ b/guests/host_vars/libvirt-opensuse-15.1/main.yml +package_format: 'rpm' +package_manager: 'zypper' +os_name: 'openSUSE' +os_version: '15.1'
So, about the naming.
What I would have done here is
os_name: 'OpenSUSE' os_version: '15'
The intial capital letter in os_name goes against the actual branding for openSUSE so I'm not perfectly happy with it, but on the other hand it's very useful when defining mappings because package formats all start with a lowercase letter and all OS names start with an uppercase letter. So I would try to stick with that convention.
Ok, no problem.
As for os_version, if you look at all existing entries we use the major version number only: eg. we have CentOS7 instead of CentOS7.7 and FreeBSD12 instead of FreeBSD12.1: this makes sense because, as the guest gets updated over time, it will naturally pick up the latest minor release. Will this work for openSUSE too?
I suppose so. Although for example Leap 15.2 will have a different kernel (5.3. vs 4.12), different install path (http://download.opensuse.org/distribution/leap/15.2/repo/oss/), etc. Is that okay?
It depends a lot on what's the OpenSUSE policy of its distro. Once 15.2 is out, what happens to 15.1? Is this just a "minor" update? Will 15.1 still be supported or are people expected to just update / upgrade to 15.2?
(Ubuntu is a slight exception in that the major version itself contains a dot, so we just shortened 18.04 to 18 because we know that there's never going to be two LTS releases per year.)
+++ b/guests/host_vars/libvirt-opensuse-15.1/docker.yml @@ -0,0 +1,2 @@ +--- +docker_base: openSUSE:15.1
I believe these images are now deprecated, and opensuse/leap should be used instead.
Looking at
https://hub.docker.com/r/opensuse/leap/tags
I see that the '15.1', '15' and 'latest' tags point to the same set of digests, so that seems to confirm that we can use just 15 as the version number and have
docker_base: opensuse/leap:15
in this file.
Sorry, I didn't even look at this. I simply put something in there with a mental note to check on it later. Thanks for checking on it sooner :-).
[...]
+++ b/guests/inventory @@ -8,5 +8,6 @@ libvirt-fedora-rawhide libvirt-freebsd-11 libvirt-freebsd-12 libvirt-freebsd-current +libvirt-opensuse-15.1
Based on the points above, I think this could and should be
libvirt-opensuse-15
[...]
@@ -127,6 +129,7 @@ mappings: dbus-daemon: default: dbus Fedora: dbus-daemon + openSUSE: dbus-1
You see how weird this looks, due to the first letter being lower case? :)
I'm not going to review the mappings in detail right now because I simply lack the time. Once 'lcitool update' works for you without errors, I'll look into it.
Sounds good.
Fabiano already pointed out where you need to look to sort out the issues you've been experiencing, so I'll leave you to it now :)
Thanks to you both!
Regards, Jim
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, 2019-11-20 at 07:56 +0100, Fabiano Fidêncio wrote:
On Wed, Nov 20, 2019 at 12:01 AM Jim Fehlig <jfehlig@suse.com> wrote:
On 11/19/19 3:32 AM, Andrea Bolognani wrote:
As for os_version, if you look at all existing entries we use the major version number only: eg. we have CentOS7 instead of CentOS7.7 and FreeBSD12 instead of FreeBSD12.1: this makes sense because, as the guest gets updated over time, it will naturally pick up the latest minor release. Will this work for openSUSE too?
I suppose so. Although for example Leap 15.2 will have a different kernel (5.3. vs 4.12), different install path (http://download.opensuse.org/distribution/leap/15.2/repo/oss/), etc. Is that okay?
It depends a lot on what's the OpenSUSE policy of its distro. Once 15.2 is out, what happens to 15.1? Is this just a "minor" update? Will 15.1 still be supported or are people expected to just update / upgrade to 15.2?
Yeah, the changing kernel is not much of an issue (Fedora rawhide, Debian sid and FreeBSD -CURRENT certainly fits into that category as well :), it's more a question of whether, as Fabiano said, eg. 15.1 and 15.2 are considered two separate branches where each of them continues to get significant development over time, or if (as is the case for RHEL minor releases) once eg. 7.8 is out, people are mostly expected to move off 7.7. In the latter case, I would expect the transition to be mostly smooth: running the daily update procedure on a 15.1 machine after 15.2 has been released would advance the OS to 15.2. That's not necessarily a hard requirement either, however: for example, FreeBSD doesn't work like that and requires an explicit upgrade step instead. -- Andrea Bolognani / Red Hat / Virtualization
On 11/20/19 1:03 AM, Andrea Bolognani wrote:
On Wed, 2019-11-20 at 07:56 +0100, Fabiano Fidêncio wrote:
On Wed, Nov 20, 2019 at 12:01 AM Jim Fehlig <jfehlig@suse.com> wrote:
On 11/19/19 3:32 AM, Andrea Bolognani wrote:
As for os_version, if you look at all existing entries we use the major version number only: eg. we have CentOS7 instead of CentOS7.7 and FreeBSD12 instead of FreeBSD12.1: this makes sense because, as the guest gets updated over time, it will naturally pick up the latest minor release. Will this work for openSUSE too?
I suppose so. Although for example Leap 15.2 will have a different kernel (5.3. vs 4.12), different install path (http://download.opensuse.org/distribution/leap/15.2/repo/oss/), etc. Is that okay?
It depends a lot on what's the OpenSUSE policy of its distro. Once 15.2 is out, what happens to 15.1? Is this just a "minor" update? Will 15.1 still be supported or are people expected to just update / upgrade to 15.2?
Yeah, the changing kernel is not much of an issue (Fedora rawhide, Debian sid and FreeBSD -CURRENT certainly fits into that category as well :), it's more a question of whether, as Fabiano said, eg. 15.1 and 15.2 are considered two separate branches where each of them continues to get significant development over time, or if (as is the case for RHEL minor releases) once eg. 7.8 is out, people are mostly expected to move off 7.7.
In the latter case, I would expect the transition to be mostly smooth: running the daily update procedure on a 15.1 machine after 15.2 has been released would advance the OS to 15.2. That's not necessarily a hard requirement either, however: for example, FreeBSD doesn't work like that and requires an explicit upgrade step instead.
It sounds like Tumbleweed fits into the later case, whereas Leap is more like FreeBSD. E.g. upgrading from 15.1 to 15.2 requires changing the configured repos (http://download.opensuse.org/distribution/leap/15.2/repo/oss/) and running 'zypper dist-upgrade'. Regards, Jim
On 11/19/19 11:56 PM, Fabiano Fidêncio wrote:
On Wed, Nov 20, 2019 at 12:01 AM Jim Fehlig <jfehlig@suse.com> wrote:
On 11/19/19 3:32 AM, Andrea Bolognani wrote:
On Tue, 2019-11-19 at 00:21 +0000, Jim Fehlig wrote:
[...]
+++ b/guests/host_vars/libvirt-opensuse-15.1/main.yml +package_format: 'rpm' +package_manager: 'zypper' +os_name: 'openSUSE' +os_version: '15.1'
So, about the naming.
What I would have done here is
os_name: 'OpenSUSE' os_version: '15'
The intial capital letter in os_name goes against the actual branding for openSUSE so I'm not perfectly happy with it, but on the other hand it's very useful when defining mappings because package formats all start with a lowercase letter and all OS names start with an uppercase letter. So I would try to stick with that convention.
Ok, no problem.
As for os_version, if you look at all existing entries we use the major version number only: eg. we have CentOS7 instead of CentOS7.7 and FreeBSD12 instead of FreeBSD12.1: this makes sense because, as the guest gets updated over time, it will naturally pick up the latest minor release. Will this work for openSUSE too?
I suppose so. Although for example Leap 15.2 will have a different kernel (5.3. vs 4.12), different install path (http://download.opensuse.org/distribution/leap/15.2/repo/oss/), etc. Is that okay?
It depends a lot on what's the OpenSUSE policy of its distro. Once 15.2 is out, what happens to 15.1? Is this just a "minor" update? Will 15.1 still be supported or are people expected to just update / upgrade to 15.2?
15.1 will continue to be actively supported alongside 15.2 for six months after the release of 15.2. The lifecycle is described here https://en.opensuse.org/Lifetime Perhaps it is best to just support the latest Leap release plus openSUSE Tumbleweed? I.e. I send a patch to replace the 15.1 machine with 15.2 once it is released. Regards, Jim
On Wed, Nov 20, 2019 at 8:44 PM Jim Fehlig <jfehlig@suse.com> wrote:
On 11/19/19 11:56 PM, Fabiano Fidêncio wrote:
On Wed, Nov 20, 2019 at 12:01 AM Jim Fehlig <jfehlig@suse.com> wrote:
On 11/19/19 3:32 AM, Andrea Bolognani wrote:
On Tue, 2019-11-19 at 00:21 +0000, Jim Fehlig wrote:
[...]
+++ b/guests/host_vars/libvirt-opensuse-15.1/main.yml +package_format: 'rpm' +package_manager: 'zypper' +os_name: 'openSUSE' +os_version: '15.1'
So, about the naming.
What I would have done here is
os_name: 'OpenSUSE' os_version: '15'
The intial capital letter in os_name goes against the actual branding for openSUSE so I'm not perfectly happy with it, but on the other hand it's very useful when defining mappings because package formats all start with a lowercase letter and all OS names start with an uppercase letter. So I would try to stick with that convention.
Ok, no problem.
As for os_version, if you look at all existing entries we use the major version number only: eg. we have CentOS7 instead of CentOS7.7 and FreeBSD12 instead of FreeBSD12.1: this makes sense because, as the guest gets updated over time, it will naturally pick up the latest minor release. Will this work for openSUSE too?
I suppose so. Although for example Leap 15.2 will have a different kernel (5.3. vs 4.12), different install path (http://download.opensuse.org/distribution/leap/15.2/repo/oss/), etc. Is that okay?
It depends a lot on what's the OpenSUSE policy of its distro. Once 15.2 is out, what happens to 15.1? Is this just a "minor" update? Will 15.1 still be supported or are people expected to just update / upgrade to 15.2?
15.1 will continue to be actively supported alongside 15.2 for six months after the release of 15.2. The lifecycle is described here
https://en.opensuse.org/Lifetime
Perhaps it is best to just support the latest Leap release plus openSUSE Tumbleweed? I.e. I send a patch to replace the 15.1 machine with 15.2 once it is released.
I'd adopt the same policy we have for other distros. Support the last two releases (as in, Fedora 30 and Fedora 31). Leap seems to fit in the "Fedora" case. Thus, I'd keep 15.1, 15.2, 15.3, ... Together with that, I really would like to have Tumbleweed supported as well. Best Regards, -- Fabiano Fidêncio
On 11/20/19 2:16 PM, Fabiano Fidêncio wrote:
On Wed, Nov 20, 2019 at 8:44 PM Jim Fehlig <jfehlig@suse.com> wrote:
On 11/19/19 11:56 PM, Fabiano Fidêncio wrote:
On Wed, Nov 20, 2019 at 12:01 AM Jim Fehlig <jfehlig@suse.com> wrote:
On 11/19/19 3:32 AM, Andrea Bolognani wrote:
On Tue, 2019-11-19 at 00:21 +0000, Jim Fehlig wrote:
[...]
+++ b/guests/host_vars/libvirt-opensuse-15.1/main.yml +package_format: 'rpm' +package_manager: 'zypper' +os_name: 'openSUSE' +os_version: '15.1'
So, about the naming.
What I would have done here is
os_name: 'OpenSUSE' os_version: '15'
The intial capital letter in os_name goes against the actual branding for openSUSE so I'm not perfectly happy with it, but on the other hand it's very useful when defining mappings because package formats all start with a lowercase letter and all OS names start with an uppercase letter. So I would try to stick with that convention.
Ok, no problem.
As for os_version, if you look at all existing entries we use the major version number only: eg. we have CentOS7 instead of CentOS7.7 and FreeBSD12 instead of FreeBSD12.1: this makes sense because, as the guest gets updated over time, it will naturally pick up the latest minor release. Will this work for openSUSE too?
I suppose so. Although for example Leap 15.2 will have a different kernel (5.3. vs 4.12), different install path (http://download.opensuse.org/distribution/leap/15.2/repo/oss/), etc. Is that okay?
It depends a lot on what's the OpenSUSE policy of its distro. Once 15.2 is out, what happens to 15.1? Is this just a "minor" update? Will 15.1 still be supported or are people expected to just update / upgrade to 15.2?
15.1 will continue to be actively supported alongside 15.2 for six months after the release of 15.2. The lifecycle is described here
https://en.opensuse.org/Lifetime
Perhaps it is best to just support the latest Leap release plus openSUSE Tumbleweed? I.e. I send a patch to replace the 15.1 machine with 15.2 once it is released.
I'd adopt the same policy we have for other distros. Support the last two releases (as in, Fedora 30 and Fedora 31).
Leap seems to fit in the "Fedora" case. Thus, I'd keep 15.1, 15.2, 15.3, ...
But how to name those? Is a '.' in the name problematic? Should inventory have libvirt-opensuse-15.1, libvirt-opensuse-15.2, etc?
Together with that, I really would like to have Tumbleweed supported as well.
Nod. That one is easy to name: libvirt-opensuse-tw :-). Regards, Jim
On Wed, Nov 20, 2019 at 10:46 PM Jim Fehlig <jfehlig@suse.com> wrote:
On 11/20/19 2:16 PM, Fabiano Fidêncio wrote:
On Wed, Nov 20, 2019 at 8:44 PM Jim Fehlig <jfehlig@suse.com> wrote:
On 11/19/19 11:56 PM, Fabiano Fidêncio wrote:
On Wed, Nov 20, 2019 at 12:01 AM Jim Fehlig <jfehlig@suse.com> wrote:
On 11/19/19 3:32 AM, Andrea Bolognani wrote:
On Tue, 2019-11-19 at 00:21 +0000, Jim Fehlig wrote:
[...]
> +++ b/guests/host_vars/libvirt-opensuse-15.1/main.yml > +package_format: 'rpm' > +package_manager: 'zypper' > +os_name: 'openSUSE' > +os_version: '15.1'
So, about the naming.
What I would have done here is
os_name: 'OpenSUSE' os_version: '15'
The intial capital letter in os_name goes against the actual branding for openSUSE so I'm not perfectly happy with it, but on the other hand it's very useful when defining mappings because package formats all start with a lowercase letter and all OS names start with an uppercase letter. So I would try to stick with that convention.
Ok, no problem.
As for os_version, if you look at all existing entries we use the major version number only: eg. we have CentOS7 instead of CentOS7.7 and FreeBSD12 instead of FreeBSD12.1: this makes sense because, as the guest gets updated over time, it will naturally pick up the latest minor release. Will this work for openSUSE too?
I suppose so. Although for example Leap 15.2 will have a different kernel (5.3. vs 4.12), different install path (http://download.opensuse.org/distribution/leap/15.2/repo/oss/), etc. Is that okay?
It depends a lot on what's the OpenSUSE policy of its distro. Once 15.2 is out, what happens to 15.1? Is this just a "minor" update? Will 15.1 still be supported or are people expected to just update / upgrade to 15.2?
15.1 will continue to be actively supported alongside 15.2 for six months after the release of 15.2. The lifecycle is described here
https://en.opensuse.org/Lifetime
Perhaps it is best to just support the latest Leap release plus openSUSE Tumbleweed? I.e. I send a patch to replace the 15.1 machine with 15.2 once it is released.
I'd adopt the same policy we have for other distros. Support the last two releases (as in, Fedora 30 and Fedora 31).
Leap seems to fit in the "Fedora" case. Thus, I'd keep 15.1, 15.2, 15.3, ...
But how to name those? Is a '.' in the name problematic? Should inventory have libvirt-opensuse-15.1, libvirt-opensuse-15.2, etc?
Now, knowing the release and life cycles, I'd suggest to keep it as: libvirt-opensuse-15.1, libvirt-opensuse-15.2, and so on ... exactly as you did in the patch you submitted.
Together with that, I really would like to have Tumbleweed supported as well.
Nod. That one is easy to name: libvirt-opensuse-tw :-).
Regards, Jim
On Wed, 2019-11-20 at 23:19 +0100, Fabiano Fidêncio wrote:
On Wed, Nov 20, 2019 at 10:46 PM Jim Fehlig <jfehlig@suse.com> wrote:
On 11/20/19 2:16 PM, Fabiano Fidêncio wrote:
On Wed, Nov 20, 2019 at 8:44 PM Jim Fehlig <jfehlig@suse.com> wrote:
15.1 will continue to be actively supported alongside 15.2 for six months after the release of 15.2. The lifecycle is described here
https://en.opensuse.org/Lifetime
Perhaps it is best to just support the latest Leap release plus openSUSE Tumbleweed? I.e. I send a patch to replace the 15.1 machine with 15.2 once it is released.
I'd adopt the same policy we have for other distros. Support the last two releases (as in, Fedora 30 and Fedora 31).
Unless it makes more sense to support the latest 42.x and the latest 15.x instead? But it looks like the former has been discontinued now, so perhaps just the latest 15.x and then, once that's released, the latest 16.x (guessing the version number :) in addition to that?
Leap seems to fit in the "Fedora" case. Thus, I'd keep 15.1, 15.2, 15.3, ...
But how to name those? Is a '.' in the name problematic? Should inventory have libvirt-opensuse-15.1, libvirt-opensuse-15.2, etc?
Now, knowing the release and life cycles, I'd suggest to keep it as: libvirt-opensuse-15.1, libvirt-opensuse-15.2, and so on ... exactly as you did in the patch you submitted.
Agreed. Incidentally, once we start introducing x.y version numbers it would make sense to rename Ubuntu guests so that they look like libvirt-ubuntu-18.04 and so on.
Together with that, I really would like to have Tumbleweed supported as well.
Nod. That one is easy to name: libvirt-opensuse-tw :-).
Please just call it libvirt-opensuse-tumbleweed instead: no need to use shorthands. -- Andrea Bolognani / Red Hat / Virtualization
participants (3)
-
Andrea Bolognani -
Fabiano Fidêncio -
Jim Fehlig