[WIP] Sprint 37 Blog Post Draft

[lslezak]

Sprint 37 Blog Post Draft

• This is just a draft for collecting the text for the team blog.
• Whenever you finish something worth mentioning at the blog just add a new entry
• The text will be reviewed and polished before publishing, this is just to collect the input from the developers. So be focused on the technical side, the wording, grammar, etc... can be improved later :wink:

Thank you for your contribution! :+1:

[gilsonsouza]

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 tool localectl to set the keyboard map in /etc/vconsole.conf, instead of writing in it directly.

[jreidinger]

MD Raid support in new partitioner

New partitioner using new storage stack growing with every sprint and this time, it adds beside other stuff ( check if there are other stuff finished ) read only support for MD Raids. It display current raids, shows details about specific one and also what devices is used to construct the raid. But pictures are better then thousand words, so lets see how it look like:

[shundhammer]

No, You Can't Have a Separate Partition for /var/lib/docker for CaaSP -- so Here You Have It

We really shouldn't make this too much public because for one thing it's kind of embarrassing, for another somebody might want to actually use this: For our new CaaSP product, they badly needed /var/lib/docker on 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. There are no provisions for any additional separate partitions to be automatically proposed based on available disk size and parameters from the installation media's control.xml file. The underlying code has grown over the years, it has undergone changes upon changes and has become really difficult to maintain; adding anything the complexity of adding more partitions to be automatically proposed was completely out of the question.

This is one (out of many) reasons why we are currently in the process of rewriting that entire YaST storage subsystem (we call the new one Storage-NG internally; you might have heard about it in this blog). But it will still take some time until it arrives; we are targeting the next SLES.

CaaSP, however, is based on SLE-12 SP2, and they need a solution now, based on the old storage stack. So what to do?

We decided we'd introduce a hack, well knowing that this kind of thing can easily backfire over time; if you let hacks accumulate in code, they develop their own life just like Dust Puppy. But we plan to kill that hack immediately once Storage-NG 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 _homepath 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, but that limitation was well communicated, along with a stern warning not to use this "feature" (a.k.a. hack) outside of that very specific use case in CaaSP.

We even considered not documenting this hack too publicly to avoid misuse (which is always only a heartbeat away once people discover "hidden features" anywhere), but we decided against it; we are living the Open Source spirit. 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 then, that's why we are pushing Storage-NG so hard: We want to regain control over that part.

[lslezak]

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 items (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 the 512 limit. The vast majority of packages have less entries than this limit 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.)

[imobachgs]

Integrating AutoYaST and the new storage layer: custom partitioning

As we mentioned in our previous report, we've been working hard to integration AutoYaST with the our brand new storage layer. 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.

[mvidner]

Published at https://lizards.opensuse.org/2017/07/03/yast-sprint-37/