lslezak commented 7 years ago

Sprint 34 Blog Post Draft

This is just a draft for collecting the text for the team blog.
Whenever you finish something worth mentioning in the blog just add a new entry
The text will be reviewed and polished before publishing, this is just to collect the input from the developers. So be focused on the technical side, the wording, grammar, etc... will be improved later :wink:
It is a good idea to add a link to Trello card, bugzilla or a GitHub PR for the reference (it will not be published in the final text but it will make the review or changes easier).

Fixed the ZFCP Controller Configuration in zKVM on S390, CI (Continuous Improvements)

When running the installer on a mainframe in a zKVM virtual machine it displays a warning about not detected ZFCP controllers:

zfcp_warning

However, when running in a zKVM virtual machine the disk is accessible via the virtio driver, not through an emulated ZFCP controller. The warning is pointless and confusing.

The fix was basically just an one-liner which skips the warning when the zKVM virtualization is detected, but the module received low maintenance so far so we applied our boy scout rule and improved the code a bit.

The improvements include using Rubocop for clean and unified coding style, enabling code coverage to know how much the code is tested (in this case it turned out to be horribly low, just about 4%), removing unused files, etc... You can find the details in the pull request.

shundhammer commented 7 years ago

Making Storage Commit Actions Great Again

(work in progress)

The core functionality of the new libstorage is to take two device graphs (the probed storage devices vs. the ones we planned for the installation) and automatically calculate the transitions from one to the other - the action graph: What partitions to delete, which to create, what filesystems to create, where to mount them etc. The big plus of this is that no action can be overlooked - it is automatically generated, and dependencies between them are taken into account, so they will be executed in the correct order.

Right now we are still dumping the raw action graph into the window for the storage proposal. But while this is great for debugging, there are way too many micro-actions the user does not care about, and the big picture is obscured:

*  Delete partition /dev/sda1 (100.00 GiB)
*  Create primary partition /dev/sda1 (67.00 GiB)
*  Set id of partition /dev/sda1 to Linux LVM (0x8E)
*  Create encryption layer device on /dev/sda1
*  Activate encryption layer device on /dev/sda1
*  Create physical volume on /dev/mapper/cr_sda1
*  Create volume group system (67.00 GiB)
*  Create logical volume home (25.00 GiB) on volume group system
*  Create xfs on /dev/system/home (25.00 GiB)
*  Create logical volume swap (2.00 GiB) on volume group system
*  Create swap on /dev/system/swap (2.00 GiB)
*  Mount /dev/system/swap at swap
*  Create logical volume root (40.00 GiB) on volume group system
*  Create btrfs on /dev/system/root (40.00 GiB)
*  Create subvolume @ on /dev/system/root
*  Create subvolume @/var/opt on /dev/system/root
*  Create subvolume @/var/log on /dev/system/root
*  Create subvolume @/var/lib/pgsql on /dev/system/root
*  Set option 'no copy on write' for subvolume @/var/lib/pgsql on /dev/system/root
...
*  Mount subvolume @/var/lib/pgsql on /dev/system/root at /var/lib/pgsql
*  Mount subvolume @/var/log on /dev/system/root at /var/log
*  Mount subvolume @/var/opt on /dev/system/root at /var/opt
...
*  Add mount point /var/opt of subvolume @/var/opt on /dev/system/root to /etc/fstab
*  Add mount point /var/log of subvolume @/var/log on /dev/system/root to /etc/fstab
*  Add mount point /var/lib/pgsql of subvolume @/var/lib/pgsql on /dev/system/root to /etc/fstab
...

This is complete and mathematically correct, but not really human readable. What we really want our users to see is a much more concise output like this:

*  Delete partition /dev/sda1 (100.00 GiB)
*  Create encrypted partition /dev/sda1 (67.00 GiB) as LVM physical device
*  Create LVM volume group /dev/system (67.00 GiB) with /dev/sda1
*  Create LVM logical volume /dev/system/root (40.00 GiB) for / with btrfs
*  Create LVM logical volume /dev/system/swap (2.00 GiB) for swap
*  Create LVM logical volume /dev/system/home (25.00 GiB) for /home with xfs
*  Create 20 subvolumes on /dev/system/root  [Details...]

And if the user clicks on [Details...], this is added for all those subvolumes that most users don't really care that much about:

*  Create subvolume @/var/lib/pgsql on /dev/system/root with option 'no copy on write'
*  Create subvolume @/var/log on /dev/system/root
*  Create subvolume @/var/opt on /dev/system/root
...

The basic idea is to combine most of the relevant actions into one and not bother the user with adding mount points to /etc/fstab etc.

imobachgs commented 7 years ago

Blog: Configuring the NTP service in CaaSP

For a CaaSP cluster to work properly, it's vitally important that all nodes have their clocks in sync. So, from now on, the installer is able to configure each node in a proper way and the administration node will act as NTP server for the worker nodes.

To achieve that, the user will be asked to specify one or several NTP servers to be used as time source during administration node installation and YaST will take care of the rest (updating the configuration and enabling the service).

If a NTP service is announced through SLP, YaST will propose automatically.

ntp-no-server

For worker nodes, YaST will configure the system to keep it synchronized with the administration role.

joseivanlopez commented 7 years ago

Proposal guided setup

In previous sprint we presented a renovated proposal guided setup that now comes with more adjustments and improvements. The general wizard workflow incorporates a refined logic, making it smarter and more usable. This revised version is able to decide which steps to show depending on the current scenario. For example, imagine you only have one disk in your system and therefore you do not need to decide which disk to use. Now, the proposal is aware of that, and it only requires from the user what it is really necessary. As result, some dialogs, as for example the disks selection, could be skipped if it does not make sense.

The actions to do with existing partitions have also gone a step further. In the first guided setup version, the second dialog showed these options only for illustrative purposes, but now they have become into real options where you can select what to do with your Windows or Linux partitions, even more, you could decide actions over other types of partitions.

Take image from PBI Guided set-up: Apply the setting what to do with existing partitions.

In addition, the password selection for encryption is now more usuable, allowing you to choose a not so strong password if you decide that.

default_yes

And until here with our improved guided setup. We will continue informing you with new advances in following sprints.

jreidinger commented 7 years ago

Trusted Boot Support for EFI

YaST2 Bootloader already supported trusted booting for legacy boot on x86_64. With new TPM2 it is possible to have trusted booting also for EFI boot. In this sprint we added support for it to bootloader module. So now it looks same in non-EFI and EFI variant, even if underlaying technology is different. We cannot did it without help of other tools which also now support TPM2.

mchf commented 7 years ago

Insserv removal

YaST is complex and large piece software. It means that time to time some pieces get not so shining then obsolete and in the end broken and or useless. This time we focused on removing calls to insserv. There were several reasons for that decision. Basicaly SUSE has used systemd for couple of years already, so revising places where the YaST code depended on SySV was must. Moreover insserv was replaced by a stub anyway. As a side effect it shortened list of YaST dependencies and in the end it is another small step towards smaller installation.