Another three weeks period and another report from the YaST Team (if you don’t know what we are talking about, see highlights of sprint 13 and the presentation post). This was actually a very productive sprint although, as usual, not all changes have such an obvious impact on final users, at least in the short term.

Redesign and refactoring of the user creation dialog

One of the most visible changes, at least during the installation process, is the revamped dialog for creating local users. There is a full screenshots-packed description of the original problems (at usability and code levels) and the implemented solution in the description of this pull request at Github.com.

Spoilers: the new dialog looks like the screenshot below and the openSUSE community now needs to decide the default behavior we want for Tumbleweed regarding password encryption methods. To take part in that discussion, read the mentioned description and reply to this thread in the openSUSE Factory mailing list.

Beyond the obvious changes for the final user, the implementation of the new dialogs resulted in a much cleaner and more tested code base, including a new reusable class to greatly streamline the development of new installation dialogs in the future.

One step further in the new libstorage: installation proposal

In the highlights of the previous sprint, we already explained the YaST team is putting a lot of effort in rewriting the layer that access to disks, partitions, volumes and all that. One important milestone in such rewrite is the ability to examine a hard disk with a complex partitioning schema (including MS Windows partitions, a Linux installation and so on) and propose the operations that need to be performed in order to install (open)SUSE. It’s a more complex topic that it could look at the first glance.

During this sprint we created a command line tool that can perform that task. Is still not part of the installation process and will take quite some time until it gets there, but it’s already a nice showcase of the capabilities of the new library.

Fixed a crash when EULA download fails

If a download error occurred during the installation of any module or extension requiring an EULA, YaST simply exited after displaying a pop-up error, as you can see here.

Now the workflow goes back to the extension selection, to retry or to deselect the problematic extension. Just like this.

Continuous integration for Snapper and (the current) libstorage

Snapper and libstorage now build the Git “master” branch continuously on ci.opensuse.org (S, L), and commit a passing build to the OBS development project (S, L), and if the version number has changed, submit the package to Factory (S, L).

The same set-up works on ci.suse.de (S, L), committing to the SUSE’s internal OBS instance (S, L) and submitting to the future SLE12-SP2 (S, L).

This brings these two packages up to the level of automation that the YaST team uses for the yast2-* packages, and allows releasing simple fixes even by team members who do not work on these packages regularly.

Disk usage stats in installation and software manager: do not list subvolumes

While installing software, YaST provides a visual overview of the free space in the different mount points of the system. With Btrfs and its subvolumes feature, the separation between a physical disk and its mount point is not that clear anymore. That resulted in wrong reports in YaST, like the one displayed in the left bottom corner of this screen.

The actual calculation of free space is performed by libzypp (the Zypper library), YaST only takes care of rendering the result of that calculation in the screen. Thus, we closely collaborated with the Zypper developer, Michael Andres, to teach libzypp how to deal with Btrfs subvolumes. Thanks to his work, with any version of libzypp >= 15.21 (already available in Tumbleweed), you can enjoy an error-free disk usage report.

To ensure we have no regressions, the YaST team also contributed a new test to openQA. See it in action.

Cleanup dependencies in YaST systemd services

We have received several bug reports about problems executing AutoYaST or YasT2-Firstboot in combination with complex network settings or third party services… and even in some simple scenarios. Many of these problems boil down to a single culprit – the dependencies of the YaST related systemd units.

During this sprint we have simplified the unit files for Tumbleweed and SLE, as you can see in this pull request. It’s a small change but with a huge impact and several implications, so a lot of time was invested into testing during the sprint. The problems seem to be gone, but more AutoYaST and YaST-Firstboot testing would be highly appreciated.

Many other things

As usual, this is only a brief collection of highlights of all the job done during the sprint. Using Scrum terminology, this represents only 27 story points out of a total of 81 story points delivered by the team during this sprint. Using more mundane words, this is just a third part of what we have achieved during the last three weeks.

Hopefully, enough to keep you entertained until the next report in other three weeks!

As promised in the previous post on this blog, we’ll try to keep you updated about what is happening in the YaST world. Before Christmas we finished an specially short sprint, interrupted by another successful Hackweek. Although we always reserve some time for bug fixing, the last two sprints has been quite focused in looking into the future, implementing new solutions for old problems and trying to prepare replacements for some legacy stuff we have been carrying on for too long. Here you are the highlights.

SCR replacement

For low level access to the system, YaST uses its own library called SCR, inherited from the old YCP days. It’s used to call scripts and also to read and write files. Its design is showing its age and using it from Ruby is unnecessary complex. We feel SCR is one of the biggest source of confusion for newcomers to YaST development. Last but not least, SCR is only used by YaST which means all the maintenance work fall to us.

We want to use a new approach for the future. For running scripts we plan to use a Ruby gem called Cheetah and for accessing configuration files we plan to rely on Augeas.

Taking some improvements that were needed in YaST2-Bootloader and the drop of perl-bootloader as starting points (or as an excuse, if you prefer), we have used this sprint to develop all the moving parts that will allow us to easily use Cheetah and Augeas within YaST.

For Cheetah, we have contributed two features to the upstream project: chroot support and the ability to provide environment variables.

For Augeas we have developed an object oriented layer called Config Files Api (shortly CFA). The idea of CFA is to provide specific functionality by mean of plugins. Of course, the first plugin we have developed is aimed to manipulation of all the Grub2 configuration files.

The next step will be to integrate these new components into the next versions of YaST2-Bootloader, hitting your Tumbleweed repositories soon. Of course, after all the usual manual and openQA testing.

Libstorage replacement

Another low level layer that has been a constant source of headache for YaST developers is libstorage. We use it -specially in the installer and the partitioner- to access disks, partitions, volumes and all that. Once again, the original design have fundamental flaws that limit us in many ways and we have been dreaming for quite some time about writing a replacement for it.

To make this rewrite fit into the Scrum process, we are using the new redesigned library (find the code at Github and the packages at OBS) to write prototypes for the installer partitioning proposal and for a new partitioning YaST module.

This new module is only intended as a testbed to showcase the development of the new library and to drive its integration process. It’s not intended for end users, but after this sprint it can already do some things that are impossible with the current partitioner and even shows some nice graphs really useful for debugging and verifying the behavior of the library.

If you don’t mind to break your system using unsupported software, you can always fetch the code or the packages.

AutoYaST integration tests

Testing is crucial in software development. And integration tests are a must when you are developing an installer. During the last sprints, we have been developing and improving our own solution for testing AutoYaST-driven installations, consisting on a set of tests and a framework to run them.

The goal for this sprint was to de-couple the tests and the framework. Making it possible to reuse our tests in openQA. As a side effect, we wanted to ease the installation and usage of our testing framework.

Both goals were achieved, now you can install AutoYaST Integration Tests (not a very original name) following the instructions available in the repository and there is already an openQA instance directly running the separately available tests.

Snapper development documentation

Last but not least, as a side effect of the development (and the Scrum principles), we have improved the Snapper’s development documentation. Enjoy it at the usual Snapper repository.

That’s all folks. Next sprint starts next week and will be three weeks long, so expect more news during the first days of February.