Bug 1221742 - Please remove transactional-server system role
Summary: Please remove transactional-server system role
Status: RESOLVED FIXED
Alias: None
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: YaST2 (show other bugs)
Version: Current
Hardware: Other Other
: P5 - None : Major (vote)
Target Milestone: ---
Assignee: E-mail List
QA Contact: Jiri Srain
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-03-20 08:25 UTC by Thorsten Kukuk
Modified: 2024-07-02 03:30 UTC (History)
7 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Leap 15.5 installation: system roles (95.08 KB, image/png)
2024-03-20 10:13 UTC, Stefan Hundhammer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thorsten Kukuk 2024-03-20 08:25:15 UTC
The transactional server system role is from the time when we had only openSUSE Kubic. But meanwhile we have openSUSE MicroOS, which makes this system role obsolete.

The transactional server role is unsupported and not maintained. It does not work with the defaults of qemu/kvm/libvirt and it's incompatible with SELinux.
We don't have the resources to implement and test everything three times, for Tumbleweed, MicroOS and this system role.

For this reason it should be removed completely from YaST2.
Comment 1 Stefan Hundhammer 2024-03-20 09:13:13 UTC
This is actually a feature request, not a bug. The last time we did something similar to do someone a favour, others were furious at us, and it turned out they had never discussed that among themselves, but we were made responsible for the fallout.


The system role is this one:

  https://github.com/yast/system-role-transactional-server

And it may be used in any of the skelcd* packages here:

  https://github.com/yast?q=skelcd&type=all&language=&sort=

but sometimes those are used as a base (or even alias) for others, so there might be unexpected consequences if we simply start changing things. That was what happened the last time.
Comment 2 Stefan Hundhammer 2024-03-20 09:35:13 UTC
That "transactional-server" role is called internally "serverro" AFAICS (Hurrah for consistent naming!):

https://github.com/yast/skelcd-control-openSUSE/blob/master/control/control.xml#L429
Comment 3 Stefan Hundhammer 2024-03-20 09:40:36 UTC
This was the commit that added it back in 2018:

https://github.com/yast/skelcd-control-openSUSE/commit/18bbf13f8b7767dd1217c9c1756d93833dfddf5e

Corresponding hange log entry:

https://github.com/yast/skelcd-control-openSUSE/blob/master/package/skelcd-control-openSUSE.changes#L458-L469

> -------------------------------------------------------------------
> Wed Mar 16 13:14:43 UTC 2018 - rbrown@suse.com
> 
> - Introduce "Server with Transactional Updates and Read-Only Root
>   Filesystem" System Role (bsc#1084149)
> - Create /root subvolume on fresh installs (bsc#1085266)
> - Re-order installation workflow to ensure partitioning is
>   configured after the system role has altered it
> - Download release notes earlier in installation workflow
> - 42.3.99.23
> 
> -------------------------------------------------------------------
Comment 4 Stefan Hundhammer 2024-03-20 09:44:17 UTC
Dominique, any objections to removing this role for skelcd-control-openSUSE?
Comment 5 Stefan Hundhammer 2024-03-20 09:52:59 UTC
Removing the role from that control.xml file is just one thing to do.

Probably we will also want to drop the corresponding package, which means removing it from the dependencies of all packages that require it. Pattern packages come to mind.
Comment 6 Richard Brown 2024-03-20 10:03:52 UTC
As the originator of this system role

I wholeheartedly support its removal
Comment 7 Stefan Hundhammer 2024-03-20 10:13:01 UTC
Created attachment 873660 [details]
Leap 15.5 installation: system roles

The "transactional server" role is also offered in Leap 15.x.
Comment 8 Thorsten Kukuk 2024-03-20 10:15:18 UTC
(In reply to Stefan Hundhammer from comment #5)

> Probably we will also want to drop the corresponding package, which means
> removing it from the dependencies of all packages that require it. Pattern
> packages come to mind.

Which corresponding package?

I'm more wondering about the used patterns, e.g. "readonly_root_tools" doesn't seem to exist.
The rest of packages and patterns needs of course to stay.
Comment 9 Stefan Hundhammer 2024-03-20 10:16:10 UTC
Lubos, I guess you'll also want this removed for Leap 15.6, right?
Comment 10 Thorsten Kukuk 2024-03-20 10:17:18 UTC
(In reply to Stefan Hundhammer from comment #7)
> Created attachment 873660 [details]
> Leap 15.5 installation: system roles
> 
> The "transactional server" role is also offered in Leap 15.x.

That's coming from SLES, is tech preview only, unsupported and known to be broken.
I don't know why they don't remove it with a SP since it is clear that this system role has no feature and will never leave tech preview. PM stated that there is zero customer interest.
Comment 12 Thorsten Kukuk 2024-03-20 10:22:12 UTC
(In reply to Stefan Hundhammer from comment #11)
> This one:
> 
> https://github.com/yast/system-role-transactional-server/blob/master/package/
> system-role-transactional-server.spec

This doesn't exist in openSUSE Tumbleweed.
Comment 13 Stefan Hundhammer 2024-03-20 10:23:57 UTC
On my Leap 15.5:

>. % sudo zypper search system-role-transactional-server
>.
>. Loading repository data...
>. Reading installed packages...
>. 
>. S | Name                             | Summary                              | Type
>. --+----------------------------------+--------------------------------------+--------
>.   | system-role-transactional-server | Transactional Server role definition | package
Comment 14 Stefan Hundhammer 2024-03-20 10:28:54 UTC
Indeed that "zypper search" comes up empty on TW. But on Leap 15.5, it's in the main repo (not YaST:Devel:Head or anything similar).
Comment 15 Stefan Hundhammer 2024-03-20 10:45:41 UTC
This will also need changes in the documentation:

https://doc.opensuse.org/documentation/leap/startup/single-html/book-startup/index.html#sec-yast-install-system-role
Comment 16 Dominique Leuenberger 2024-03-20 11:02:49 UTC
(In reply to Stefan Hundhammer from comment #4)
> Dominique, any objections to removing this role for skelcd-control-openSUSE?

No strong objection - if it does not work

the 'it does not work statement' is a bit puzzling though, as we even have it openQA covered:

* https://openqa.opensuse.org/tests/4025834
* https://openqa.opensuse.org/tests/4025829
* https://openqa.opensuse.org/tests/4026875
Comment 17 Thorsten Kukuk 2024-03-20 12:54:41 UTC
(In reply to Dominique Leuenberger from comment #16)

> the 'it does not work statement' is a bit puzzling though, as we even have
> it openQA covered:
> 
> * https://openqa.opensuse.org/tests/4025834
> * https://openqa.opensuse.org/tests/4025829
> * https://openqa.opensuse.org/tests/4026875

This are the standard minimal MicroOS tests. They use special sized disks, not the defaults as libvirt would suggest. They don't switch any of the defaults and don't use SELinux.
Comment 18 Stefan Hundhammer 2024-03-21 14:18:14 UTC
PR for master / TW:

  https://github.com/yast/skelcd-control-openSUSE/pull/281

this will become available with

  skelcd-control-openSUSE-20240321
Comment 19 Dominique Leuenberger 2024-03-21 14:31:31 UTC
openqa: stop testing the transactional server role: https://github.com/os-autoinst/opensuse-jobgroups/pull/439
Comment 20 Pavin Joseph 2024-03-22 14:52:00 UTC
@Thorsten You aren't considering removing it from normal Tumbleweed / Slowroll right? I'm using it for nightly updates ever since I found it and it has saved me quite a few times already :-)
Comment 21 Stefan Hundhammer 2024-03-22 17:04:29 UTC
@Pavin: Of course this goes to normal TW; that's the whole point of this request.

But this is only about the installation; if you have it on any existing TW, that won't change. But you won't be able to easily install a new system that way anymore; that will be some more manual steps after the installation.
Comment 22 Pavin Joseph 2024-03-22 17:12:14 UTC
@Stefan Thanks for the clarification. I should clarify my own request, I meant to ask if transactional-update (TU) would continue to be supported for normal read-write Tumbleweed installs. I and many others on OpenSuse forums use TU dup instead of "zypper dup".

Existing members of the forum seems to think TU is not supported on read-write Tumbleweed installations or support for it might be dropped in the future for read-only systems.
Comment 23 Pavin Joseph 2024-03-22 17:14:34 UTC
I'm such a klutz, phrasing the last part better: Existing members of the forum seems to think TU is not supported on read-write Tumbleweed installations or support for it might be dropped in the future in favor of read-only systems.
Comment 24 Stefan Hundhammer 2024-03-24 15:08:02 UTC
This pull request from comment #18 is purely for offering the "transactional server role" during installation. None of this touches any existing setup that you might already have deployed.

What this system role did:

https://github.com/yast/skelcd-control-openSUSE/blob/master/control/control.xml#L428-L560

I.e. it's mostly about a storage setup with a read-only Btrfs with snapshots, which you cannot change during installation if you select this system role.

Other than that, it also pulls in two software patterns, 'enhanced_base' and 'transactional_base', and it sets the defaults for enabling the ssh port in the firewall and installing sshd.


It's really not rocket science, and it should be reasonably easy for a non-novice user to set this up manually if desired.
Comment 25 Pavin Joseph 2024-03-24 15:21:52 UTC
Great, thanks for the clarification.
Comment 26 Stefan Hundhammer 2024-03-24 15:25:45 UTC
Pattern 'transactional_base' is provided by package 'patterns-base-transactional_base' which will pull in a number of packages:


% zypper info --requires --recommends patterns-base-transactional_base
Loading repository data...
Reading installed packages...


Information for package patterns-base-transactional_base:
---------------------------------------------------------
Repository     : Main Repository
Name           : patterns-base-transactional_base
Version        : 20200505-lp155.10.5
Arch           : x86_64
Vendor         : openSUSE
Installed Size : 64 B
Installed      : No
Status         : not installed
Source package : patterns-base-20200505-lp155.10.5.src
Upstream URL   : https://github.com/openSUSE/patterns
Summary        : Transactional Base System
Description    : 
    This is the base system for a host updated by Transactional
    Updates. Includes Tools for systems with a read-only root
    filesystem.
Requires       : [7]
    man
    transactional-update
    rebootmgr
    read-only-root-fs
    systemd-presets-branding-transactional-server
    transactional-update-zypp-config
    pattern() = base
Recommends     : pattern() = enhanced_base
Comment 27 Thorsten Kukuk 2024-03-24 19:09:41 UTC
(In reply to Pavin Joseph from comment #23)
> I'm such a klutz, phrasing the last part better: Existing members of the
> forum seems to think TU is not supported on read-write Tumbleweed
> installations or support for it might be dropped in the future in favor of
> read-only systems.

The transactional server system role requires a read-only root filesystem. So this has nothing to do with your use case.
While transactional-update currently works with a read-write root filesystem, it is really not supported. And if we need to break it for new features, we will break it.
Using transactional-uodate on a read-write filesystem can lead to data lossage.
Comment 28 Pavin Joseph 2024-03-25 06:37:21 UTC
@Thorsten Thanks for the confirmation about the current changes, but the future is still sad that you would drop support for read-write systems after having advertised support for it over the last few years.

It seems like you do not care about existing users unless they're using a read-only root filesystem.

From the docs which you and Ignaz wrote:
transactional-update is typically used on a read-only root file system, even though it also supports regular read-write systems.

From the manpages:
       On read-write systems please be aware that all changes done to the running root filesystem after snapshot creation are lost after the next reboot. For this reason
       the system should be rebooted as fast as possible after a successful update.

--
           Sets the default root file system. On a read-only system the root file system is set directly using btrfs. On read-write systems snapper(8) rollback is
           called.
Comment 29 Stefan Hundhammer 2024-03-25 10:21:58 UTC
(In reply to Pavin Joseph from comment #28)
> @Thorsten Thanks for the confirmation about the current changes, but the
> future is still sad that you would drop support for read-write systems after
> having advertised support for it over the last few years.

This might be misleading for others reading this bug. To clarify: Pavin's last comment #28 was about 'transactional-update' supporting a read-write root filesystem (vs. the read-only root filesystem which is normally used in connection with 'transactional-update'). That was a spin-off discussion here.

Of course a normal Tumbleweed or Leap 15.x uses a read-write root filesystem by default. Sticking to that default was what this bug was all about; hence the request to remove that 'transactional server' system role which uses a very different approach.
Comment 30 Stefan Hundhammer 2024-03-25 10:30:15 UTC
SR to Factory / TW:

https://build.opensuse.org/request/show/1161360
Comment 31 Stefan Hundhammer 2024-03-25 10:52:28 UTC
Backport PR for Leap 15.6:

https://github.com/yast/skelcd-control-openSUSE/pull/282
Comment 32 Stefan Hundhammer 2024-03-25 12:26:51 UTC
SR to OBS YaST:openSUSE:15.6 as skelcd-control-openSUSE-15.6.1:

https://build.opensuse.org/request/show/1161383
Comment 33 Felix Niederwanger 2024-04-15 11:34:40 UTC
Does this also mean there won't be a Transactional Server Module for 15-SP6, as it was for 15-SP5?

Also what happens to existing 15-SP5/Leap 15.5 server installed with this role?
Comment 34 Thorsten Kukuk 2024-04-15 12:29:40 UTC
(In reply to Felix Niederwanger from comment #33)
> Does this also mean there won't be a Transactional Server Module for 15-SP6,
> as it was for 15-SP5?
> 
> Also what happens to existing 15-SP5/Leap 15.5 server installed with this
> role?

Product: openSUSE Tumbleweed
Comment 35 Felix Niederwanger 2024-04-15 14:28:19 UTC
(In reply to Thorsten Kukuk from comment #34)
> (In reply to Felix Niederwanger from comment #33)
> > Does this also mean there won't be a Transactional Server Module for 15-SP6,
> > as it was for 15-SP5?
> > 
> > Also what happens to existing 15-SP5/Leap 15.5 server installed with this
> > role?
> 
> Product: openSUSE Tumbleweed

Sorry, I have been redirected here from https://bugzilla.suse.com/show_bug.cgi?id=1222797. If this bsc applies only for Tumbleweed, then this redirect was wrong.
Comment 36 Lukas Ocilka 2024-04-17 07:40:35 UTC
It does not apply to TW only, please, read all the comments in this bug.
Comment 37 Stefan Hundhammer 2024-04-17 08:05:23 UTC
(In reply to Felix Niederwanger from comment #33)
> Does this also mean there won't be a Transactional Server Module for 15-SP6,
> as it was for 15-SP5?

What "module"? Do you mean the pattern? See comment #26.

 
> Also what happens to existing 15-SP5/Leap 15.5 server installed with this
> role?

See comment #24.

This affects TW and Leap 15.6. A backport to Leap 15.5 would be pointless anyway since this is only about the INSTALLATION and what roles are offered there.
Comment 38 Stefan Hundhammer 2024-04-17 08:18:00 UTC
(In reply to Stefan Hundhammer from comment #37)
> (In reply to Felix Niederwanger from comment #33)
> > Does this also mean there won't be a Transactional Server Module for 15-SP6,
> > as it was for 15-SP5?
> 
> What "module"? Do you mean the pattern? See comment #26.

Disregard - I just read the comments about that in the other bug.
Comment 39 Stefan Hundhammer 2024-04-17 11:19:05 UTC
See also bug #1198505 for another good reason to remove this role.
Comment 40 hui 2024-07-02 03:30:00 UTC
*** Bug 1227260 has been marked as a duplicate of this bug. ***