action #43970
closedo3 webui update on 2018-11-19
0%
Description
Today around 9AM, I did an update of the host openqa.opensuse.org together with @okurz.
This ticket is to track changes we did.
To better reflect our needed packages we changed the repo priority of devel_openQA as well as devel_openQA_Leap_42.3. This should enable us to always pull the latest packages relevant to openQA from the appropriate repo. Here's a dump of the new state on o3:
ariel:~ # zypper lr --details
Repository priorities in effect: (See 'zypper lr -P' for details)
95 (raised priority) : 2 repositories
99 (default priority) : 2 repositories
100 (lowered priority) : 1 repository
# | Alias | Name | Enabled | GPG Check | Refresh | Priority | Type | URI | Service
--+-------------------------+----------------------------------------------------+---------+-----------+---------+----------+--------+-----------------------------------------------------------------------------------------+--------
1 | SUSE:CA | SUSE:CA | No | ---- | ---- | 99 | rpm-md | http://smt-internal.suse-dmz.opensuse.org/int-suse-ca/openSUSE_Leap_42.3 |
2 | devel_openQA | Providing openQA dependencies (openSUSE_Leap_42.3) | Yes | (r ) Yes | Yes | 95 | rpm-md | http://download.opensuse.org/repositories/devel:/openQA/openSUSE_Leap_42.3/ |
3 | devel_openQA_Leap_42.3 | devel:openQA:Leap:42.3 (openSUSE_Leap_42.3) | Yes | (r ) Yes | Yes | 95 | rpm-md | http://download.opensuse.org/repositories/devel:/openQA:/Leap:/42.3/openSUSE_Leap_42.3/ |
4 | openSUSE:infrastructure | openSUSE:infrastructure | Yes | (r ) Yes | Yes | 100 | rpm-md | http://download.opensuse.org/repositories/openSUSE:/infrastructure/openSUSE_Leap_42.3 |
5 | repo-oss | repo-oss | Yes | (r ) Yes | No | 99 | yast2 | http://download.opensuse.org/distribution/leap/42.3/repo/oss |
6 | repo-update-oss | repo-update-oss | Yes | (r ) Yes | Yes | 99 | rpm-md | http://download.opensuse.org/update/leap/42.3/oss |
We updated the kernel with zypper patch and all other packages like this:
ariel:~ # zypper dup --details
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Loading repository data...
Reading installed packages...
Computing distribution upgrade...
The following 4 NEW packages are going to be installed:
perl-Minion-Backend-SQLite 4.002-2.1 noarch devel:openQA:Leap:42.3 (openSUSE_Leap_42.3) obs://build.opensuse.org/devel:openQA
perl-Mojo-SQLite 3.001-2.1 noarch devel:openQA:Leap:42.3 (openSUSE_Leap_42.3) obs://build.opensuse.org/devel:openQA
perl-URI-Nested 0.10-1.2 noarch repo-oss openSUSE
perl-URI-db 0.17-1.1 noarch repo-oss openSUSE
The following 13 packages are going to be upgraded:
monitoring-plugins-zypper
1.92-3.1 -> 1.95-8.1 noarch repo-update-oss obs://build.opensuse.org/openSUSE -> openSUSE
openQA
4.6.1536608808.787537fe-775.1 -> 4.6.1542530127.60004e2a-889.1 noarch Providing openQA dependencies (openSUSE_Leap_42.3) obs://build.opensuse.org/devel:openQA
openQA-client
4.6.1536608808.787537fe-775.1 -> 4.6.1542530127.60004e2a-889.1 noarch Providing openQA dependencies (openSUSE_Leap_42.3) obs://build.opensuse.org/devel:openQA
openQA-common
4.6.1536608808.787537fe-775.1 -> 4.6.1542530127.60004e2a-889.1 noarch Providing openQA dependencies (openSUSE_Leap_42.3) obs://build.opensuse.org/devel:openQA
perl-Cpanel-JSON-XS
4.06-2.1 -> 4.07-2.1 x86_64 devel:openQA:Leap:42.3 (openSUSE_Leap_42.3) obs://build.opensuse.org/devel:openQA
perl-DBD-SQLite
1.50-3.11 -> 1.58-48.6 x86_64 devel:openQA:Leap:42.3 (openSUSE_Leap_42.3) openSUSE -> obs://build.opensuse.org/devel:openQA
perl-IO-Socket-SSL
2.059-2.1 -> 2.060-3.1 noarch devel:openQA:Leap:42.3 (openSUSE_Leap_42.3) obs://build.opensuse.org/devel:openQA
perl-Minion
9.03-2.1 -> 9.07-2.1 noarch devel:openQA:Leap:42.3 (openSUSE_Leap_42.3) obs://build.opensuse.org/devel:openQA
perl-Mojo-Pg
4.09-2.1 -> 4.11-3.1 noarch devel:openQA:Leap:42.3 (openSUSE_Leap_42.3) obs://build.opensuse.org/devel:openQA
perl-Mojolicious
7.93-2.1 -> 8.06-4.1 noarch devel:openQA:Leap:42.3 (openSUSE_Leap_42.3) obs://build.opensuse.org/devel:openQA
perl-Mojolicious-Plugin-AssetPack
2.05-2.1 -> 2.06-2.1 noarch devel:openQA:Leap:42.3 (openSUSE_Leap_42.3) obs://build.opensuse.org/devel:openQA
perl-Perl-Tidy
20160302-3.1 -> 20180220-2.8 noarch devel:openQA:Leap:42.3 (openSUSE_Leap_42.3) openSUSE -> obs://build.opensuse.org/devel:openQA
perl-URI
1.60-12.3 -> 1.74-51.1 noarch devel:openQA:Leap:42.3 (openSUSE_Leap_42.3) openSUSE -> obs://build.opensuse.org/devel:openQA
The following package is going to be reinstalled:
perl-Mojo-RabbitMQ-Client 0.2.1-2.1 noarch devel:openQA:Leap:42.3 (openSUSE_Leap_42.3) obs://build.opensuse.org/devel:openQA
The following 4 packages are going to change vendor:
monitoring-plugins-zypper 1.92-3.1 -> 1.95-8.1 noarch repo-update-oss obs://build.opensuse.org/openSUSE -> openSUSE
perl-DBD-SQLite 1.50-3.11 -> 1.58-48.6 x86_64 devel:openQA:Leap:42.3 (openSUSE_Leap_42.3) openSUSE -> obs://build.opensuse.org/devel:openQA
perl-Perl-Tidy 20160302-3.1 -> 20180220-2.8 noarch devel:openQA:Leap:42.3 (openSUSE_Leap_42.3) openSUSE -> obs://build.opensuse.org/devel:openQA
perl-URI 1.60-12.3 -> 1.74-51.1 noarch devel:openQA:Leap:42.3 (openSUSE_Leap_42.3) openSUSE -> obs://build.opensuse.org/devel:openQA
13 packages to upgrade, 4 new, 1 to reinstall, 4 to change vendor.
Overall download size: 7.6 MiB. Already cached: 0 B. After the operation, additional 5.9 MiB will be used.
Continue? [y/n/...? shows all options] (y):
Afterwards the service apache2 and openqa-webui got restarted.
The updated web-ui looks fine and functional (jobs scheduled, jobs picked up, worker connected). The openqa-jounal did not show significant new errors.
@okurz will reboot the machine in the evening to enable the newest kernel.
Updated by nicksinger over 5 years ago
foursixnine mentioned in #opensuse-factory:
10:01 <foursixnine> nsinger: I think one change required for o3 is to update the worker's setting and set the WORKER_HOSTNAME to the ip addresses, so that interactive mode can be used
I think this is covered in https://progress.opensuse.org/issues/43148
Updated by okurz over 5 years ago
- Status changed from Resolved to Feedback
- Assignee changed from nicksinger to okurz
Actually I have not yet dared to reboot the machine after remembering problems we had on these occassions, e.g. hour-long xfs filesystem checks during bootup which without management interface one would not be able to follow. I asked in #opensuse-admin as well is in internal #infra what we would need to do to get access to such a management interface before taking care of reboot of the machine ourselves or if someone else would take care.
Updated by nicksinger over 5 years ago
- Subject changed from o3 webui update on 2017-11-19 to o3 webui update on 2018-11-19
Updated by okurz over 5 years ago
answer from tampakrap in #opensuse-admin: serial console access requires ssh access (via simple user, root is not really needed) to the hypervisors. I cant take the decision of who non-suse-it can have access to the hypervisors, so please talk to Artem for this until an agreement is reached, either me or anyone from suse-it can do the reboots
I will try to get a hold of achernikov.
Updated by okurz over 5 years ago
- Blocked by tickets #44060: Kind request for access to management interface of ariel VM, e.g. ssh-access, libvirt, "ssh user access to atreju1 to be able to view cscreen" added
Updated by okurz almost 5 years ago
I (or we) still have no access to control the o3 VM however someone (probably SUSE-IT?) installed most recent kernel updates and rebooted the machine. Seems nobody else even has noticed that. I guess this is how it should be ;)
Updated by okurz over 4 years ago
- Blocked by deleted (tickets #44060: Kind request for access to management interface of ariel VM, e.g. ssh-access, libvirt, "ssh user access to atreju1 to be able to view cscreen")
Updated by okurz over 4 years ago
- Related to tickets #44060: Kind request for access to management interface of ariel VM, e.g. ssh-access, libvirt, "ssh user access to atreju1 to be able to view cscreen" added
Updated by okurz over 4 years ago
- Status changed from Blocked to Resolved
#44060 is still open but we will not receive the permissions to control the VMs of neither o3 nor osd so this will simply not happen anytime soon. In case the machine is down or can not boot we have to rely on Engineering Infrastructure to react fast, no better option.