Home Home > Programming
Sign up | Login

Archive for the ‘Programming’ Category

Highlights of YaST development sprint 33

April 26th, 2017 by

It has been a long time since our last status update! The reason is the end of the previous sprint caught quite some of the YaST Team members on vacations and, when the vacation period was over, we were so anxious to jump into development to make YaST another little bit better that the blog post somehow fell behind.

But it’s time to pay our (reporting) debts. So these are some of the highlights of the 33th development sprint that finished on April 11th.

AutoYaST and Salt integration

During this sprint, a new module has been added to the YaST tool box: YaST2 Configuration Management.

This module offers integration between AutoYaST and configuration management systems like Salt. The idea is that AutoYaST will take care of system installation (partitioning, network setup, etc.) and, if desired, the system configuration can be delegated to one of those external tools.

The YaST Configuration Management module was born during an internal SUSE workshop during the last summer and it got more love during HackWeek 14 and 15.

Now it is officially part of the YaST family and it will be included in the upcoming releases.

The new module: YaST - Configuration Manager

Extend the YaST Installer Workflow by Add-ons

The YaST installer already allows extending the installation work flow by add-on extensions. However, this was only supported for the SUSE tag repositories used on the ISO installation media. That means the online repositories, which normally use the RPM-MD data format, could not use this feature.

This sprint we extended the support also for the other repository formats (basically any repository format supported by libzypp). The original limitation was caused by the fact that the other repository types do not support other files except the RPM packages.

To overcome this limitation we now support packaging the installer extension files into a standard RPM package which can be then provided by any repository type.

The implementation is documented and there is the YaST:extension OBS project with a simple example extension.

The example extension in action

YaST pattern definitions

The software pattern definitions have been split and moved to the respective OBS devel projects. See more details in this opensuse-factory announcement. That means the YaST patterns are now maintained in the
YaST:Head project.

The project sources have been imported to the GitHub repository to track the history and use the code review workflow. Also and the usual Jenkins and Travis automation has been set up. For contributing your changes in the YaST patterns use the usual GitHub pull request workflow as for the other YaST packages. Thank you in advance! 😉

CaaSP deserves its own YaST package!

Among other things, our team is working hard to make YaST fulfill the requirements of the upcoming Containers as a Service Platform (CaaSP) product. As part of this effort, we have added some new features, discovered (and fixed) some bugs, improved documentation and so on.

We’ve also added some specific CaaSP code, so during this sprint we’ve decided to create a new dedicated package (yast2-caasp) and move the code there.

Currently it only contains system role handlers and some additional documentation, but most probably we will add some stuff during the upcoming months.

Bootloader improvement

Also the bootloader module has been improved to better handle invalid partitioning proposal in the CaaSP product. When the partitioning proposal did not contain a valid root directory then the bootloader module crashed.

After the fix it now displays details about the problem so the user can manually fix the configuration.

New YaST-bootloader warning

Automatic screenshots in the AutoYaST integration tests

An important part of keeping the quality in a job is investing in the quality of the tools. So during this sprint we decided to improve the capabilities of the AutoYaST integration tests. To help with debugging, AYTests will now store a screenshot and, if possible, YaST2 logs from installation/upgrade under the workspace.

The screenshot will be refreshed every 30 seconds so, if a timeout occurs, it will be now easy to find out where the process got stuck.

Creating your own installation media

Recently, a new set of packages were introduced into Tumbleweed to help setting up the local installation servers. They are named tftpboot-installation-<PRODUCT>-<ARCH> (for example tftpboot-installation-openSUSE-Tumbleweed-x86_64) and are intended to make it easy to set up the PXE boot environment for an installation server.

These packages basically contain the installation environment as found on the SUSE installation media.

And this enables mksusecd to create a network installation image from it.

For example, the package above installs its files into directory /srv/tftpboot/openSUSE-Tumbleweed-x86_64.

So, let’s run

mksusecd \
  --create foo.iso \
  --net=http://download.opensuse.org/tumbleweed/repo/oss/suse \
  /srv/tftpboot/openSUSE-Tumbleweed-x86_64

and we get a network installation ISO image that will install the Tumbleweed distribution using the official openSUSE Tumbleweed repository.

Note that we are using the RPM-MD repository at /tumbleweed/repo/oss/suse instead of /tumbleweed/repo/oss as one might expect. Of course it is also OK to use the /tumbleweed/repo/oss repository but we want to be cool. 😀

You can put foo.iso also on a USB stick

dd if=foo.iso of=/dev/<USB_DEVICE>

and boot from it.

To be extra-cool, try the --fat option

mksusecd \
  --create foo.iso \
  --fat \
  --net=http://download.opensuse.org/tumbleweed/repo/oss/suse \
  /srv/tftpboot/openSUSE-Tumbleweed-x86_64

that will create a FAT partition for the data, which is a bit more convenient when you plan to put the image on an USB stick (and yes, you can still use the image to burn a DVD).

Serial console at boot

The YaST bootloader module can be used to configure the parameters to allow accessing the system’s boot process through a serial console. But that’s a relatively complex topic and is easy to make mistakes when specifying such parameters. In the past, the message displayed by YaST in case of error was not helpful enough. To improve usability, the new pop-up is nicer and includes a proper example, as can be seen in the following screenshot.

More guided serial console setup in YaST-Bootloader

Storage reimplementation: new proposal guided setup

The previous sprint we brought in the ability to use encryption for both partition-based and LVM-based proposals. This time we go a step further and present a new guided setup that allows you to do even more. We have worked hand in hand with our UX experts to design a new proposal wizard composed by four steps.

In the first one, a list with the available disks is showed and you can select which ones to use for your fresh installation.

Guided proposal setup - step 1

In the second screen, you can select a specific disk to be used for the root partition, and also, you might decide what to do with the existing Windows and Linux installed systems. Currently, this last functionality is only illustrative, but it will become functional in the upcoming sprints.

Guided proposal setup - step 2

The third step is surely more familiar for you. As in the previous sprint, here you can select the LVM usage and encryption. And of course, the encryption password will be checked to ensure you use it is strong enough.

Guided proposal setup - step 3

Finally, in the last step the filesystem type for the root partition can be selected. Moreover, you can decide whether to use a separate home or not. Or you can select another filesystem type for your home.

As result of the wizard, a new partition schema is automatically created taking into account all the options you have selected. And naturally, that is only the first version. We will let know about the news in the guided setup in following sprints.

Warn the user in case of inconsistencies in Online Migration

Before the live Service Pack migration the system can be manually modified in many ways producing inconsistencies between the installed system and the extensions/modules registered in the registration server.

In this sprint we have added some steps that will allow the user to fix the inconsistencies. Also the displayed summary of the available migrations has been improved showing information about products without any migration available (e.g. third party addons).

For the online migration it is important to be able to rollback to the original state (before the migration started) when a problem occurs or the migration is aborted by user.

Now the user will be able to decide if the registered but not installed products should be deactivated as part of the rollback.

Warning for inconsistent online migration

See you very soon!

As usual, this report only covers a relatively small part of all the work done during the previous sprint and, as usual, you will have to wait until the end of the current sprint to get more exciting news. The bright side is that the sprint will finish in a matter of days, so you will only need to wait one week to read our next report.

Stay tuned and have a lot of fun!

Highlights of YaST development sprint 32

March 22nd, 2017 by

To make sure you didn’t missed us too much, in our latest blog post we summarized all the YaST-related projects worked during Hack Week 15. But after all the fun, it was time for… more fun! So let’s take a look to what the team has delivered on this first sprint after Hack Week 15.

Storage reimplementation: encrypted proposal without LVM

One of the known limitations of the current installer is that it’s only able to automatically propose an encrypted schema if LVM is used. For historical reasons, if you want to encrypt your root and/or home partitions but not to use LVM, you would need to use the expert partitioner… and hope for the best from the bootloader proposal.

But the new storage stack is here (well, almost here) to make all the old limitations vanish. With our testing ISO it’s already possible to set encryption with just one click for both partition-based and LVM-based proposals. The best possible partition schema is correctly created and everything is encrypted as the user would expect. We even have continuous tests in our internal openQA instance for it.

The part of the installer managing the bootloader installation is still not adapted, which means the resulting system would need some manual fixing of Grub before being able to boot… but that’s something for an upcoming sprint (likely the very next one).

Improved add-ons listing for SLE12-SP1

The dialog in SLES-12-SP1 for selecting the add-ons after registering the system was originally designed just for a small list of add-ons. Unfortunately (or fortunately, depending on how you look at it), the number of add-ons grew over the time and it exceeded the original limit for the text mode UI.

The equivalent screen in SLE-12-SP2 is not affected by the problem because it uses a different layout with scrollable list. But the SP1 dialog looks like this.

Broken add-ons list in SP1

If you look carefully at the screenshot you will see that the Web and Scripting Module is missing in the list and the Back, Next and Abort buttons at the bottom are also not displayed.

The fix decreased the size of the Details widget and allowed displaying more items in each column. Now there is even free space for three more add-ons.

Fixed addons list in SP1

Moreover the dialog is now dynamic and checks the current size of the screen. If there is enough free space then the list is displayed in one column so the labels are not truncated and the Details widget size is increased back to the original size.

Add-ons list in SP1 with enough space

Storage reimplementation: Btrfs subvolumes

The management of subvolumes is one of those features that make Btrfs rather unique and that need special handling when compared to more traditional file systems. That was indeed one of the several reasons to rewrite libstorage – Btrfs subvolumes never fully fitted the philosophy and data structures on the old (current) libstorage and yast2-storage.

In this sprint we introduced support for subvolumes in libstorage-ng from the ground up, taking into consideration all the specificities, use cases and scenarios found in the past. And, hopefully, in a way that is also prepared for whatever the future brings.

The new functionality is already working and tested and it’s included in the latest versions of libstorage-ng, but is still not used in the proposal or any other part yast2-storage. You will have to wait another sprint to see more visible results. At least if “more visible” means screenshots. Meanwhile, if you like images you can always enjoy the graphs generated from the internal structures managed by libstorage-ng.

Internal subvolumes representation in libstorage-ng

Storage reimplementation: system upgrade

The new storage stack has been able to install an openSUSE system for quite some time already. While we keep improving that area, the next challenge was to make the upgrade from a previous openSUSE version also possible using our testing ISO.

That implies scanning the hard disks looking for previous installations, allowing the user to select one, mounting the corresponding partitions or LVM volumes, performing the update of every package and doing some final tasks like updating the bootloader configuration.

Following the iterative approach encouraged by Scrum, we focused in the first three steps, which is something that a user (or openQA, for that matter) can test and verify. So now we are able to detect and list pre-existing systems and start the upgrade process on the selected one. And we have automated tests in openQA to ensure it works across all the combinations of partition-based vs LVM-based layout and UUID-based vs name-based fstab file.

Add-ons can define new system roles

YaST is pretty customizable when it comes to adapt/modify the installation workflow. Among other things, add-ons are allowed to adapt the workflow (adding/removing steps), define new proposals, etc. And starting now, they can also define new system roles.

Let’s see an example of adding a new mail server role:

<update>
  <system_roles>
    <insert_system_roles config:type="list">
      <insert_system_role>
        <system_roles config:type="list">
          <system_role>
            <id>mail_role</id>
            <software>
              <default_patterns>base Minimal mail_server</default_patterns>
            </software>
          </system_role>
        </system_roles>
      </insert_system_role>
    </insert_system_roles>
  </system_roles>
</update>

<!-- Don't forget to add the texts -->
<texts>
  <mail_role>
    <label>Mail Server</label>
  </mail_role>
  <mail_role_description>
    <label>• Software needed to set up a mail server
• No production ready yet!</label>
  </mail_role_description>
</texts>

And now let’s see how it looks:

A role added by an addon

Which leads us to the next section…

The list of roles becomes responsive in text mode

A really nice thing about YaST is that it’s able to run in textmode, so you don’t need a graphical interface to install or configure your system. As a consequence, YaST developers need to keep certain limitations in mind when working in the user interface.

Now that add-ons can add new system roles, we noticed a potential problem in the dialog selection screen: we eventually will get out of space if more than one system role is added. So we decided to improve how system roles are displayed to make them fit in a 80×25 mode (that is, only 25 lines of text). Let’s see the changes with some examples.

This is how the screen looks by default, with a reasonably small set of roles.

Default system roles list

If the system detects there is no space to present all the information in such a convenient way, it removes all the spaces so at least the information is all there, even if it looks a little bit packed.

Roles list with no extra space

If even that is not enough, the extra descriptions are omitted, which gives us way more room.

Compact roles list

If roles don’t fit even without the descriptions, the introductory text will be also omitted which means we can present up to eighteen (yes, 18!) roles in the screen.

Storage reimplementation: guided setup mock-up

As explained in several previous reports, we are collaborating closely with SUSE UX experts to design the revamped interfaces of the installer’s partitioning proposal and the expert partitioner. We already showed you the document we used as a base to discuss the partitioning proposal, including the conclusions, and the first very simple prototype of the so-called Guided Setup.

During this sprint, that collaborative effort focused on defining exactly how every step of that wizard should work and look like. The goal was to get some interface mock-ups to be used as starting point for the upcoming sprint. More than ever, a picture (well, four of them) is worth a thousand words.

First step of the guided partitioning setup mock-up

Second step of the guided partitioning setup mock-up

Third step of the guided partitioning setup mock-up

Fourth step of the guided partitioning setup mock-up

Prevent the installation of CaaSP if Btrfs snapshots are not possible

CaaSP is a single purpose system, and having snapshots enabled is essential. So there’s now a check in place that will simply prevent you from going on with the installation if snapshots are disabled (for example, if the disk is too small).

Blocked CaaSP installation

Storage reimplementation: better handling of /etc/fstab and /etc/cryptab

For the new storage stack, we refactored the classes to handle /etc/fstab. While this would normally not be anything to write much about, we included intelligent handling for existing comments based on this standalone GitHub project.

This means that existing comment blocks at the start and at the end of the file remain untouched, and comments before any content entry remain attached to that entry; i.e. when that entry is moved around in the file (e.g. because of mount dependencies), that comment is moving along with the entry it belongs to. While this is not 100% fool proof, it is much better than the usual strategy to simply discard such comments when the file is rewritten.

Quite some adaptations and bugfixes for CaaSP

As you already know from previous reports and other sources, a considerable part of SUSE’s development firepower is focused on building the upcoming CaaSP. As part of that heavy development process, the YaST team invested a significant part of the sprint adapting YaST for CaaSP and fixing bugs introduced by previous adaptations. A large collection of changes here and there that are hard to summarize here but that help CaaSP to be a couple of steps closer to the final goal.

Keep it rolling!

We have already planned our next sprint which will hopefully bring more features to the new storage stack, CaaSP-related improvements, a surprise about AutoYaST and more stuff. And, of course, it will be followed by its corresponding report.

So see you in three weeks. Stay tuned and have a lot of fun!

Highlights of YaST development sprint 31

February 20th, 2017 by

As we announced in the previous report, our 31th Scrum sprint was slightly shorter than the usual ones. But you would never say so looking to this blog post. We have a lot of things to talk you about!

Teaching the installer self-update to be a better citizen

As you may know, YaST includes a nice feature which allows the installer to update itself in order to solve bugs in the installation media. This mechanism has been included in SUSE Linux Enterprise 12 SP2, although it’s not enabled by default (you need to pass an extra option selfupdate=1 to make it work).

So after getting some feedback, we’re working toward fixing some usability problems. The first of them is that, in some situations, the self-update mechanism is too intrusive.

Consider the following scenario: you’re installing a system behind a firewall which prevents the machine to connect to the outside network. As the SUSE Customer Center will be unreachable, YaST complains about not being able to get the list of repositories for the self-update. And, after that, you get another complain because the fallback repository is not accessible. Two error messages and 2 timeouts.

And the situation could be even worse if you don’t have access to a DNS server (add another error message).

So after some discussion we’ve decided to show such errors only if the user has specified SMT or a custom self-update repository (which is also possible). In any other case, the error is logged and the self-update is skipped completely.

You can find further information in our Self-Update Use Cases and Error Handling document.

During upcoming sprints, we’ll keep working on making the self-update feature great!

Configuring workers during CaaSP installation

While CaaSP release approaches, our team is still working hard to satisfy the new requirements. Thankfully, YaST is a pretty flexible tool and it allows us to change a lot of things.

For CaaSP installation, YaST features a one-dialog installation screen. During this sprint, configuration of the Worker role has been implemented, including validation of the entered URL and writing the value to the installed system. You can check the animated screenshot for details.

The CaaSP worker configuration

New desktop selection screen in openSUSE installer

The world of Linux desktop environments change relatively quick, with new options popping-up and some projects being abandoned. Thanks to the openSUSE’s community of packagers we have a lot of these new desktop environments available on the openSUSE distributions. But the status of those packages for openSUSE is also subject to changes: some desktop environments are poorly maintained while others have a strong and active group of packagers and maintainer behind.

The YaST Team does not have enough overview and time to watch all these desktop environment and evaluate which one is ready or not for being in the installer’s desktop selection screen. So the openSUSE Release Team decided to replace this dialog with something a bit more generic but still useful for newcomers.

They asked the YaST Team to come up with a new dialog featuring the two openSUSE main desktops (KDE Plasma and GNOME) and allowing the easy selection of other environments without reworking the dialog in the future. The goal of that new dialog was to replace the existing one you can see in the following screenshot.

The old desktop selection screen

We decided the new dialog should rely on patterns for several reasons. The main one is that the set of patterns is under the close control of the openSUSE community, which looks more closely than us to the desktop environments and their integration into the distribution. Moreover, each pattern specifies its own icon and description that can be somehow re-used by the installer.

We also took the opportunity to merge this almost empty and outdated dialog with the new one.

The old additional repositories screen

Addons are no longer produced for openSUSE, so only the second checkbox made any sense nowadays. Moreover, the functionality of that second checkbox directly influence the available selection of patterns, so it made more sense to merge everything in a single screen that keeping an extra step in the installation just to accommodate a checkbox.

So we sent a proposal for the new dialog to the opensuse-factory mailing list and, after implementing many of the ideas discussed there (like better wording or using a button instead of a checkbox for the online repositories), this is the new dialog that replaces the two ones mentioned above.

The new desktop selection dialog

Selecting “custom” will take the users to the already existing patterns selection screen. Just in case you don’t remember how that screen looks like, you can check this image.

The patterns selection screen

If these screenshots are not enough to make your mind about the change, you can check the following animation, in which KDE Plasma is initially chosen to be changed at a later point (going back in the workflow) to LXQt.

Desktop selection animation

It will take some time before the changes hit the Tumbleweed installer, since they obviously have a non-trivial impact on the openQA tests, that will need some adaptation.

We would like to thank everybody that contributed to this new feature by providing feedback and suggestions through the mailing list. Once again, the openSUSE community has proved to be simply awesome!

Storage reimplementation: improved handling of logical partitions

Our reimplementation of the storage layer keeps getting improvements here and there. With the base x86 case working, we are now implementing the tricky parts, like the partitions renumbering that takes place when dealing with logical partitions in a MBR style partition table.

With GPT partition tables or with primary partitions in a MBR partition table, the partition gets a number (like sda1) when it’s created and keeps that number for its whole lifetime. But logical partition gets constantly renumbered when other partitions are created and destroyed. We need to know in advance what device name every partition will get in order to configure everything beforehand and only commit the changes to the disk when the user clicks in the “install” (during the installation process) or “commit” (if running the expert partitioner).

Now, libstorage-ng is able to simulate in memory the re-numbering process, so we can calculate all the settings related to partitioning (like the configuration of the bootloader) before really touching the disk.

Making kdump work in CaaSP

When you enable the Kernel Crash Dump (kdump), you probably expect that you will get a kind of core dump, like you do for regular processes. What you might not expect is an automatic reboot. That is a nice bonus. If you are tired of waiting for an actual kernel crash, you can test your kdump setup by triggering a crash yourself. Just run this as root:

echo c > /proc/sysrq-trigger

The way kdump works is by allocating some extra memory at boot time and putting a second kernel+initrd there. When the main kernel realizes it is crashing, it transfers control (by kexec) to the other one, which has only one purpose, to dump the memory of the crashed kernel.

In the upcoming Containers as a Service Platform, kdump was not working because the root filesystem is read-only there and we were not able to create the kdump initrd. We fixed it by creating it just after the RPMs are installed, when the FS is still read-write.

Fixes for Snapper in CaaSP

Kdump was not the only component affected by the fact of having a read-only filesystem in CaaSP. Snapper was also running into problems when trying to execute the rollback and cleanup operations. Now the problems are fixed. While working on that we did enough interesting findings to deserve a separate blog entry. So you can expect a new entry in the Snapper.io blog soon.

Snapshot-related improvements in the expert partitioner

While we work on the new storage system, we are still taking care and improving the current one that will continue to be shipped with SLE12-SP3, SUSE CaaSP and openSUSE Leap 42.3. During this sprint we introduced a couple of usability improvements in the expert partitioner related to Btrfs subvolumes.

First of all, we moved the “Enable Snapshots” checkbox that was pretty much hidden in the “Subvolume Handling” dialog to the place where it really belongs – below the selector of the file-system type.

New location for enabling snapshots

In addition, we added the warning you can see in the screenshot below for users enabling snapshots in a potentially problematic setup.

Warning for snapshots in a small partition

Bring back the beta warning on CaaSP

And talking about warnings, we improved the CaaSP installation dialog to show the Alpha/Beta product warning at the beginning. After changing the CaaSP installation to use the all-in-one dialog described in our previous post, this feature was lost as it is part of the initial EULA dialog. Now it is back and the users should now properly see the current product status.

The CaaSP alpha/beta warning pop-up

Storage reimplementation: encrypted LVM proposal

Back to our storage layer reimplementation, the new system is now able to propose a setup with encrypted LVM. Since some sprints ago, we were already able to propose a partition-based and a LVM setup. That means the new proposal is now feature-pair with the old one, with the only exceptions of Btrfs sub-volumes (that shouldn’t be a big challenge) and s/390 storage (that is still not properly managed by the underlying libstorage-ng).

The bright part is that the new code is written with re-usability in mind, which means implementing an encrypted partition-based proposal (with no LVM) would be trivial. The new code is 100% covered by automatic unit tests and scores to the top in all the automatic quality checkers we have run (like Rubycritics, CodeClimate, and Rubocop).

So now we are prepared for whatever the future brings, having lost no single feature in the way.

Storage reimplementation: prototype if the UI for the proposal settings

The next challenge is to make the power of that new storage proposal available to the users through the user interface. In the previous post we presented the document describing the general ideas we wanted to discuss with UX experts.

It’s our pleasure to announce we met the experts and we very easily reached an agreement on how the user interaction should be. During this sprint we already implemented a prototype of the future proposal settings wizard that is, as usual, included in our testing ISO.

Now that we have solid foundations, it’s very likely that the following sprint will result in the fully working wizard, with almost-final wording and design.

Support for CaaSP added to the AutoYaST integration tests

While fixing a problem with AutoYaST and CaaSP, we decided to extend our AutoYaST integration testing tool to support CaaSP. But, as a side effect, we also made some additional improvements that were long overdue (like improving the procedure to download ISOs, reducing timeouts, etc.).

Now, our internal Jenkins instance takes care of running AutoYaST integration tests for the development version of CaaSP (as it already does for SLE 12 SP2).

Services manager moved to first auto-installation stage

AutoYaST allows to define a set of services to be enabled/disabled in the installed system, applying this configuration during the 2nd stage (after the first reboot).

Unfortunately, this approach won’t work for CaaSP because, in that case, the 2nd stage won’t be available. For that reason, during this sprint, we have adapted AutoYaST to write services configuration during 1st stage.

As usual, not only CaaSP, but other future (open)SUSE versions will benefit of this change.

Faster YaST installation when the release notes cannot be downloaded

Sometimes a very small simple change in a program makes a very noticeable impact in its everyday use. That’s the case of a fix implemented during this sprint. YaST usually re-tries to download the distribution release notes several times if the first attempt was unsuccessful. Although that’s correct from a general point of view, there are cases in which retrying makes no sense and only delays the installation. We have now added failed DNS resolution to that list of cases, which should result in a noticeable faster installation in many scenarios.

Moreover, in the case of AutoYaST we now skip downloading the release notes completely. Downloading them don’t make us much sense in the kind of unattended scenarios handled by AutoYaST and skipping this step and all the possible associated problems result in a more robust process.

Better continuous integration for Libyui

In the previous sprint we switched to Docker at Travis so we could build and test our packages in the native openSUSE system instead of the default Ubuntu. This sprint we did the same change also for the Libyui library which implements the UI part of YaST.

Originally we could not build the Libyui packages at Travis as either the required build dependencies were missing or were present at a very old unusable version. With this switch we can easily use the latest packages from openSUSE Tumbleweed and thus enable Travis builds for all Libyui packages.

See you after Hack Week!

As already mentioned, this week is Hack Week 15! So our Scrum process will be on hold for some days. That doesn’t necessarily mean the YaST development will stall. Since there are quite some YaST-related projects in the Hack Week page, you can expect YaST to simply go in unexpected directions. 🙂

And remember Hack Week is not a SUSE internal initiative, we are open to collaboration from anybody within or outside the company. So jump in and have fun with us!

Highlights of YaST development sprint 30

February 3rd, 2017 by

This is our first post in 2017 and looks like we must start apologizing. In our previous post we promised news about this blog, but the administrative part slowed us down and the surprise is still not ready. On the bright side, we have quite some news about YaST. So let’s go for it!

One-click system installation for CaaSP

As you may know, SUSE has been working on making containers easier, with SUSE Container as a Service Platform. We have referred to it in several previous posts using the CASP acronym, although nowadays the correct one is CaaSP (maybe we could sell the new “a” as a shiny feature 😉 ).

Part of this upcoming product is also an interactive installation option using the good old YaST. CaaSP uses a limited subset of the SLE possibilities and we wanted to make the installation simpler to reflect that. So we reduced the number of dialogs you have to click through… to one!

One-click installation in CaaSP

As you can see, it is at the expense of stuffing the screen with more widgets than usual. Still, the only part where you must make a decision is the root password.

We expect that most of the CaaSP installations will actually not use this, because they will be done automatically with AutoYaST. But still this should be useful when you are only getting started.

Refining the read-only installation proposals

It was possible to make a proposal “read-only” for some time already. However, its black-and-white logic was not sufficient for some use cases. So, it was redesigned and you can mark a proposal hard read-only or soft read-only. The difference is that users will never be able to change hard read-only proposal. However their will be able to modify a soft read-only proposal if the proposal reports an error. It can be useful e.g. for error recovery in software proposal. It has been implemented originally for CaaSP, but it will be available for SLE-12-SP3 and Leap 42.3 too.

Installing directly from a repomd repository

When you install (open)SUSE you have up to now needed a specially prepared install repository. In addition to the repository with the RPM packages, it needed a bunch of specially prepared files containing the installation system and our beloved YaST installer.

That’s all gone now!

You can now point the installer to any plain repomd repository. For this to work you have to point the installer to the repomd repository and to the installation system (they can be completely separate now).

For example:

install=http://download.opensuse.org/tumbleweed/repo/oss instsys=disk:/boot/x86_64/root

In that example, we install Tumbleweed from the openSUSE website and use the installer from some local media (maybe the NET iso).

To make things even easier there is now a regular package (tftpboot-installation-openSUSE) that contains the installation system and some sample config files.

Check out this linuxrc documentation for technical details.

Storage reimplementation: removing stones from the installation path

In our latest post, we presented the dedicated openQA instance contantly testing the new storage layer implementation. It still doesn’t run exactly the same tests than openQA.opensuse.org because not all technologies and operations are supported yet in the new yast2-storage. But now we are a couple of steps closer to run the full-blown tests also in our dedicated instance.

During this sprint, the partitioning proposal gained the ability to deal with disks not containing a partition table in advance (it always proposes to create a GPT one in that scenario) and the software selection proposal learned how to use the new storage API, so it can properly inspect the system and the associated error pop-ups are gone from the installation workflow.

More power to the system roles

We keep extending the capabilities of the system roles, now with the ability to specify some systemd services to enable. As the roles can define which software gets installed in the system, it made sense for them to also be able to specify the desired status for the services included in that software

For example, it would be possible for a given product (let’s say a customized openSUSE) to define a “static web server” role. Choosing that role during installation would result in a system with a HTTP server already installed and enabled, so the user just need to copy the files to be served into the right directory.

Expert partitioner is now less restrictive with encryption

Setting up an encrypted LVM was always pretty easy when using the automated storage proposal – simply select “encrypted LVM” at the proposal settings and you are done.

But doing that manually was almost impossible: The expert partitioner wouldn’t allow any of the system mount points (“/”, “/usr”, “/var”, …) on any encrypted partition, and it also wouldn’t allow to encrypt, but not format a partition of type “LVM” for use as an LVM physical volume.

Both restrictions are now lifted; you can now create an LVM physical volume with encryption, or you can do the encryption layer on the logical volume if you prefer. And you can create an encrypted plain partition with a filesystem directly on it without LVM.

Over the years, Grub2 learned how to do that, so you don’t even need a /boot partition anymore. For the time being, you’ll need to enter the encryption password twice, though: once at the Grub2 prompt and once later at the graphical console so systemd can mount those filesystems. Our base system developers are working on a secure solution to avoid that.

Migrate Travis CI to Docker

That’s actually not a change in YaST itself, but in its development infrastructure. Still, we believe it would be interesting for the average reader of our blog.

So far we used Travis CI for building and testing the commits and pull requests at GitHub. But the problem was that by default Travis runs Ubuntu 12.04 or 14.04 at the build workers. That had several drawbacks for us, since compiling and testing YaST on Ubuntu is not trivial and the result is not always 100% equivalent to openSUSE. All this meant extra maintenance work for us.

Fortunately Travis allows using Docker containers at the workers and that allows using basically any Linux distribution. This sprint we spent some time converting the Travis configuration to use a dockerized openSUSE Tumbleweed at Travis.

From Github to Travis thanks to Docker

The work was successful, we switched all YaST modules to use this new builds and the result is already paying off at several levels, although it took us over 100 pull requests (all of them manually tweaked and reviewed) to make it happen.

The current solution is documented and we had also a short internal presentation about this change. The notes from the presentation are available here.

Improved continuous integration for Snapper

We also enabled Travis integration with Docker for Snapper. As you may know, Snapper is a portable software that has always offered packages for many Linux distributions in the filesystems:snapper OBS repository.

So we took the continuous integration one step further and enabled Travis builds on more distributions, currently we build for openSUSE Tumbleweed, openSUSE Leap 42.2, Fedora 25, Debian 8 and Ubuntu 16.10. You can see an example build here or more details in the documentation.

Example build result of Snapper at Travis

That means we can ensure that the package still builds on all these distributions even before merging a pull request!

Better integration with systemd for YaST Services

Systemd recognizes many possible states for a service beyond the classic Unix enabled/disabled and running/stopped, and that list of possible states grows with every systemd release. In the past YaST have had some issues displaying the services status.

Now the problems are fixed by delegating to systemd the conversion from the concrete state to the good old known Unix equivalent. So the user now gets more precise information about all services running on the system.

Storage reimplementation: redesigning the installation user experience

In the latest post we showed you the document we were using as a base to discuss the new expert partitioner UI with usability experts. Now it was turn for the proposal settings dialog. We collected the current state, had a very productive discussion and ended up with a proposal for a new interface. You can check the resulting document covering all that.

As mentioned, the SUSE UX experts will use that document as a starting point to design the final interface. But we want the process to be as open as everything around YaST, so feel free to provide feedback.

Reading product renaming information from libzypp

When performing an upgrade, YaST needs to know whether a product is renamed or replaced by a another one. For example, in the past, the Subscription Manager Tool (SMT) lived in its own product but it’s included in SUSE Linux Enterprise 12. So YaST needs to know that the suse-smt product was just replaced by sles.

This information is usually provided by the SUSE Customer Center (SCC). But what happens if, for example, we are performing an offline upgrade? Until now, YaST used a hard-coded fallback list.

From now on, before falling back to such a list, YaST will ask libzypp for that information so, hopefully, it will avoid some problems while upgrading extensions and it will reduce the hassle of maintaining a hard-coded list.

Storage reimplementation: Making sure to install storage-related packages

The YaST storage subsystem has been taking care about storage-related software packages for a long time. For example, when a specific filesystem type like Btrfs or XFS is used by the system, we need to make sure that necessary support packages like btrfsprogs or xfsprogs are installed.

Figuring out what features are used is now done by the new libstorage. In this sprint, we created one Ruby class that maps those features to respective packages and one class that handles package installation itself. One interesting technical aspect is how Ruby introspection capacities are used to avoid duplicating the list of defined features from the C++ part (i.e. libstorage).

Power the chameleon

Apart from all those changes in YaST, and many more we have not included in this summary, we have something else to celebrate. On February 1st the YaST Team at SUSE has grown with the addition of a new member, Iván, who will allow the project to evolve even faster and better… and that will not be the last announcement in that direction, so stay tuned.

But don’t forget you can also help YaST, and openSUSE in general, to keep moving. This week we added several ideas for Google Summer of Code projects to the openSUSE mentoring page, including one idea to contribute to YaST. Do you have a better plan for this summer?

See you in less than three weeks, since the next sprint will be slightly shorter due to Hack Week 15.

Highlights of YaST development sprint 29

December 22nd, 2016 by

It’s Christmas time and since (open)SUSE users have been nice, the YaST team brings some gifts for them. This is the result of the last development sprint of 2016.

As you may have noticed, in the latest sprints we have been focusing more and more in making SUSE CASP possible. That’s even more obvious in this last sprint of the year. For those that have not been following this blog recently, it’s probably worth to remember that SUSE CASP will be a Kubernetes based Container As a Service Platform.

But our daily work goes beyond CASP, so let’s take a look to all the highlights.

More improvements in the management of DHCLIENT_SET_HOSTNAME

In the previous report we presented the changes introduced in yast2-network to make the configuration parameter DHCLIENT_SET_HOSTNAME configurable in a per-interface basis.

One of the great things about working in an agile an iterative way, presenting and evaluating the result every three weeks, is that it allows us to detect room for improvements in our work. In this case we noticed some discrepancy in the expectations of Linuxrc and yast2-network and also some room for improvement in the code documentation and in the help texts.

Thus, we used this sprint to refine the work done in the previous one and tackle those problems down.

Improved error message

Ensure installation of needed packages

Another example of iterative development. We already presented in the report of the 26th development sprint a new mechanism to detect when the user had deselected during installation some package that was previously pre-selected by YaST in order to install the bootloader. Since the new functionality proved to work nicely, we decided to extend it to cover other parts of the system beyond the bootloader.

The software proposal now contains an error message including a list of missing packages or patterns, in case the user deselects some needed items.

Warning about missing packages

After clicking the Install button the installation is blocked, the user must resolve the problem either by selecting the packages back or by adjusting the respective YaST configuration (e.g. do not install any bootloader and disable the firewall).

Blocking an incomplete installation

Rethinking the expert partitioner

May we insist one more time on the topic of using Scrum to organize our work in an iterative way? 😉 As our usual readers should already know, we structure the work into minimal units that produce a valuable outcome called PBIs in Scrum jargon. That valuable outcome doesn’t always have to be a piece of software, an implemented feature or a fixed bug. Sometimes a document adds value to YaST, specially if it can be used as base to collaborate with people outside the team.

Our readers also know that we are putting a lot of effort in rewriting the whole storage layer of YaST. That also implies rewriting the most powerful tool known by humanity to define partitions, volumes, RAIDs and similar stuff – the YaST expert partitioner.

It would be great if we could use the opportunity to make it both more powerful and more usable. You can take the first part for granted, but we are not so sure about our UI design skills. That’s why we wanted to have a base to discuss possible changes and alternative approaches with UX (user experience) experts. And we decided that it was worth to invest some time to create a document collecting the state of the art and some ideas for the future and to send that to SUSE experts in UX and to anybody with some interest in the topic.

Here you can find that fine piece of documentation. Take a look to that document if you want to peek into YaST developers’ mind. That’s the kind of stuff we discuss when we are about to start rewriting something… specially something that need to serve hundreds of different use cases.

And of course we would like to know your ideas or thoughts. We usually discuss this stuff at the public #yast IRC channel and at the yast-devel mailing list. But if you prefer so, you can simply open an issue at the repository hosting the document. Whatever works for you.

Rethinking yast2-network

But that was not the only documentation PBI finished during this sprint. Inspired by the first fruits of the storage layer reimplementation, we decided yast2-network also deserves a reincarnation.

As we did in the past with yast2-storage and libstorage, the first step is to collect as much information as possible about what can be currently done with the module and how it behaves in several situations, specially in tricky or complex scenarios. The outcome was three documents, one about the behavior during installation (installation.md), a second one about AutoYaST (autoinstallation.md) and another collecting general features (features.md).

CASP: merged dialogs for root password and keyboard layout

CASP is a product targeted to a quite specific use case with simplicity as a main priority. The installation process has been streamlined to a minimal set of dialogs to configure just the very basic stuff. Among other removed things, there is no step to configure the system language. That can be a problem when entering the root password (the only user that will be created during installation), since the language settings screen is normally also used to select the keyboard layout.

The implemented solution is shown in the screenshot below. As you can see, the keyboard layout and root passwords selections are merged into a single step. As a bonus, we made both widgets more reusable, opening the possibility to place the root password widget or the keyboard layout selection anywhere.

Keyboard layout and root password screen

Storage reimplementation: handling GPT disks in the installation proposal

After several sprints reporting small steps forward, in the 27th sprint we were happy to announce that our testing ISO for the new storage stack was fully installable under certain circumstances. As we reported, it worked in UEFI or legacy systems with the only requirement of having a pre-existing MBR partition table in the disk.

Now we can say it also works with GPT partition tables and even with systems with a mixture of both technologies.

Making the GPT scenario work was much harder that it sounds due to several factors, like the strange way in which parted handles partition types in GPT or some peculiarities in the way the space is distributed in such partition tables.

But now our test ISO can install a fully functional system in the four combinations of MBR/GPT partition table and UEFI/Legacy boot, as it can be seen in the next image.

Storage proposal in several scenarios

The storage reimplementation gets its own openQA instance

But there are better ways than screenshots to prove that something is working, even to prove it keeps working after future modifications. And in (open)SUSE we have one of the best tools for that – openQA.

We have always considered having the new stack tested in openQA as the first big milestone in its development (and we are finally there!) but we are aware that openQA.opensuse.org is already quite busy testing a huge combination of products, architectures and scenarios… even testing releases of openQA itself. Fortunately openQA is free software and can be installed anywhere so we created our own instance of openQA to test YaST stuff, specially the new storage layer.

So far, that instance is hosted in the internal SUSE network, which is enough for us to get continuous feedback about the changes we introduce. In addition to installing the new instance and configuring it to continuously grab and check the latest testing ISO, we had to introduce several changes in the ISO itself with the goal of keeping our tests as aligned as possible with the tests performed in the current Tumbleweed version by openQA.opensuse.org.

For example, we made sure the ISO was properly signed to avoid the need to always pass the insecure=1 boot argument. We also included several packages that were missing in order to make sure the ISO included all the software checked during the so-called MinimalX test and to make sure it shared the look and feel with a regular Tumbleweed, since many openQA checks are screenshot-based.

From now on, we can back every new feature with the corresponding integration tests, something crucial to ensure the quality of a piece of software meant to handle storage hardware.

Making Snapper work without DBus

As you may know, some YaST team members are also the main developers and maintainers of Snapper, the ultimate file-system snapshot tool for GNU/Linux systems.

Normally the snapper command line tool uses DBus to connect to snapperd which does most of the actual work. This allows non-root users to work with snapper.

There are however situations when using DBus is not possible and not being able to work in those situations was limiting Snapper’s usefulness. Now with the latest version all snapper commands support the –no-dbus option. This evolution is worth a blog post by itself… and, of course, we have it. To know all the details check this post at Snapper’s blog.

CASP (and beyond): improved roles

Do you remember the system roles feature introduced during development sprint 16 and improved in subsequent sprints? In case you don’t, let us remind you that system roles allow to define many settings of the installation just by choosing one of the offered roles. That’s only possible, of course, in products making use of that feature, like SLES.

For CASP we will have 3 different roles, as shown in the following screenshot.

CASP system roles

The main difference between these three roles is the selection of patterns to be installed. But apart from that, the Worker role will offer an extra step during installation allowing the user to specify the address of the so-called Administration Dashboard.

Configuration screen for the Worker role

That relatively small detail implied the development of a full new feature in the installer – the ability of a given role to define it’s own specific configuration, including the dialog to interact with the user. As expected from any other installation dialog, you can go back and forward without loosing the entered information. If the user goes back and selects a different role, then this additional dialog is not run again.

That new feature is, of course, not specific to CASP and could eventually be used in other products and roles. Just as a crazy example, openSUSE could decide to introduce a role called “NTP server”, running the YaST NTP server configuration right after the user selecting the role.

Other CASP related features

As already said, we have been focusing quite a lot on introducing features that are needed for CASP. It’s worth mentioning, in case it’s still unclear, that CASP will NOT ship its own adapted version of YaST. All the features introduced in the installer are in fact configurable and available for all other products as well. There is only one YaST codebase to rule them all.

Let’s briefly describe some of the introduced CASP-specific (at least for the time being) features.

CASP always uses Btrfs as filesystem for the root partition. At the end of the installation, the root btrfs subvolume will become read-only. All the other subvolumes will stay as read-write, as shown in this screenshot taken right after rebooting at the end of the installation process.

CASP subvolumes

It makes no sense to update from any existing product to CASP. Thus, CASP media should not show an “update” option when booting, even if it’s still possible for advanced users to pass the UPDATE boot parameter. Since we needed to modify the installation-images package, we took the opportunity to make the “update” option and other settings configurable in a per product basis and we unified SLES and openSUSE packages, so now they share a single branch in the source code repository.

CASP is targeted to big deployments extended all over the world. To make possible the synchronization of geographically distributed nodes, the UTC timezone is enforced in every CASP installation. Thus, we implemented support for products to enforce a given timezone in the installer. Take into account this is different from a default timezone.

Last but not least, it has already been mentioned that the CASP installation workflow will have very few steps. That also affects the screen displaying the installations settings summary. In comparison to a regular SLES, some options must disappear because they are not configurable and some other sections must be added because they are not longer presented as a separate previous step. So far, this is the appearance of the installation settings screen in the current CASP prototype.

Installation settings in CASP prototype

…and a surprise about the blog

We also prepared a Christmas gift related to the blog. The technical aspects are solved, but we are ironing out the administrative details. So you will have to wait until the next sprint report to see it in full glory. But, as the Spanish proverb says, “good things are worth waiting for”.

See you next year

That’s enough to report from our December sprint, we don’t want to bore you with every small bug fix. And talking about things that are worth waiting for, our next report will very likely be published at the beginning of February 2017.

That’s because we will put our Scrum process on hold during the Christmas session. We will restart it on the second week of the year, after the visit of the Three Wise Men. In several countries, it’s a tradition that the Three Kings bring gifts to the kids that have been nice, so let’s expect they bring us some new members for the team!

Highlights of YaST development sprint 28

December 2nd, 2016 by

November is over, Santa Claus elves start to stress and the YaST team brings you one of the last reports of 2016. Let’s see what’s new in YaSTland.

Harder to ignore installation warning

The “installation settings” summary screen usually reports some non-critical errors displayed as a red text. Although the installation can proceed despite those errors, they are usually serious enough to lead to problems. That’s why we decided to introduce a change to highlight them a little bit more, making them harder to overlook.

The following screenshot shows the newly introduced confirmation dialog, presented before proceeding with installation.

Preventing users to shoot their feet

Make DHCLIENT_SET_HOSTNAME configurable on a per-interface basis

But that’s not the only usability-oriented enhancement on this sprint. We also reworked a bit the network configuration dialog.

For home users is very common to use a fixed hostname -set during installation- for our beloved linux box. But in some circumstances it’s better to set the hostname of the machine dynamically using DHCP, something YaST has always allowed to do by just ticking a checkbox that used to be in the network configuration screen. See “Change Hostname via DHCP” below.

The old network settings screen

That checkbox used to modify the system-wide variable DHCLIENT_SET_HOSTNAME, which was fine in scenarios in which only one of the network interfaces was configured via DHCP. But with several network interfaces connected to different DHCP-enabled networks, some problems arose.

During installation, if network configuration is used, Linuxrc creates the ifcfg files with DHCLIENT_SET_HOSTNAME='yes' for all of the enabled or configured interfaces and this value has precedence over the global one.

So the main problem was that YaST only allowed us to modify the global variable and setting it to ‘no’ did nothing because it was enabled for some interface.

During this sprint we have fixed that and now the user interface offers the possibility of choosing which DHCP interface will be used to decide the hostname.

The new network settings screen

Apart from choosing one of the existing interfaces, the new setting can also be set to ‘no’ or to ‘any’. In any case, YaST will always configure the system-wide options and the interface specific ones in a consistent way, so the behavior is always predictable.

But YaST is not the only way of configuring the network, so it’s always possible to have an unpredictable configuration. Fortunately, those potentially problematic scenarios will be detected by YaST and reported to the user.

Detecting dangerous scenarios in network settings

Partitioning in CASP

In the previous report we already explained how are we improving the installer to support the definition of the ultra-streamlined installation process of SUSE CASP, the new Kubernetes based member of the SUSE family.

In this sprint we introduced several additional changes to enable a different partitioning approach, more guided and automatic than ever. In a CASP node it makes no sense to use the advanced settings offered by our storage proposal, like encryption or LVM. Moreover, CASP relies on Btrfs to provide some of its cool and advanced features, like transactional updates.

As a result, although the regular SUSE and openSUSE releases will keep offering all the current possibilities in the same way than ever, in CASP the partitioning step will be skipped and the automatically calculated proposal will be simply displayed in the installation summary.

The new CASP installation summary

Clicking on the proposal will allow to re-target the installation to a different disk (or disks) in a similar way than the regular installer, but the options will be more limited. Again, no easy way to use LVM, encryption, separate home or any file system type other than Btrfs.

Selecting the partitions in CASP, no proposal settings button

The expert partitioner is still available during CASP installation, but using it will show an extra warning, since it implies a much bigger risk than using it in a regular SUSE or openSUSE system.

Expert partitioner warning in CASP

Improved debugger integration

We have improved the Ruby debugger integration in YaST. So far you could start the debugger using the y2debugger=1 boot option or by setting the Y2DEBUGGER=1 environment variable. The new feature allows starting the Ruby debugger also later when the YaST module is already running.

Simply press the Shift+Ctrl+Alt+D keyboard shortcut (D as debug) and it will start the Ruby debugger. It works during installation and also in installed system (just make sure the byebug Ruby gem is installed).

Unfortunately this new feature works only in the Qt UI, the ncurses UI is not supported (currently it does not handle the debugging keyboard shortcut at all).

After pressing the keyboard shortcut the debugger window will pop up:

New debugger integration

Storage reimplementation: it’s alive!

It took us one more sprint than originally expected, but finally we can say the testing ISO for the new storage stack is fully installable.

We fixed the UEFI + MBR partition table scenario we already had almost working in the previous sprint (turns out it was not that broken in Tumbleweed after all) and we adapted yast2-bootloader to be also able to deal with legacy (i.e. no UEFI) booting using the new storage stack.

As a nice result, our testing ISO can be used to install a perfectly functional system in both UEFI or legacy systems with the only requirement of having a pre-existing MBR partition table in the disk. It only shows a couple of error pop-ups related to the calculation of the proposal of software to be installed, but nothing that would prevent you from replacing whatever operating system you have with a new shiny openSUSE-based experiment.

This milestone opens the door to start testing the new stack with openQA, the same system that helps to guarantee the robustness of all the recent SUSE and openSUSE versions.

Storage reimplementation: preparations for the storage proposal

Now that yast2-bootloader starts to be ready to work with the new storage stack in more and more scenarios, it’s time to adapt the only component that still complains during the installation.

In order to make that task doable during the next sprint, we invested some time in this sprint analyzing the interaction between the software proposal calculator and the old storage layer. The outcome was a small document detailing what needs to be adapted in the proposal and in the new stack. The perfect input for a task in the next sprint.

Help for power-users with short memory

Our beloved YaST is packed with magic tricks below the surface. Many of them are very useful to debug installation problems or to better understand how the YaST internals work. Unfortunately developers tend to not be that good at blindly memorizing stuff and the functionality is so well hidden that most newcomers would have hard times finding it… until now.

We have added a couple of new keyboard shortcuts to show a summary of all the advanced hotkeys, so now you only have to remember one key combination instead of a dozen of them. In both text (ncurses) and graphical (Qt) mode, it will be enough to press shift+F1 to get the advanced help displayed below. Since some terminal emulators could already use that combination, ctrl+D F1 can also be used in the ncurses interface as an alternative.

Advanced Hotkeys help dialog

Contributions keep coming!

As we have already mentioned in previous sprint reports, an important part of our daily job as open source developers is helping casual (and not so casual) contributors to bring their ideas and code into YaST and related projects.

This time that (hopefully not casual) contributor was Devin Waas, who wanted to improve the installation to make the life of cloud-lovers easier.

For cloud guys out there retrieving logs of a failed installation is was a huge problem. Now, thanks to Devin, all you need is a running a rsyslog server and you’ll be able to easily access your installation logs from there.

A drawing is worth a thousand words

As a matter of fact, the newest Tumbleweed release allows us to specify the IP address of a remote server from the bootloader through the “Loghost flag”. Linuxrc will take care of setting up a UDP broadcast for dmesg contents and YaST installation logs.

This is just a first step. Devin promised further improvements of our newly implemented remote logging system. And he codes better than he draws, so stay tuned!

Storage reimplementation: LVM-based proposal

As we already mentioned in previous reports, when we started to develop the partitioning proposal we first focused in the scenario of a partition-based proposal with one or several MBR-style partition tables. That looked like the most complex scenario due to the limited number of primary partitions, the alignment problems, the overhead introduced by the EBR (extended boot record) of every logical partition and so on.

A couple of sprints ago, we got that working so we started to work on the LVM-based proposal. It took a little bit longer than expected but now we are able to generate LVM-based proposals for almost every possible scenario. The goal was to have them working in our mocked test cases. So probably the new LVM-based proposal cannot still be used to install a fully functional system, but it is backed by a full load of tests that prove we can handle many situations, from trivial to really tricky ones… and believe us, things can get quite tricky if you mix logical partitions with their EBR overhead and LVM volumes with their PE size rounding and their metadata overhead.

Bugs, bugs, bugs

In this sprint we kept the already commented approach of making the fix of low-priority and small bugs part of the Scrum process. As a result we accounted for approximately 50 deaths of those annoying creatures.

Conclusion

Looking at the report, we could say it was a quite successful sprint. But to be honest we were aiming even higher. Quite some interesting PBIs (features or bug-fixes in Scrum jargon) were almost done at the end of the sprint. But following Scrum philosophy, we never blog about almost-done stuff.

Thus, if nothing goes wrong things will be even better in the next report in three weeks. So have a lot of fun trying the new stuff and stay tuned for more!

YaST Team visits Euruko 2016

November 23rd, 2016 by

As promised in previous posts, we want to share with you our experience and views from this year annual Ruby conference Euruko. Maybe “our” is too much to say, since we only sent one developer there. So to be precise, these are Josef Reidinger’s experience and views on the conference.

This year Euruko took place in Sofia, capital of Bulgaria. It turned out to be a great conference place. Public transport works very well, everyone speak English and even when it uses Cyrilic alphabet, almost everything is written also in Latin one.

That being said, let’s talk about the conference content. Fortunately all the presentations were recorded so you can watch them yourself. But since it would be quite some hours of video to go through, we have reviewed some presentations for you including access to the corresponding videos.

Highlights

Let’s start with the three presentation Josef specially recommend to watch.

Keynote by Matz

He speaks about how Ruby 3 will probably look in distant future. With “distant future” meaning “for sure not in next two years”. If you cannot wait, it’s worth mentioning that Ruby 2.4 will be released on December.

Ruby 3 will use guild membership concurrency model. The most interesting part of the talk is digging into rationale of typed versus non-typed languages and what can be the Ruby future in that regard.

Rules, Laws and Gently Guidelines by Andrew Radev

Interesting view about common design principles, common mistakes when applying them and looking to them from different angles. Also explaining how to handle situations in which several design principles seem to contradict each other.

Elixir by Jose Valim

Interesting intro to Elixir language. What it is, why it make sense to use it and what are its benefits. Josef’s impression was that Elixir’s idea is similar to isolated micro-services communicating via messages, with nice introspection and scalability.

But we have more team members with something to say about Elixir. Like Imobach, who has been playing with Elixir (and Phoenix) for some time now. And Imobach really likes Elixir, so he would like to add some more bits of information for those who are interested.

For example, he would like to highlight that Elixir uses BEAM, the Erlang virtual machine, so great support for concurrency is backed in the platform. Concurrency sits on the concept of Erlang processes and it’s pretty common to use them for all kind of tasks (from computation to storing state, etc.). Imobach would like to encourage all developers out there to take a look to OTP (Open Telecom Platform). Who needs micro-services at all?

Last but not least, take into account that Elixir is a functional language, so if you have an object-oriented mindset (like most Ruby developers) it will take some time to wrap your head around it.

Other presentations

Little Snippets by Xavier Noria

Summary of common inefficiency in small snippets. Small things that matter, although most of them should be already known by the average Ruby developer. (Video)

Since we mention the topic, some YaST team members has found this cheat sheet by Juanito Fatas about Ruby optimization to be quite useful.

Rails + Kafka by Terence Lee

Apache Kafka is yet another messaging system. This talk did not manage to convince Josef to use it, but maybe it makes sense in some scenarios like HPC or HA. (Video)

Graphql on Rails by Marc-Andre Giroux

The typical REST setup is sometimes not scalable enough due to the excess of endpoints. The Graphql language is designed to specify what resources are needed from a server in a single query. The result is returned as JSON and the request specification looks also similar to JSON. Caching is done on client side. Interesting for web stuff and already used by Facebook, Shopify and others. (Video)

Evolution of engineering on call team by Grace Chang

How to maintain services, how to scale when the grow, preventing burnout and so on. Specially interesting for us since there are many similarities with YaST maintenance. Maybe the end of the talk is a bit theoretic and idealistic. (Video)

Sprockets by Rafael Franca

Not specially interesting intro to assets generation used by Rails. People doing some assets generation with Rails would most likely already know all the content. (Video)

Contribute to Ruby core by Hiroshi Shibata

Presentation about Ruby core development infrastructure, rules, etc. Certainly not the best talk ever. (Video)

Consequences of insightful algorithms by Carina C. Zona

Interesting presentation about conflicts between algorithms and real humans, especially with data-mining. Unfortunately, the second half turned to be too emotional and not technical enough for Josef’s taste :). (Video)

Viewing Ruby Blossom – Hamani by Anton Davydov

Introduction to yet another Ruby web framework. Not that interesting for us. (Video)

A Year of Ruby, Together by Andre Arko

Introduction on how the open source community infrastructure behind Rubygems and Bundler is ran. How they get money to improve stuff, how they maintain their servers… Good talk about hard times keeping open source infrastructure alive. Interesting talk for any open source project. (Video)

What I Have Learned from Organizing Remote Internship for Ruby Developers by Ivan Nemytchenko

Talk describing an attempt to scale internship for a lot of students. Josef had a small chat with the author about Google Summer of Code after the presentation. He looked interested. (Video)

The Illusion of Stable APIs by Nick Sutterer

Not Josef’s cup of tea. The presenter probably went a little bit too far trying to be funny all the time. The core of the presentation was about three examples of API that needed to be changed “just” because the rest of the world changed. So the whole presentation can be shortened to one sentence – your API will only remain static if the world remains static. (Video)

Conclusion

That was all from Sofia. See you again in approximately one week, just in time for the report of our 28th Scrum sprint.

Highlights of YaST development sprint 27

November 10th, 2016 by

Another three weeks of development come to an end… and our usual report starts. Take a look to what we have been cooking.

Read-only proposal modules

This week, during SUSECon 2016, SUSE announced an exciting upcoming new product. SUSE CASP – a Kubernetes based Container As a Service Platform.

That has, of course, some implications for the installer, like the need of some products (like CASP) to specify a fixed configuration for some subsystems. For example, an established selection of packages. The user should not be allowed to change those fixed configurations during installation.

We have implemented a possibility to mark some modules in the installation proposal as read-only. These read-only modules then cannot be started from the installer and therefore their configuration is kept at the default initial state.

Software and firewall proposals as read-only

In this sprint we have implemented a basic support in the proposal framework, in the future we could improve the respective proposal modules to better handle the read-only mode.

Per product Btrfs subvolumes handling

The ability to have read-only proposals is not the only improvement we have introduced in YaST to make SUSE CASP possible.

When Btrfs is used during the installation, YaST2 proposes a list of subvolumes to create. Unfortunatelly, that list is hard-coded and it’s the same for every (open)SUSE product… until now.

Starting on yast2-storage 3.1.103.1, a list of subvolumes can be defined in the product’s control file along with additional options (check out SLES and openSUSE examples to learn more).

<subvolumes config:type="list">
  <subvolume>
    <path>boot/grub2/i386-pc</path>
    <archs>i386,x86_64</archs>
  </subvolume>
  <subvolume>
    <path>home</path>
  </subvolume>
  <subvolume>
    <path>opt</path>
  </subvolume>
  <subvolume>
    <path>var/lib/libvirt/images</path>
    <copy_on_write config:type="boolean">false</copy_on_write>
  </subvolume>
</subvolumes>

This specification supports:

  • Disabling copy-on-write for a given subvolume (it’s enabled by default).
  • Enabling the creation of a subvolume only for a set of architectures.

Improved AutoYaST Btrfs subvolumes handling

AutoYaST Btrfs subvolumes handling has been also improved. Using almost the same syntax as for product control files, you can disable the CoW behavior for a given subvolume.

Of course, if you don’t need such a feature, you won’t need to adapt your profiles to the new syntax as it’s backward compatible. You can also mix both of them:

<subvolumes config:type="list">
  <subvolume>home</subvolume>
  <subvolume>
    <path>var/lib/libvirt/images</path>
    <copy_on_write config:type="boolean">false</copy_on_write>
  </subvolume>
</subvolumes>

On the other hand, if you’re running SLES, you’ll know that a subvolume called @ is used as the default Btrfs subvolume. Now is possible to turn-off such behavior in the profile’s general section.

<general>
  <btrfs_set_subvolume_default_name config:type="boolean">false</btrfs_set_subvolume_default_name>
</general>

Disable installer self-update by default

We have talked many times in this blog about the new self-update functionality for the installer. As expected, this functionality will debut in SLE-12-SP2 but with a small change in the original plan. In order to ensure maximum consistency in the behavior of SLE-12-SP1 and SP2 installers, the self-update functionality will be disabled by default. Not a big deal, since enabling it to get the latest fixes will be just a matter of adding a boot option in the initial installation screen.

Storage reimplementation: adapted EFI proposal in yast2-bootloader

The previous report about the status of the storage stack reimplementation finished with the following cliffhanger “we have in place all the ingredients to cook an installable ISO“. So, as expected, we worked during this sprint in adapting the bootloader proposal to the new storage layer. As you can see in the following screenshot, we succeeded and the installer can already propose a valid grub2 setup to boot an EFI system.

EFI proposal with the storage-ng ISO

Does that mean that the testing ISO for the new storage stack is already fully installable? Unfortunately not. Why not, you ask? The reason is, in fact, kind of fun.

The current partitioning proposal only works with MS-DOS style partition tables because we wanted to address the most complicated case first. On the other hand, we intentionally restricted the adaptation of the bootloader proposal to the EFI scenario. And you know what? We found out that combination (MS-DOS partition table + EFI) does not currently work in Tumbleweed, so it neither does in our Tumbleweed-based testing ISO.

We will work during the following sprint to support another scenario. And hopefully we will not choose again an unsupported or broken one. 😉

Letting libYUI run free: first visible steps

As you know, YaST has both a graphical and a textual interface. They run on the same code thanks to an abstraction layer called LibYUI. Originally it served YaST only, but over time other projects started using it, notably the admin panel in Mageia. Moreover, the developers of those projects started to contribute fixes and improvements to LibYUI… faster than we can cope with.

Recently we decided to give the people outside the YaST team more power in the LibYUI project. To make that possible ensuring it does not affect YaST stability, we have been enabling more continuous integration tests.

As a first fruit of the revamped collaboration, we have merged a fix contributed by Angelo Naselli of Mageia regarding selection of tree items. As soon as we complete our continuous integration setup (of course we will keep you informed), more fixes and improvements will come for sure.

More bug squashing and bug paleontology

In the previous report we presented our new effort to integrate the fix of low-priority bugs into the Scrum process. During this sprint we refined the idea a little bit more, distinguishing two separate concepts (each of them with its own PBI) – fixing of existing bugs and closing of too old ones.

The first one doesn’t need much explanation. We managed to fix around 25 non-critical bugs in YaST and if you are using Tumbleweed you are probably already benefiting from the result.

The second task was not exactly about fixing bugs present in the software, but about cleaning bugzilla from bug reports that were simply too old to be relevant any more. Like bugs affecting very old versions of openSUSE that cannot be reproduced in openSUSE 13.2 or Leap. We must be realistic about releases that are already out of support and the limited human resources we have. We closed around 80 of those ancient bugs.

no_country_for_old_bugs

So overall, we cleaned up around one hundred bugs from our queue. Still a long way to have a bug-free YaST, but undoubtedly a step in the right direction.

More coming

We are already working in the next sprint that will hopefully bring several new improvements for CASP, quite relevant progress in the storage reimplementation, several usability improvements, some bugfixes and even some news about this blog.

To make sure you don’t get bored while waiting we are also planning to finally publish the report about our visit to Euruko 2016.

Stay tuned!

Highlights of YaST development sprint 26

October 20th, 2016 by

We did our best to keep you entertained during this development sprint with a couple of blog posts ([1] and [2]). But now the sprint is over and it’s time for a new report.

Squashing low priority bugs

One of the main reasons to adopt Scrum was to ensure we make a good use of our development resources (i.e. developers’ time and brains) focusing on things that bring more value to our users. In the past we had the feeling that many important things were always postponed because the developers were flooded by other not so important stuff. Now that feeling is gone (to a great extent) and we have a more clear and shared view of the direction of our development efforts.

But there is always a drawback. We have accumulated quite some unsolved low-priority bugs. That was an expected consequence, but still it was starting to feel wrong. On one hand, it makes us feel uncomfortable – replying “this will have to wait” so often is not nice, even if it’s for the shake a bigger goal. On the other hand, the amount of low-priority stuff was affecting the signal/noise ratio on Bugzilla, making harder to distinguish the important stuff.

So far, dealing with those low-priority bug was something that each developer did on his own, as permitted by the time dedicated to Scrum. In sprint 26 we decided to make that effort an explicit part of the process and to devote a significant portion of the sprint to it. As a result we closed or reassigned a total of 135 bugs that were just sitting in our list.

Yes, you did read it right. One hundred and thirty five bugs.

Storage reimplementation: our testing ISO can already destroy your data

On the previous sprint we already showed a screenshot of the installer using the new storage stack to calculate a partitioning proposal. Now the installer can go one step further. As you can see on this animation, the changes are now committed to the disk, meaning the system is actually partitioned, formatted and installed.

Installation with the new storage stack

The process is interrupted after installing the software, when trying to configure and install the bootloader. That was expected because yast2-bootloader has still not been adapted to use the new stack. First of all, because we wanted to leave some fun for sprint 27. But also because we used this sprint (26) to document all the requirements of yast2-bootloader in relation to the new storage stack. Now we have in place all the ingredients to cook an installable ISO.

Automatic update of translation files

Recently openSUSE has adopted Weblate to perform and coordinate the translation of the software and the project’s web pages. The openSUSE’s Weblate instance enables everybody (from dedicated translators to casual contributors) to take part in the process and makes possible to coordinate the translations of openSUSE with the ones for SUSE Enterprise Linux, boosting collaboration between the translators of both projects.

As YaST developers, is of course our responsibility to ensure that openSUSE’s Weblate contains always the latest English strings to be translated. Making our developer’s life easier sometimes not only brings advantages for us but also for our users. Until now, after each code change we had to keep in mind to trigger the translation process for every added or changed English text. Sometimes we were not quick enough so that some English leftovers remained in our awesome YaST when being used in one of the 20 languages where the translation is normally 100% complete.

Now we finally set up a Jenkins job to automate the process of triggering the translation update after code changes. This saves the developers some work and makes the update of translations even faster.

Looking at Weblate numbers, you can see we have 20 languages that are about 100% translated, another 20 that are translated more than 75% and 37 languages which are translated less than 75%. So we still need some help to bring all languages to 100% coverage. If you are willing to contribute, why not join our team of translators? Check out the localization guide to get in contact with the coordinators of your preferred language to learn about how to contribute with translations, reviews or by any other mean.

Ensure installation of packages needed for booting

We got some reports of systems not being able to work after the installation in scenarios in which the user had customized the list of packages to install. That happened because, although the bootloader component of YaST pre-selects for installation all the needed packages, the user can override that selection and manually disable the installation of those packages.

To prevent this situation, or at least to increase awareness of it, the installer now alerts in the summary screen (the last step before proceeding to installation) if some of the required packages is missing, as you can see in the screenshot below. We still allow the users to shoot their own feet if they insist, but now we warn them very clearly.

Warning about de-selected Grub2 package

Progress in the low-vision accessibility of the installer

During this sprint, we have been working to make the (open)SUSE installer accessible to people with low-vision impairment. We already blogged about it looking for feedback.

One of the new color modes available in the installer

In a few days, some changes will land in Tumbleweed:

  • Alternative style selection (color and font-sizes). Currently, we offer four options: default (no changes), high contrast (cyan/green/white/black), white on black and cyan on black. Those styles are just a proof of concept in order to test the code changes and, most important, to get feedback from you.
  • A long-standing issue, which prevented to switch to high-contrast mode during installation (shift+F4), has been fixed.

Style selection at the beginning of installation
Although we have made some progress, it is still an ongoing effort and we hope to release more improvements during the upcoming weeks.

Recover from broken bootloader configuration

There are situations in which YaST Bootloader is not able to read the system configuration. For example, when the udev device originally used by Grub2 is no longer available. In the past that leaded to YaST crashes, requiring a manual fix of the bootloader configuration files. Now YaST correctly detects the situation and offers the option to propose a new configuration with correct devices.

YaST bootloader fixing a broken configuration

Disable autorefresh by default in local media

We have changed the default autorefresh flag for the new repositories added by YaST. In the past the autorefresh was enabled for all repositories except CD/DVD media and ISO files.

With the new defaults the autorefresh is enabled only for remote repositories (like http, ftp, nfs,…). The reason is that some local repositories might not be always available (e.g. external hard disk, USB flash drive,…) and the automatic refresh might cause ugly errors when starting the package manager.

Of course, you can still manually change the autorefresh flag after adding a repository if you need a different value.

Note: The default has been changed in Tumbleweed distribution only, Leap 42.2 or SLE-12-SP2 keep the old defaults. The zypper behavior is unchanged as well, it by default disables autorefresh for all repositories. Only repositories imported from a .repo file have autorefresh enabled. See man zypper for more details.

Tons of improvements in network bridge handling

YaST Network is Swiss Army knife for network configuration which comprehends the management of routing, bonding, bridging and many other things. But, to be honest, the management of bridges was not in the best possible shape. It had quite some usability problems and it was not 100% consistent with the way in which bridges are managed nowadays by Wicked in (open)SUSE. Until now!

This pull request with several screenshots and animations tries to summarize all the changes that have been done during this sprint. Like adapting old configuration files to the new conventions or unifying the UI to make it consistent with the one for managing bonding.

Revamped YaST interface for handling bridges

This revamp includes also quite some usability improvements:

  • “NONE” is shown instead of 0.0.0.0 for old bridge configuration.
  • The bridge master is shown in the enslaved interface.
  • The interfaces overview is updated after a bridge is modified.

Optimizing read of hosts file

It was reported that yast2-network was slow in system with a lot of entries in the /etc/hosts file. We took that as an opportunity to test the new profiler support in YaST. The profiler revealed the problem was in some slow calls to SCR, the layer traditionally used by YaST to interact with the underlying system… which sounded like another opportunity. This time an opportunity to expand the use of CFA (the component we are developing to steady replace SCR) and its Augeas parser. Since Augeas already supports parsing of /etc/hosts files, it was quite straightforward to implement that into YaST… and the result is quite impressive.

The time needed to execute the next command in a system containing a huge /etc/hosts with around 10,000 entries (quite an extreme case, we know) was reduced from 75 seconds to just 20.

yast2 lan list

As you can see in this pull request, we also improved CFA itself, greatly reducing the time needed for reading configuration files with Augeas.

That’s all… until next report

Once again, we must conclude the report telling that this was just a small summary of all the work done during the sprint and that we will be back in three weeks with the next report. Or maybe before, now that we are starting to get used to blog more often.

In any case, see you soon and don’t forget to have a lot of fun!

Reducing YaST rebuild time by 30%

October 11th, 2016 by

Here comes the YaST team again trying to flood your aggregator with blog post! Now it’s time for the story of how we reduced the critical path of the rebuild time of YaST RPM packages from 42min 2s to 29min 40s.

Chapter 1: where to optimize

Of course, the first step to start fixing something is finding out what exactly needs to be fixed. In our case, this breaks down into

  1. knowing the dependencies, and
  2. knowing the individual build times.

Dependencies

It is tempting to figure out the dependencies by yourself, by parsing the spec files. But it is hard to do right, and, more importantly, a reinvention of the wheel. The Build Service must know all this to be able to schedule the builds, and provides a convenient way to access it, with osc dependson:

$ osc dependson YaST:Head openSUSE_Factory x86_64
[...]
yast2-x11 :
   yast2-devtools
yast2-xml :
   yast2-core
   yast2-devtools
yast2-ycp-ui-bindings :
   libyui
   yast2-core
   yast2-devtools

Individual build times

For each source package, the Build Service produces not only binary RPMs but also a _statistics file, available in the web UI or via osc getbinaries. We were interested in the total build time, although the data was of limited use because packages can be built on machines with vastly different power and this information is not included.

Chapter 2: how to optimize

Once we knew which screws needed to be tightened, it was time to do it. Fortunately we had more than one tool for the job.

Stop using Autotools

Autotools (automake, autoconf and configure) took up a majority of the time needed for building YaST packages. Now that most of those packages are written in pure Ruby, we don’t need autotools there checking for portability problems that we don’t have. Autotools are a leftover from the times 15 years back when they were the only sensible option. We have wiped them out where possible and have been switching to our own set of Rake tasks.

Stub the APIs used in tests

We run a mixture of unit and integration tests at RPM build time. The downside of this is that we pull in many of the run time dependencies. Fortunately Ruby is a dynamic language and makes it easy to replace interfaces by stubs. That enables us to cut those dependencies.

In fact, we also have some Perl code, notably in yast2-users. Although the stubbing techniques across languages are messier than with pure ruby, they are still effective for our purposes.

Do not build specialized documentation

This one is simple: if the development documentation is only useful for people that will check out the git repo anyway, then leave it out from the RPM.

Appendix: the details

Enough of high-level explanations, we we promised you graphs, code and all kind of gory details, and a promise made is a debt unpaid. So there we go.

Dependency graphs

A picture is worth a thousand words. That’s why we came up with this small tool to generate a graphical representation of the dependencies of the YaST packages. In the resulting graphs displayed below, a node is a source package in the build service, and an arrow means “needs for its build”. Redundant arrows are omitted (that is, we’ve erased an A→C if both A→B and B→C existed).

We can see that the most prominent conclusion is that there is a large number of packages that depend on yast2, a collection of basic libraries.

But on top of that, in the original graph there are 6 more layers, and the graph is not very dense there. After our fixes, there are only 4 layers that are more dense.

Is worth mentioning that the “layer” concept only works if the packages take roughly the same time to build; it would not be helpful if there were huge variations. To get a more accurate picture, we should have generated a histogram of build times. But the graph was good enough in our scenario… and we had to stop the analysis at some point. 🙂

The build dependency graph before our fixes:

YaST dependencies graph (before)

The build dependency graph after our fixes:

YaST dependencies graph (after)

Build statistics

If those graph are not geeky enough for you, here you are the detailed build statistics from the build service

<buildstatistics>
  <disk>
    <usage>
      <size unit="M">1118</size>
      <io_requests>15578</io_requests>
      <io_sectors>2156642</io_sectors>
    </usage>
  </disk>
  <memory>
    <usage>      <size unit="M">580</size> </usage>
  </memory>
  <times>
    <total>      <time unit="s">756</time> </total>         <!-- THIS -->
    <preinstall> <time unit="s">8</time>   </preinstall>
    <install>    <time unit="s">72</time>  </install>
    <main>       <time unit="s">555</time> </main>
    <download>   <time unit="s">4</time>   </download>
  </times>
  <download>
    <size unit="k">33564</size>
    <binaries>53</binaries>
    <cachehits>24</cachehits>
    <preinstallimage>preinstallimage.preinstallimage.tar.gz</preinstallimage>
  </download>
</buildstatistics>

Epilogue

This was definitely an interesting journey. We learned quite some things. Specially we learned that there is still room for improvement, but most likely the time reduction will not pay off for the time invested implementing those improvements.

We have to be realistic and keep working in other interesting stuff to fuel the next sprint report, coming next week!