openSUSE Lizards

Archive for the ‘Factory’ Category

Highlights of YaST development sprint 40

August 10th, 2017 by Yast Team

Doubtlessly, these are pretty exciting times for the YaST team. The merge of the new storage layer into the main codebase is around the corner and we are working on other features that will debut on the next open(SUSE) major release. So let’s summarize what happened during the last sprint.

New storage layer is coming

As you may already know, the YaST team has invested a lot of time and effort preparing our storage layer for the future and we have started to merge the new layer into the main code base during the current sprint. But that’s something for our next report, right? By now, we will just focus on the stuff that got added and fixed during the last two weeks.

Storage reimplementation: BIOS RAID support

libstorage-ng, the low level library in which our new storage layer relies on, got support for BIOS RAID (handled in Linux via MD devices). Now, YaST could take advantage of such a feature to allow the installation of open(SUSE) systems on this kind of devices, including the bootloader.

Storage reimplementation: managing BtrFS subvolumes in new Expert Partitioner

The new Expert Partitioner is getting a lot of attention these days and, during sprint 40, it got initial support for Btrfs subvolumes management.

Now, when you select the BtrFS section in the general menu placed on the left, all BtrFS filesystems are presented allowing you to edit its subvolumes through a dialog which contains the list of subvolumes that belongs to the filesystem. Apart from the usual stuff, like adding and deleting subvolumes, it is also possible to set the noCoW property when you are creating a new one.

However, some features are still missing. For instance the partitioner will not prevent you to create a subvolume which is shadowed by an already existing mount point. Consider the current implementation as the first step towards a really cool Btrfs subvolume handling.

Dropping SUSE tags support

During installation, YaST uses a mechanism known as SUSE tags as source of information for media handling. For instance, a /content file contains information about the product, languages, etc. Additionally, information like release notes or the slide-show texts are stored in the installation media.

Some time ago, SUSE decided to drop SUSE tags and use RPM metadata and packages to store all that information. To make it possible, the installation media would use REPOMD repositories.

Obviously, YaST needs some adaptation. As a first step, support for the /content has been dropped, cleaning up some old and even unused code.

In the upcoming sprints, YaST will be adapted to retrieve licensing, release notes, etc. from RPM repositories and packages, which is also an opportunity to do some refactoring and to improve test coverage.

AutoYaST support for add-on products on same installation media

Nowadays YaST supports having add-on products on the same media than the base product. The problem is that the EULA for those products is displayed too early, even before AutoYaST had been initialized at all.

To solve this issue, now the EULA acceptance of included add-ons is performed at the same time than other add-ons which are not included in the installation media. As a side effect, now the user needs to define those add-ons on the AutoYaST profile in order to handle the EULA acceptance.

Bug squashing and 80×24 terminals

As developers, we enjoy working on new features and, of course, we are committed to fix critical bugs as fast as possible. But there are many small (and annoying) bugs out there that deserve our attention. Additionally, there are several bug reports that are no longer valid (the bug was fixed, it is not reproducible, it is a duplicate, the affected product is not supported anymore, etc.). In order to reduce the list of open issues, the team decided some sprints ago to reserve one day to do some bug squashing.

Among the bugs we closed during this sprint, we would like to highlight a usability problem in YaST services manager. Bear in mind that, along with the graphical interface, YaST ships a text based one which is supposed to fit in good old-fashioned 80×24 terminals. That’s an interesting constraint when you are designing interfaces for YaST.

Needlessly to say that, from time to time, we get a bug report about some element that just do not fit. In this case, YaST services manager had a problem when the service name was too long as you can see in the screenshot below.

Now, if there is not enough space, the name will be truncated and the rest of the information will be shown in an proper way.

Do not miss the next report!

As you may have noticed, a lot of interesting things are currently happening in the YaST world and more cool stuff is about to come. So you should not miss our next sprint report.

By now, enjoy openSUSE 42.3 (you already upgraded your system, right?) and see you in two weeks.

Posted in Distribution, Factory, Programming, Systems Management, Usability, YaST | Comments Off on Highlights of YaST development sprint 40

Highlights of YaST development sprint 39

July 31st, 2017 by Yast Team

openSUSE 42.3 is out! Do you need some reading material while you wait for the download of the new release to finish? Don’t worry, we have the solution right here – another YaST team report. 😉

Several products in one installation medium

Obviously, we stopped adding new features to SLE12-SP3 and Leap 42.3 some days ago, because everything needed to be tested properly before the release. So now we are mainly looking into the future. And one of the plans for that future regarding SUSE Linux Enterprise (SLE) is offering several products packed in a single installation medium.

SUSE offers several mission-specific products based on SLE and, so far, every product needs to be installed from its own medium (usually a DVD or a virtual image). So if you use SLE Server, SLE Desktop and SLE Server for SAP, you have to have three DVDs which is a bit cumbersome.

After some discussions about the technical implementation details, we created a first prototype of the installer with an extra dialog that allows to select one of the detected products and continues the installation from there according to the installation workflow of the chosen product. It is still a proof of concept, but we can at least share screenshots showing how it looks for the time being.

So far, there are no plans to use the new feature in openSUSE, mainly because the project does not deliver separate mission-specific products in the same way than SUSE does with SUSE Linux Enterprise.

Storage reimplementation: numbers after repatriating the Expert Partitioner

In the Sprint 36 report we presented the rewrite of the YaST Partitioner and we have been informing about its evolution in subsequent reports. We told you back then that we decided to split it in a separate yast2-partitioner package. But time has proved that decision to have too many drawbacks so we decided to bring the Partitioner back home, to yast2-storage-ng. As part of the process, we got rid of an old previous prototype of the Partitioner that was still lying in the yast2-storage-ng repository and some code that was there just to support that old prototype.

You may be asking why is all that relevant. It is because that means the repository (and thus the package) is finally approaching the final structure it will have when released into Tumbleweed. And that implies that all the systems we use to automatically measure the quality and reliability of our repositories are now providing trustworthy results… as trustworthy as automatic quality evaluations can be.

And according to those tools:

93% of the code in yast2-storage-ng is covered with automated unit tests in addition to openQA (this number is expected to raise in close future as we polish the new Partitioner),
Code Climate reports a code quality GPA of 3.91 out of a possible maximum of 4
and 76% of all the classes, modules and functions, including the internal ones, are properly documented (with that developer documentation being available here, by the way).

If you wonder about the numbers for the old codebase we want to replace, its code quality is 0.94 and only a 31% of it is covered by unit tests. A perfect example of legacy code.

Storage reimplementation: Btrfs subvolumes in AutoYaST

As reported in previous posts, the new storage stack can already process AutoYaST profiles including partitions, LVM and MD arrays, but some details are still missing. The first of those details we wanted to address was the definition and creation of subvolumes in a Btrfs file-system.

Now it works according to the official documentation – both syntaxes for the <subvolumes> section are supported, it never creates subvolumes that would be shadowed by any other mounted file-system and it uses the list in control.xml as fallback for the root partition if Btrfs is used but subvolumes are not specified.

All that, as usual in the re-implemented stack, with fully tested and documented code.

Storage reimplementation: handle multipath I/O in the proposal

In the previous report we showed you how the support for Multipath I/O looked at the library level, which usually means just geeky graphs. During this sprint, we have taught the installer to use that new library feature, so we now have real screenshots to show!

During the installation, now multipath hardware is detected and the user is asked for activation.

If the user agrees, the installer will never use the individual disk devices to propose a partitioning layout and it will not offer them as an option during the guided setup. The installer always works on the final (compound) multipath device, proposing the correct names for the partitions and so on (which, being a devicemapper device, follows a
different pattern when compared to raw devices).

The resulting system is still not fully bootable because yast2-bootloader has still not been adapted to this scenario. Very likely, something for the upcoming sprint, so stay tuned.

Support for Ruby 2.4

The world changes every day and we are always adapting YaST to remain shiny. The 2.4 version of Ruby is about to land in openSUSE Tumbleweed and is expected to be the default Ruby for SUSE Linux Enterprise 15 and openSUSE Leap 15. We found that some of the YaST packages were not fully ready for this new Ruby, so it was time for some tweaking.

After dealing with quite some details too technical and boring for this blog (but feel free to ask if you want the gory bits), YaST is shining again in Factory, which means we are no longer blocking the adoption of Ruby 2.4 in Tumbleweed.

Add-on Creator and Product Creator

As our team keeps always developing new features, solving bugs, and receiving feedback, we always evaluate our priorities and product. Sometimes, during this evaluation, we see that some YaST modules do not bring enough value or do not shine enough as part of our standard package.

After some evaluation, we come to announce that the modules Add-on Creator and Product Creator will no longer be part of YaST. These packages use Kiwi as backend and we have high competition on UI sides – SUSE Studio and Open Build Service. So it no longer makes sense to have these packages and we recommend for users of these modules to use one of the alternatives or Kiwi directly if you already have an XML definition file for Kiwi.

Adapting YaST to accept 12 digits Service Request Number

As Service Request Numbers can be now composed of 11 or 12 digits, instead of only 11 digits as before, we had to adapt YaST to handle this change. YaST module Support can now accept 11 or 12 digit service request numbers. We implemented such a change for all products dating back from SLE 10 SP3 until the most recent SUSE Linux versions. Updates with this change will be soon released.

Network Setup in the 1st Stage of Autoinstallation

The YaST installation used to have two stages, separated by a reboot. Starting with SLE 12 and openSUSE Leap 42.1 we have eliminated the
second stage. But it was still needed for AutoYaST, controlled by the setting

<profile><general><mode><second_stage>true | false</...>

We have fixed those parts of the networking setup and now you can explicitly set AutoYaST to not use a second stage anymore.

User settings in AutoYaST

An issue that we have found out is that GDM has problems with the system when different users have the same UIDs. If it happens, GDM does not start properly. As a solution, we decided that either UIDs will be defined in the AutoYaST configuration file for ALL users or this tag will not be used at all for ALL users since a mix of both can result into duplicate UIDs.

And we just keep YaSTing!

We hope you liked our report as much as we loved to build all of that. We’ll continue YaSTing so we can reach you again in two weeks with much more cool stuff to show.

By now, enjoy your openSUSE 42.3 and all the cool features that came with it!

Posted in Distribution, Factory, Packaging, Programming, Systems Management, YaST | 3 Comments »

Highlights of YaST development sprint 38

July 14th, 2017 by Yast Team

Here we go again with a new report from the YaST trenches. This time with the storage reimplementation as the clear star of the show.

Storage reimplementation: the proposal adapts, you succeed

As we have announced in our previous sprints and as you probably already know, the YaST team is working hard to rewrite the whole storage stack on time for SLE15 and openSUSE Leap 15. As part of this reimplementation we have designed a brand new storage proposal that automagically offers the user the best combination of partitions and LVM volumes based on the current configuration of the system and the user preferences.

When we are working with very small disks or with special technologies like DASD (which doesn’t accept more than three partitions by device), the storage proposal might not be able to generate a valid initial proposal honoring the initial requirements of the product (e.g. creating a separate home partition and enabling btrfs snapshots for the root partition in the openSUSE Leap case). Now the proposal is not limited to fail when it is not possible to satisfy the default product requirements. Before giving up, the new system looks for alternatives, like discarding the separate home partition or disabling snapshots. Moreover, now the proposal is able to automatically adjust the size requirements not only for root, but also for swap and home. And, of course, the guided setup continues there for fine tuning the proposal settings.

Desktop selection improvements

As our usual readers also know, we recently introduced a more fair desktop selection screen for openSUSE, both Leap 42.3 and Tumbleweed. We used part of the latest sprint to implement some feedback we gathered about the wording and behavior of that dialog.

That feedback gathering included some discussions on how to make user experience nicer after selecting one of the user interfaces available through the “custom” option. As a result, the awesome openSUSE crew created a new mechanism for selecting the default window manager on each graphical login, so YaST can delegate the details to the maintainers of those alternative interfaces.

How everything works now? Glad you asked. 🙂

If the user select KDE or GNOME in the YaST dialog, /etc/sysconfig/windowmanager is configured to point to that desktop by default. If the “custom” option is selected, then YaST does not enforce any interface in that file and the new mechanism comes into play. It relies in the default.desktop file, which defines the default window manager and can be managed by the common update-alternatives workflow. Meaning it can be easily tweaked by the package maintainers and by the users, specially since YaST includes a nice module for managing alternatives.

Storage reimplementation: improvements in the expert partitioner

Although, as explained above, we keep improving the storage automatic proposal to support more and more situations, we cannot ignore that flexibility and adaptability have always been two of the flagships of (open)SUSE. And one of the most prominent examples is the YaST Expert Partitioner.

As detailed in our report of the sprint 36, we have been rewriting that powerful Swiss Army knife using the new storage stack but keeping the same user interface and functionality. So far, the new implementation was only able to display information about the existing partitions, LVM systems and MD RAIDs. But now we added many options to create, edit and delete partitions.

It is still a work in progress because the number of possibilities offered by the YaST Partitioner is sometimes overwhelming and implementing them all takes time, but it’s progressing nicely.

Beside the improvements in the Partitioner itself, we also worked on its integration in the installation workflow. Now the Expert Partitioner can be used to refine the schema automatically proposed by the installer. As a bonus, the behavior of the “abort” and “finish” buttons has been improved in relation to the Expert Partitioner currently available in (open)SUSE, which historically shows a usability inconsistency there compared to the rest of the installation process.

Fixed Automatic Patch Installation

In both SLE and openSUSE Leap, the online updates can be installed either manually or automatically at some regular intervals. For the automatic installation we provide the yast2-online-update-configuration package which provides a cron job script and an YaST module for configuring it (hint: it is not installed by default, you might give it a try, maybe it is something “new” for you).

You can configure how often the patches should be installed or filter the patch categories in the YaST module, but we got a bug report saying that when multiple patch categories are selected only one is actually used.

It turned out to be a trivial mistake in the cron job and we fixed it for SLE12-SP2 and Leap 42.2, as well as for the upcoming SLE12-SP3 and Leap 42.3. So if you use this module and want to use the category filter then it’s recommended to upgrade the package.

Storage reimplementation: many steps forward in the AutoYaST integration

And going back to our new storage stack, we keep working to integrate it better with other parts of YaST, specially AutoYaST. During this sprint we polished some rough edges and we added support for MD RAID. With all that, now is possible to automatically setup a system based on an AutoYaST profile containing any combination of partitions, LVM systems and MD arrays, including encryption at any of the levels.

But the relation of AutoYaST with the system works in both directions. Apart from being able to install a system based on an AutoYaST profile, it also offers the interface to export the current system configuration, including the storage layout, to a profile in order to reproduce the system later. During this sprint we also ported that logic to rely on the new storage layer.

It was harder than it sounds, due to the need of keeping the backwards-compatibility with several behaviors that have been introduced along the AutoYaST history to adapt to several specific situations. On the bright side, the new code is easier to follow, includes behavior-driven automated tests (RSpec) and contains information about the rationale of each decision… which in some cases required some archaeology.

Storage reimplementation: fixed bootloader proposal in S/390 and PowerPC

Another part of YaST we are constantly working to integrate better with the new storage stack is yast2-bootloader. Although the new storage system was already able to correctly setup a valid disk layout for most situations and architectures (each one with it’s own requirements for booting), our bootloader module is still not fully compatible with the new system in all those scenarios.

During this sprint, we adapted it to ensure all the combinations suggested by the new storage stack (partitions, LVM, encryption and so on) are correctly covered by YaST2-Bootloader. As a result, we can already say that our testing ISO images are fully installable in any x86_64, PowerPC and S/390 system by just clicking “next” a few times. And we have automated integration tests (a separate openQA instance) to ensure the resulting system boots just fine.

UDEV device id on PowerPC

We know some of our readers enjoy our more technical posts and like to lurk into the kitchen to see how we deal with all kind of surprises maintaining a complex tool like YaST. Today’s chapter in that regard started with a bug report about the bootloader being installed in the wrong device name (/dev/vda instead of /dev/vdb) in an emulated PowerPC machine in openQA.

After a lot of investigation and with help from our PowerPC expert, we found the culprit, that turned out to be an emulator quirk. The next couple of paragraphs may be interesting or daunting, depending how much virtualization and PowerPC jargon you know. Be warned.

On POWER, the PReP partition containing the bootloader has no unique identifier other than the serial number of the disk on which it created. QEMU virtualization does not provide any disk serial number when the user does not explicitly specify one. This means that the PReP partition in QEMU installation does not have any unique identification and the partition name may change when a disk is added or removed from the virtual machine or the storage configuration otherwise changes. This may lead to system errors related to bootloader installation and updates.

It is recommended to assign a unique serial number to each disk in a QEMU virtual machine on POWER when it is expected the storage configuration of the virtual machine may change. Otherwise, there is nothing YaST or any other tool running within the virtual machine can do to avoid the problems. So this time we only did the investigation part, with the fix coming from the openQA side, which was improved to explicitly set serial numbers when needed.

Storage reimplementation: better support for advanced scenarios

As exposed above, our StorageNG testing image already works in all the supported architectures and in scenarios combining plain partitions, LVM, RAID and encryption in any way. But there are even more situations and technologies currently supported by YaST that we need to incorporate into the new stack.

First of all, we used this sprint to add Multipath I/O support to the new libstorage. Now it can also be combined with all the other mentioned technologies (like having an LVM system on top of an encrypted multipath device), although the storage proposal still needs to be adapted to play nicely with preexisting multipath setups.

As usual with the library stuff, the best “screenshot” we have to offer is one of its geeky autogenerated graphs.

Another scenario that goes beyond the most regular use cases is installing the system into a network storage device, instead of a local hard disk. Now, the new storage system can report whether a root filesystem via a network is used. When that happens, YaST sets the network interfaces with the start mode nfsroot, which is used to avoid interface shutdown and, therefore, the unavailability of the system.

That’s all, folks!

Once again, we omitted the boring parts about bugfixing (with yast2-ntp-client being the star in that regard) and similar stuff. We hope you enjoyed the report and we hope to reach you again in two weeks. Meanwhile…

Have a lot of fun testing the Leap 42.3 pre-releases and reporting bugs!

Posted in Desktop, Distribution, Factory, Packaging, Programming, Software Management, Systems Management, YaST | 1 Comment »

Highlights of YaST development sprint 37

July 3rd, 2017 by Yast Team

Since we announced in the latest report, we decided to shorten our development sprints from three to only two weeks. As a natural consequence, this is the first report of a series of shorter ones. But shorter doesn’t have to mean less juicy! Keep reading and enjoy.

Displaying very long changelog

We got a bug report about YaST not responding when a very long package changelog was displaying in the package manager. It turned out that some packages have a huge change log history with several thousands entries (almost 5000 for the kernel-default package). That produces a very long table which takes long time to parse and display in the UI.

The solution is to limit the maximum number of displayed items in the UI. You cannot easily read that very long text anyway, for such a long text you would need some search functionality which the YaST UI does not provide.

Finding the limit, that magic number, was not easy as we want to be backward compatible and display as much as possible but still avoid that pathological cases with a huge list.

In the end we decided to go for a limit of 512 change entries. The vast majority of packages have way fewer entries, so you should not notice this clipping functionality. When the limit is reached a command to display the full log is displayed at the end so you can easily see the missing part when needed. (Hint: the widget supports the usual copy&paste functionality, you can copy (with Ctrl+C) the displayed command and paste it into a terminal window directly.)

Storage reimplementation: MD RAID support in the rewritten partitioner

In the previous report we told you we are rewriting the YaST partitioner to use the new storage stack and modern reusable CWM widgets under the hood while retaining exactly the same behavior and look&feel on the surface. We are reimplementing one feature at a time, and this sprint it was the MD RAID’s turn.

Now the partitioner displays current RAIDs, with details about them and the devices used to construct each RAID. If a picture is worth a thousand words, here you have 3,000 words:

No, you can’t have a separate partition for /var/lib/docker for CaaSP – so here you have it

Our brand new containers-oriented solutions, SUSE CaaSP and its openSUSE counterpart Kubic, need to have /var/lib/docker as a separate partition for several reasons. It was a separate Btrfs subvolume already, but that wasn't quite separate enough. 🙂

The problem was just that the automated storage proposal in the old YaST storage subsystem is not prepared for anything like this; it can deal with root, swap and optionally a separate home partition (or volume if using LVM). That's it. Extending the current syntax of the control.xml file to be able to specify arbitrary partitions and adapting the code of the old proposal to understand and handle this new specification was unfortunately almost impossible. Sadly, we have to admit the old code is hardly maintainable these days and not flexible enough to accommodate this kind of changes in a safe way.

This is one (out of many) reasons why we are currently in the process of rewriting that entire YaST storage subsystem, as you already know from many previous posts in this blog. But, as you also know, the new system will debut in SLES15 and openSUSE Leap 15.0, too late for the current SUSE CaaSP and openSUSE Kubic.

We decided we'd introduce a hack based in the old proposal, well knowing that hacks accumulated in code can develop their own life just like Dust Puppy. But we plan to kill that hack immediately once StorageNG arrives.

So the hack was to simply use the logic for the separate home partition and repurpose it, keeping all the respective parameters in control.xml and introducing yet another one called home_path where the actual mount point for that partition can be specified — in this case /var/lib/docker. The tradeoff is that there can be no separate /home anymore in parallel to that.

That "feature" should not be used outside of that very specific use case in CaaSP and we even considered the possibility of not documenting it too publicly to avoid misuse. But we are living the open source spirit and whatever we do, we do in public. Even if it's the (quite embarrassing) fact that we consider changes to certain parts of our own code too risky. But again, that's why we are pushing the storage layer reimplementation (Storage-NG) so hard: we want to regain control over that part.

Storage reimplementation: custom partitioning with AutoYaST

And talking about the new storage layer and our previous posts, you already know we are working hard to integrate it with AutoYaST. For the time being, custom partitioning layouts are supported, but only using plain partitions and LVM. Other features, like RAID or Btrfs subvolumes support, are still missing.

A nice thing about the new code is that it relies as much as possible on the new storage layer. On older versions, AutoYaST implemented some logic on its own and that caused some unexpected troubles. Fortunately, that is not the case anymore, and the new code looks way easier to extend and maintain.

YaST does not write directly in `/etc/vconsole.conf` anymore

When configuring the system keyboard, YaST used to write the keyboard map configuration directly in the /etc/vconsole.conf file. However, this approach is no longer appropriated since it may cause undesired effects to other tools. Now YaST uses the Systemd tool localectl to set the keyboard map in /etc/vconsole.conf, instead of writing in it directly. Another step to make YaST a good citizen of the Systemd world.

Storage reimplementation: named RAID arrays

If you use MD RAID arrays you probably know there are two ways of identifying them – by number or assigning a meaningful name to them. Named arrays use device names like /dev/md/<name> instead of /dev/md<number>.

During this sprint, we taught the new libstorage how to create and manage named RAID array, in addition to the already supported numbered ones. If the user decides so, the MD RAID name is used in fstab instead of the UUID (which was the only option with the old libstorage). We also made sure to improve the behavior in several scenarios, so we consider some bugs of the old storage to be fixed (or obsoleted, if you prefer) with storage-ng.

Linux also supports names of the form /dev/md_<name>. The new library is also able to handle this format, but the feature is intentionally disabled and documented to be unsupported because other parts of the system could not be 100% verified to work in that scenario. And we take quality assurance very seriously before labeling a feature as “supported”.

If you are not happy enough with the screenshots showing the RAID support in the partitioner, here you have more pictures. But, as usual with stuff implemented in the library, here “pictures” doesn’t mean screenshots, but fancy automatically generated graphs.

Stay tuned

Of course there are a lot of other things we did during the last two weeks, although some of them were considered not interesting enough for this report or were not finished on time. We are already working in finishing the unfinished stuff and implementing new exciting improvements. And the bright side is that you only have to wait two weeks to know more… so stay tuned.

Posted in Distribution, Factory, Programming, Software Management, Systems Management, YaST | Comments Off on Highlights of YaST development sprint 37

Highlights of YaST development sprint 36

June 16th, 2017 by Yast Team

We are still digesting all the great content and conversations from openSUSE Conference 2017, but the development machine never stops, so here we are with the report of our post-conference sprint.

Storage reimplementation: expert partitioner

You have been reading for months about the new stack for managing storage devices and the new features and improvements it will bring to the installation. But so far there was no way to view and fine-tune the details of those devices. During this sprint we have implemented a first prototype of the new version of the YaST2 Expert Partitioner, that awesome tool you can invoke with yast2 storage.

To make the transition easier and to be able to submit it to Tumbleweed as soon as possible (hopefully in a couple of months, together with the rest of the new stack) we decided to postpone any UI redesign. So this first incarnation of the new expert partitioner looks and behaves exactly like the one available in current versions of (open)SUSE.

To try it out (on a scratch machine!), add a repository and remove the current storage library, as described in yast-storage-ng: Trying on Running System and then run zypper install yast2-partitioner. As you may have noticed, we split the partitioner in a separate package, unlike the current version that was part of the basic yast2-storage.

The new expert partitioner will only give you a read-only view of things similar to the following screenshots, not being able to modify anything yet.

As you can see in your own system or in the screenshots, the following items are already functional

Hard disks and their partitions
Volume Groups, Logical Volumes, and Physical Volumes of the Logical Volume Manager (LVM)

The other kinds of devices that you can see in the navigation tree are so far only stubs.

You may feel a bit underwhelmed by this, and that’s OK, because most of the effort that we spent on this is actually hidden in a set of nice UI classes which we use to reconstruct the legacy procedural UI code. So the new expert partitioner not only relies on the revamped storage stack, but also on a powerful and reusable set of shiny UI components. If you ever need to code a user interface for YaST, the next section is for you.

New CWM Widgets

This section may be a little bit too developer-oriented, so feel free to skip it if you don’t care about the YaST implementation details. If, to the contrary, you want to have a glance at the new YaST widgets, go ahead.

Before diving into the new widgets, let us introduce what CWM is. It stands for Common Widget Manipulation and it is an old procedural YaST module which puts together a widget, its help and its callbacks. These callbacks are used to initialize, validate and store the content of the widget. This organization allows easier re-usability of widgets, which are then put together into a dialog. We also made an object-oriented version of CWM, which uses the old one under the hood, but is based on classes. So the contents and callbacks all live in their own class which is then used in dialogs. It is already used e.g. in the bootloader module.

As part of the Expert Partitioner rewrite, we created new types of reusable widgets, like Table or Tree, that are now available for its usage in any YaST module.

We also realized that it would be cool to be able to construct full dialogs out of smaller “bricks”, because the partitioner dialogs usually have rather complex structures in which some parts are shared by several dialogs. For this purpose we added new kinds of widgets – a Page which represents a part of a dialog that contains other widgets, and a Pager which allows switching of pages. So far there are two different pagers. The first one is Tabs which shows a set of tabs and allows switching among them and the second one is TreePager which allows switching pages according the item selected in a tree.

As you can see in the screenshots from the Expert Partitioner, there is a tree on the left side, which decides which page is shown on the right side. That right side sometimes contains a set of tabs, which decides what is displayed for every single tab.

Building blocks for the win!

Added support for allocation of memory high into YaST Kdump Command-line

A new option to allocate memory high during enable of Kdump was already implemented in YaST interface but unavailable through command-line. From the next Service Pack (i.e. SLES 12 SP3, Leap 42.3, and Tumbleweed), the user will be able also to use this option in command-line and scripts. In order to do that you can just use the command yast2 kdump enable alloc_mem=low,high, where low sets Kdump Low Memory and high sets Kdump High Memory.

For current users of Kdump command line, the old command to enable kdump yast2 kdump enable alloc_mem=$mem will still work as before, keeping its compatibility.

Handle optional filesystem packages correctly

During installation, when YaST detects in the system a particular filesystem or technology for which the installer would need additional packages to deal with, it alerts the user and tries to install those packages. A very visible case are the ntfs-3g and ntfsprogs packages, installed when a MS Windows partition is found in the system.

But, what happens if those packages are simply not available for installation? That’s the case of SLE12-SP3, which doesn’t include ntfs-3g. Should the installer block the installation of SLE12-SP3 alongside an existing MS Windows just because of that?

Fortunately we have solved that problem for the upcoming SLE12-SP3… and also created the code infrastructure to avoid similar problems in the future. Now we have a separate list for packages that would be nice to have installed in order to deal with a particular technology but that are not 100% mandatory to the point of blocking the installation process if they are not available. So we don’t bother the user about things that cannot be solved anyway.

Issues solved in YaST Remote command-line

But apart from looking into the future, we keep taking care of the existing YaST modules and its supported scenarios. During this sprint, we also addressed some issues related to YaST Remote, when using the command line.

The command yast2 remote list was installing required packages for YaST Remote and also restarting the display manager. However, as this command is expected to be a read-only operation, it shouldn’t change anything in the system. Such a problem was solved and now this command just lists the status of remote options.

Another issue was in the command yast2 remote allow=yes, which was opening a pop-up interface to alert the user about the changes in the system. Such a pop-up was impeding the use of this command in scripts. Therefore, we removed it when executing YaST Remote in command-line and, instead, we now just show a warning message on the console.

Both fixes were submitted as a maintenance update to all the supported versions of SLE and openSUSE and will reach our user as soon as they pass all the extra security checks performed by the respective maintenance teams. Of course, both fixes will also be included in future releases.

Storage reimplementation: simplified actions summary

The Expert Partitioner was not the only thing we did related to the new storage stack during this sprint. We also tried to improve how the information is presented to the user everywhere.

Having a huge amount of information at a glance might be useful in certain cases… as long as that amount can be handled by a human brain! Since we don’t expect all our users to be androids, we decided to improve our storage actions summary. Now is much easier to understand what is going to happen in the disks after pressing the confirmation button.

They say a picture is worth a thousand words. So let’s compare the ultra-detailed list offered before this sprint…

…with the new digested one.

As you can see, the new summary carries the essential information in a clear and legible way. Delete actions are highlighted in bold and, moreover, the set of actions related to btrfs subvolumes are grouped in a collapsible list.

Integration of AutoYaST with the new storage has also received our attention during this sprint. Now, the summary dialog in AutoYaST shows the list of storage actions in the new compact way. Currently it is not possible to edit partitions from this AutoYaST dialog, but stay tuned for more information in upcoming sprints.

AutoYaST: warn the user when creating smaller partitions

You already know how powerful can AutoYaST be in terms of automating complex installations based on flexible profiles, even trying its best if the profile contains parts that are challenging to implement in the target system.

One of those adjustments that AutoYaST can perform is reducing the size of some of the partitions specified in the provided profile if the target disk is not big enough, to make sure the installation doesn’t get blocked just by some missing space.

The mechanism works very well but that kind of automatic adjustments can be unexpected and can produce undesired results. That’s why we have added the following warning message.

Of course, this new warning uses the usual AutoYaST reporting mechanisms, so even if the users are not in front of the screen (something very common when performing an unattended installation) they will be notified about the special circumstance.

Docker, Docker everywhere!

And now, another dose of technical content for those of you that love to lurk into the kitchen.

In the report of the sprint 30 we already described how we adopted Docker to power up our continuous integration process in the master branch of our repositories (the one in which we develop Tumbleweed and upcoming products). As also reported, we adopted the same solution for Libyui in the next sprint. And now it was the turn the branches of YaST that we use to maintain already released version of our products. Not a trivial task taking into account the many repositories YaST is divided in and the many products we provide maintenance for.

If you want to refresh your memory about the whole topic of using Docker for the continuous integration infrastructure, here you can watch the talk Ladislav offered about the topic a few days ago in the openSUSE Conference 2017.

Storage reimplementation: full support for DASD devices

If you don’t have a S/390 mainframe laying around, maybe you are not familiar with the concept of DASD (direct-access storage devices). DASDs are used in mainframe basically as regular disks… just that they are not.

DASDs are special disks in various aspects – they have a different partition table type allowing only three partitions with a restricted set of partition ids, they must be managed by a different set of partitioning tools, they have their own specific alignment logic and requirements…

But thanks to YaST and libstorage, in (open)SUSE you don’t have to care about most of those details. The expert partitioner and the installer allow you to treat DASDs almost as regular disks.

During this sprint we adjusted the new libstorage, i.e. the library C++ based layer of the stack, to be able to deal with DASD. As usual with new features implemented in the library, the only “screenshot” we have to show is one of the graphs generated by the library. Enjoy.

More to come… very soon

We want to have a shorter and more agile feedback loop regarding our development efforts. To achieve that, we have decided to shorten our Scrum sprints from the current three weeks to just two. So you will have more news from us in half a month.

But a feedback loop works in both ways, so we also expect to have more news from you. 🙂 See you soon!

Posted in Distribution, Factory, Miscellaneous, Programming, Systems Management, YaST | Comments Off on Highlights of YaST development sprint 36

Highlights of YaST development sprint 35

May 25th, 2017 by Yast Team

openSUSE Conference 2017 is coming! And as we flight there (literally, one third of the YaST team is in a plane right now typing this), we wanted to inform our beloved readers on what we did in the previous three weeks.

So here is our report, brought to you by airmail!

Bugfixes, bugfixes everywhere

Leaving openSUSE Tumbleweed aside, The YaST team is currently working to deliver SLE12-SP3, openSUSE Leap 42.3, SLE15, openSUSE Leap 15, SUSE CaaSP 1.0 and Kubic (more about Kubic later). Three of them are already in beta phase, which means they are being extensively tested by several parties and in many scenarios, hardware platforms and possible configurations. That amount of manual testing always result in several bug being discovered, no matter how much we try to have some automated tests for the most common cases.

Many of the bugs our testers are finding are related to internationalization and localization, mainly texts in the UI that are always displayed in English, despite the system been configured (or being installed) in a different language.

But, of course, other kind of bugs are also being found. For example, our hardware detection component (hwinfo) was not able to deal with some new machines, making the installation experience everything but pleasant.

As a result, a significant amount of the YaST team manpower during this sprint was targeted to squash those annoying bugs. Which doesn’t mean we didn’t have time for some interesting new features and improvements.

Storage reimplementation: unlock encrypted devices

Once again, our new storage system comes with news. Now it’s able to detect and unlock preexisting encrypted devices during the hard disks probing step, raising you a new pop-pup dialog to ask for the corresponding device password. After unlocking the devices, all your installed systems will be accessible for upgrade and, moreover, the LVM volumes allocated over encrypted devices will be activated.

The new storage stack is expected to debut in SLE15 (and, thus, openSUSE Leap 15), but the functionality can already be tested, for both the installation and upgrade processes, with the StorageNG test ISOs.

The storage reimplementation & AutoYaST – a love story

But the happiest news coming from the new storage stack during this sprint is it’s marriage with AutoYaST. The new automatic partitioning proposal (that is, the “Guided Setup”) is now integrated with AutoYaST.

Thanks to the new software architecture, AutoYaST users will be able to override every single partitioning setting from the control file.

<profile xmlns="http://www.suse.com/1.0/yast2ns" xmlns:config="http://www.suse.com/1.0/configns">
  <general>
    <storage>
      <!-- Override settings from control file  -->
      <try_separate_home config:type="boolean">false</try_separate_home>
      <proposal_lvm config:type="boolean">true</proposal_lvm>
    </storage>
  </general>
</profile>

So you can easily switch on/off LVM, use a separate partition for /home, enable/disable snapshots, enable/disable Windows resizing, etc. All that, still relying on the automated storage proposal to iron the details up. Something that is not possible with the current version of AutoYaST without being forced to define explicitly every partition and LVM volume.

But the simplest way to use the new libstorage proposal is to not define any setting at all in the AutoYaST configuration file. In that case, the partitioning proposal code will do the complete job, installing a new system with the default options.

Of course, before integrating the new storage stack into the upcoming SLE15, the AutoYaST support have to go one step further. Apart from using and configuring the proposal, it must be possible to define a completely custom setup including partitions, LVM volumes, software RAID devices and so on through the corresponding <partitioning> section of the AutoYaST profile. So we used this sprint to sketch a plan to make that possible in the following months, analyzing all the scenarios and configurations supported by AutoYaST and looking for the best way to support them using the existing yast2-storage-ng infrastructure. The outcome of that effort is this detailed document and a list of tasks (PBIs in Scrum jargon) for the upcoming sprints. So be prepared for more news in this regard.

Automatic Cleanup of Snapshots created by Rollback

So far the user had to ensure that snapshots created by rollbacks got deleted to avoid filling up the storage. This process has now been automated. During a rollback, Snapper now sets the cleanup algorithm to “number” for the snapshot corresponding to the previous default subvolume and for the backup snapshot of the previous default subvolume. This enhanced behavior will be available in SLE12-SP3 and openSUSE Leap 42.3. For more information take a look at the more detailed post in the Snapper blog.

Helping to bring the CaaSP fun to openSUSE

For several sprints already we have been presenting features targeted to SUSE CaaSP, the Kubernets-powered solution for managing containers. Many of those features and custom configurations live in a package called yast2-caasp, originally targeted to this great upcoming product built on top of the SLE12-SP2 codebase.

But now the package is also available for Tumbleweed-based systems by request of the Kubic project. Kubic will be the openSUSE alter ego of SUSE CaaSP, that is, a Container as a Service Platform based on openSUSE and Kubernetes. As with any other YaST component, the exact same source code will shared by the SUSE product and its openSUSE brother.

Improved UX when an invalid registration URL is provided

Humans make mistakes, but when the mistakes are made entering some option in
the installation command line, it usually means that a reboot of the machine is be needed to fix them.

That was the case for the registration URL (regurl) option. In the provided address was malformed the installation just stopped. During this sprint we have added an early check of that URL which allows the user to reenter it and continue with the installation. Something that obviously improves the user experience.

In case of an autoinstallation (AutoYaST), the error is reported and the steps to get installer updates and to register the system are skipped.

There is still room for more improvements, allowing the user to also modify the URL in other scenarios. For example, for an URL with a valid format but that points to an unreachable server. But in those cases is not so straightforward to identify the culprit of the problem. It would make no sense to annoy the user with a recurring pop-up to change the registration URL if the root of the issue is not the URL but a incorrect network configuration.

Translations and Interpolations

As mentioned at the begining of this post, we recently got quite some bug reports about missing translations. Although some of them were really caused by bugs in the YaST code, others were a consequence of a buggy Ruby rxgettext script which collects the translatable strings from the Ruby source code. The bug is known by the Ruby-GetText developers, but it’s unclear when (or whether) it will be fixed.

The problem is that the tool cannot collect the translatable strings from interpolations. For example it cannot find the “foo” string from this string literal: "#{_("foo")}". As a result, that string is missing in the resulting POT file and cannot be translated by the SUSE or openSUSE localization teams.

As a workaround, we fixed the YaST code to not use the translations inside interpolations. We also documented the possible problems when mixing translations a interpolations and their solution.

And talking about new developer oriented documentation…

Security Tips for YaST Developers

YaST runs with the administrator privileges (root) and therefore we have to be aware of the possible security issues in the code. During this sprint we published a document with a short summary of security tips for YaST developers.

If you are programming an YaST module you should definitely read it, but it might be interesting also for other programmers as many mentioned issues are generic, not tight only to YaST.

The document is available online here.

See you at the conference

That’s all for this sprint report. We have many more things in the oven, be we didn’t manage to finish them during the sprint, so they will have to wait for the next report. Meanwhile we hope to see many of you at the openSUSE Conference 2017. There will be a whole workshop about modern YaST development, a summary with the more relevant news in the last year of YaST development, talks about the new superb yast2-configuration-management module, about our continuous delivery infrastructure and about how we use Docker to deliver YaST… And, of course, also many other interesting content like the awesome presentation from Thorsten Kukuk about the brand new openSUSE Kubic we mentioned earlier. And even more important, a lot of fun!

For those of you that cannot attend to the conference, see you again in this little corner of the internet in three weeks!

Posted in Distribution, Documentation, Events, Factory, Localization, Programming, Systems Management, YaST | Comments Off on Highlights of YaST development sprint 35

Highlights of YaST development sprint 34

May 3rd, 2017 by Yast Team

Here we go again! Only one week after our previous report, we already have a new bunch of (hopefully) exciting news. Let’s take a look to the outcome of our 34th Scrum sprint.

Trusted boot support for EFI

In the report of our 19th sprint, we already presented the new (at that point in time) and shiny Trusted Boot support in YaST2 Bootloader. So far, the only supported scenario was legacy boot (i.e. no UEFI) on x86_64 systems. Now, thanks to TPM2, is also possible use Trusted Boot with EFI, so we added support for it in our beloved bootloader module.

So now YaST Bootloader looks the same in non-EFI and EFI variants, no matter which underlying technology is actually used. Of course, YaST is only the tip of the iceberg, booting in Trusted Boot with EFI is possible thanks to all the tools that has recently added support for TPM2. openSUSE developers and packagers rock!

Configuring the NTP service in CaaSP

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

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

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

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

Storage reimplementation: improvements in the guided setup

Through the previous reports, you have been able to follow the evolution of the renovated guided setup for the partitioning proposal. This sprint is not different, we have improved and adjusted that new wizard even further, making it smarter and more usable.

The new version is able to decide which steps to show depending on the current scenario. For example, in systems with only one disk the whole disk selection dialog will be skipped. The steps are also simplified by disabling widgets that are not applicable to the current situation. For example, if there is no previous Linux installation, the question about what to do with the existing Linux partitions will be disabled.

And talking about the actions to perform on preexisting partitions, that has also been improved. In the first guided setup version, these options were only displaying for illustrative purposes, but now they are 100% real and the proposal will honor their values, so the user can easily select what to do with previous Windows or Linux partitions. We even added a third option for other kind of partitions.

Last but not least (regarding the guided setup), the password selection for encryption is now more usable, allowing the user to choose a not so strong password if really desired.

Insserv removal

YaST is a complex and large piece software. It means that time to time some pieces that used to be great and shiny become obsolete and end up being useless. The cycle of life. 😉

Some time ago, it was decided it was time for insserv to enjoy retirement and it was replaced by a stub. But there were still calls to insserv in YaST and we decided to remove them all. There were several reasons for that decision. Basicaly (open)SUSE has used systemd for couple of years already, so revisiting places where the YaST code depended on SySV was a must. As a side effect it shortened the list of YaST dependencies and, in the end, it is another small step towards smaller installation.

So good bye insserv, it was a pleasure to work with you.

Improvements in the ZFCP Controller Configuration for zKVM on S/390

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

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

The fix was basically just an one-liner which skips the warning when the zKVM virtualization is detected, but the YaST module for ZFCP doesn’t usually receive to much maintenance, so we applied our boy scout rule and improved the code a bit.

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

Storage reimplementation: improvements all around

As we reported in our report about Hack Week 15, we have been working on an alternative way to offer the power of the new storage library to the Ruby world. The new API is finally ready for prime-time and used in all the Ruby code.

We took the opportunity to greatly improve the developer documentation and to revamp the yast2-storage-ng README and status page.

We also did some extra checks and added automated testing to ensure our partitioning proposal ensure the requisites if a S/390 system using ZFCP, so mainframe users also have a peaceful transition to the new storage stack.

We also greatly improved the ability of the new library to work with alternative name schemes for the devices. Up to now, only using plain kernel device name (e.g. /dev/sda1) was fully supported. Now we can do all the operations (specially generating the /etc/fstab file) by device name, by UUID, by filesystem label, by device id and by device path.

Great news ahead!

The next sprint will be the first in which the whole YaST team will work together integrating the new storage stack in every single part of YaST. So we hope the next report to be full of good news about the expert partitioner, improvements in AutoYaST’s handling of disks and so on.

Of course, that would be only a small fraction of all the stuff we plan to work on. See you in three weeks with more news!

Posted in Distribution, Documentation, Factory, Hackweek, Programming, Systems Management, YaST | Comments Off on Highlights of YaST development sprint 34

Highlights of YaST development sprint 33

April 26th, 2017 by Yast Team

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.

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.

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.

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.

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.

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.

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.

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!

Posted in Distribution, Factory, Programming, Systems Management, YaST | Comments Off on Highlights of YaST development sprint 33

Highlights of YaST development sprint 32

March 22nd, 2017 by Yast Team

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.

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.

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.

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.

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:

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.

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.

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

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.

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).

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!

Posted in Distribution, Factory, Miscellaneous, Programming, Systems Management, Usability, YaST | 6 Comments »

Highlights of YaST development sprint 31

February 20th, 2017 by Yast Team

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.

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.

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.

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.

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.

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

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.

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!

Posted in Desktop, Distribution, Factory, GNOME, Hackweek, KDE, Packaging, Programming, Software Management, Systems Management, XFCE, YaST | 5 Comments »

Advertisement
Tags
11.3 11.4 12.1 12.2 12.3 13.1 13.2 amd ARM ATI Beta buildservice Build Service C-Language cloud Collaboration Community conference Education event Events Factory fglrx fun GNOME gsoc Hackweek KDE Kernel Kraft Linux LXDE obs openSUSE Package PostgreSQL radeon raspberry Raspberry Pi rpm Ruby Tumbleweed XML xorg YaST
Lizards
- Adrian Schröter (12)
- Agustin Chavarria (6)
- Alessandro de Oliveira Faria (13)
- Alex Barrios (12)
- Alexander Naumov (10)
- Alexander Orlovskyy (3)
- Alin M Elena (5)
- Andrea Florio (27)
- Andreas Jaeger (70)
- Andreas Stieger (12)
- Andrew Wafaa (31)
- Arvin Schnell (9)
- Atri Bhattacharya (3)
- Bernhard Wiedemann (31)
- Bonnie Kurniawan (1)
- Bruno Friedmann (98)
- Calumma Brevicorne (29)
- Carl Fletcher (1)
- Christopher Hobbs (17)
- Ciaran Farrell (3)
- Stephan Kulow (17)
- craig gardner (2)
- Stephan Barth (2)
- Thomas Schmidt (2)
- Dinar Valeev (1)
- Dirk Mueller (2)
- Dmitry Serpokryl (7)
- Efstathios Iosifidis (21)
- Fabio Mucciante (5)
- Federico Lucifredi (9)
- Greg Freemyer (1)
- Holger Sickenberg (2)
- Hubert Mantel (1)
- Ilya Chernykh (5)
- Ismail Donmez (1)
- J. Daniel Schmidt (2)
- James Tremblay (7)
- Jan Blunck (4)
- Jan Loeser (3)
- Jan Madsen (1)
- Jan-Christoph Bornschlegel (3)
- Jan-Simon Möller (20)
- Javier Llorente (12)
- Jigish Gohil (85)
- Jiri Srain (1)
- Jiří Suchomel (3)
- Johan Kotze (5)
- José Oramas M. (6)
- Josef Reidinger (16)
- Juergen Weigert (1)
- Julio Vannini (9)
- Dinar Valeev (5)
- Kevin "Yeaux" Dupuy (11)
- Klaas Freitag (55)
- Lars Vogdt (11)
- Ludwig Nussel (13)
- M. Edwin Zakaria (4)
- Marcus Hüwe (39)
- Marcus Meissner (2)
- Marcus Moeller (3)
- Marcus Schaefer (4)
- Martin Lasarsch (8)
- Martin Mohring (11)
- Masim "Vavai" Sugianto (20)
- Michael Andres (1)
- Michael Löffler (7)
- Michal Marek (7)
- Michal Vyskocil (12)
- Miguel Angel Barajas Hernandez (2)
- P Linnell (2)
- Nelson Marques (55)
- Nenad Latinović (1)
- Nikanth Karthikesan (2)
- Przemyslaw Bojczuk (1)
- Peter Pöml (4)
- Petr Gajdos (2)
- Petr Mladek (60)
- Petr Uzel (5)
- Ray Wang (1)
- Raymond Wooninck (1)
- Ricardo Chung (7)
- Ricardo Varas Santana (7)
- Richard Bos (11)
- Robert Schweikert (16)
- Rossana Motta (1)
- Rupert Horstkötter (10)
- Sascha Manns (66)
- saydul akram (3)
- Sebastian Siebert (6)
- Shawn Dunn (2)
- Stanislav Visnovsky (7)
- Stefan Haas (1)
- Stefan Hundhammer (5)
- Stefan Schubert (7)
- Steffen Winterfeldt (8)
- Suresh Jayaraman (3)
- Susanne Oberhauser (3)
- Thomas Göttlicher (6)
- Thomas Schraitle (26)
- Togan Muftuoglu (3)
- Tuukka Pasanen (36)
- Will Stephenson (22)
- YaST Team (90)
Archives
- March 2020 (1)
- February 2020 (2)
- January 2020 (1)
- December 2019 (3)
- November 2019 (2)
- October 2019 (4)
- September 2019 (3)
- August 2019 (3)
- July 2019 (4)
- June 2019 (2)
- April 2019 (4)
- March 2019 (3)
- February 2019 (5)
- January 2019 (1)
- December 2018 (2)
- November 2018 (2)
- October 2018 (3)
- September 2018 (1)
- August 2018 (3)
- July 2018 (2)
- May 2018 (2)
- April 2018 (2)
- March 2018 (2)
- February 2018 (2)
- January 2018 (2)
- December 2017 (1)
- November 2017 (2)
- October 2017 (2)
- September 2017 (3)
- August 2017 (4)
- July 2017 (4)
- June 2017 (2)
- May 2017 (4)
- April 2017 (2)
- March 2017 (3)
- February 2017 (3)
- January 2017 (2)
- December 2016 (5)
- November 2016 (3)
- October 2016 (6)
- September 2016 (2)
- August 2016 (3)
- July 2016 (4)
- June 2016 (2)
- May 2016 (2)
- April 2016 (1)
- March 2016 (2)
- February 2016 (4)
- January 2016 (4)
- December 2015 (6)
- November 2015 (2)
- October 2015 (3)
- September 2015 (2)
- August 2015 (2)
- July 2015 (2)
- June 2015 (3)
- May 2015 (12)
- April 2015 (7)
- March 2015 (6)
- February 2015 (6)
- January 2015 (7)
- December 2014 (5)
- November 2014 (3)
- October 2014 (5)
- September 2014 (3)
- August 2014 (5)
- July 2014 (5)
- June 2014 (7)
- May 2014 (9)
- April 2014 (2)
- March 2014 (9)
- February 2014 (9)
- January 2014 (10)
- December 2013 (9)
- November 2013 (10)
- October 2013 (10)
- September 2013 (6)
- August 2013 (7)
- July 2013 (3)
- June 2013 (7)
- May 2013 (4)
- April 2013 (4)
- March 2013 (7)
- February 2013 (6)
- January 2013 (3)
- December 2012 (3)
- October 2012 (6)
- September 2012 (6)
- August 2012 (5)
- July 2012 (12)
- June 2012 (6)
- May 2012 (4)
- April 2012 (4)
- March 2012 (5)
- February 2012 (2)
- January 2012 (5)
- December 2011 (10)
- November 2011 (6)
- October 2011 (5)
- September 2011 (9)
- August 2011 (12)
- July 2011 (14)
- June 2011 (11)
- May 2011 (18)
- April 2011 (15)
- March 2011 (26)
- February 2011 (16)
- January 2011 (23)
- December 2010 (27)
- November 2010 (18)
- October 2010 (21)
- September 2010 (16)
- August 2010 (21)
- July 2010 (20)
- June 2010 (33)
- May 2010 (29)
- April 2010 (24)
- March 2010 (29)
- February 2010 (22)
- January 2010 (20)
- December 2009 (15)
- November 2009 (21)
- October 2009 (17)
- September 2009 (22)
- August 2009 (28)
- July 2009 (36)
- June 2009 (38)
- May 2009 (40)
- April 2009 (30)
- March 2009 (20)
- February 2009 (21)
- January 2009 (27)
- December 2008 (23)
- November 2008 (12)
- October 2008 (23)
- September 2008 (40)
- August 2008 (24)
- July 2008 (12)
- June 2008 (28)
- May 2008 (26)
- April 2008 (1)