vpodzime

[Design Draft] libblockdev's multiplugin support

With the LVM DBus API being almost a reality comes the need for libblockdev to start supporting multiple plugins providing the same functionality. In this particular example, the current lvm plugin using the lvm utility(ies) should be forked as a new lvm-dbus plugin that would use the LVM DBus API, but both should be supported and maintained in the near future because the LVM DBus API may contain serious bugs or it can be unavailable on some systems, etc.

vpodzime

diff --git a/blivet/devicefactory.py b/blivet/devicefactory.py
index 54f5d9d..b06e651 100644
--- a/blivet/devicefactory.py
+++ b/blivet/devicefactory.py
@@ -34,6 +34,7 @@ from .partitioning import SameSizeSet
 from .partitioning import TotalSizeSet
 from .partitioning import do_partitioning
 from .size import Size
+from .util import default_namedtuple
 

vpodzime

From e53bb4bebcfbbb859c165e3e7449ec3031e15026 Mon Sep 17 00:00:00 2001
From: Vratislav Podzimek <vpodzime@redhat.com>
Date: Tue, 12 Jan 2016 10:16:44 +0100
Subject: [PATCH] Filter items that are not part of the API for the
 documenation

We can easily mark items that we don't consider to be a part of the API in their
docstrings and then skip them when creating documentation.

Signed-off-by: Vratislav Podzimek <vpodzime@redhat.com>

vpodzime

commit 04f7cc5d1a9d1e8f180394e90953c16255b48b24
Author: Vratislav Podzimek <vpodzime@redhat.com>
Date:   Mon Jan 25 16:26:19 2016 +0100

    Add a test for the to-be-used @type_specific decorator
    
    When objects of various (sub)types need to be represented by a single class
    (e.g. because their (sub)types can change in time), it's nice to implement the
    (sub)type specific code in mixin classes the single resulting class inherits
    from. With thatthere are two (major) options how to implement the methods of

vpodzime

Problems

1. Many functions in libblockdev utilities that take lots of extra options and arguments. Adding separate parameters for all these options would complicate things a lot for the majority of use cases that don't need to specify them. And having multiple functions for the same thing just with different sets of arguments would be basically the same.
2. Adding extra arguments to functions means API breakage. The only solution

vpodzime

from gi.repository import BlockDev as blockdev

blockdev.init()

def print_args(*args):
    print(args)

# set print_args() as the logging function
blockdev.reinit(None, False, print_args)

vpodzime

procedure Task_Storage_Size is
   task type My_Task (Id : Natural);    --  works just fine without the discriminant
   task body My_Task is
      X : Natural := Id;
   begin
      X := X ** 10;
   end;

   type My_Task_Access is access My_Task
     with Storage_Size => 4 * My_Task'Max_size_in_storage_elements;

vpodzime

Reporting and monitoring storage events

With any type of storage failures and errors happen. Depending on the setup and the their extent such failures and errors might be anything from being just annoying or absolutely critical. However, they all have one thing in common -- they need to be properly reported so that counter-actions and fixups can happen.

What does properly mean here? The failures and errors need to be reported:

vpodzime

Weak dependencies for blivet and libblockdev

RPM weak dependencies are now fully supported in Fedora. They are even part of the packaging guidelines__. There are two kinds of weak dependencies both having forward and backward forms (respectively):

• weak - Recommends:, Supplements: and
• hint - Suggests:, Enhances:

vpodzime

Doing structured logging from kernel

For obvious reasons it's impossible to use the sd_journal C API from kernel to do structured logging. However, there are mechanisms for passing key=value pairs as extra data for log messages.

The standard way of reporting/logging from kernel is the printk() function. As its name suggests, it's very similar to the well-known printf() function from libc, but it has some specialties related to the fact that it's