yast2-storage-ng as a libstorage-ng wrapper. POC
a project by ancorgs
Updated about 5 years ago. 1 hackers ♥️.

The goal of this project is to write a proof of concept of a new philosophy for yast2-storage-ng. Instead of just extending the API offered by libstorage-ng, the idea is wrap libstorage-ng so the Ruby code using yast2-storage-ng does not have direct visibility (unless explicitly desired) on the libstorage-ng classes and methods.

If you don't know what all that means, keep reading.

The YaST team is rewriting the storage stack (the part that manages disks, partitions, filesystems and so on). In the current implementation the low-level operations (partitioning and so on) are performed by a C++ library called libstorage. On top of that, yast2-storage provides an API for all the other YaST components and modules.

In the new implementation that should debut in SLE13, libstorage-ng already offers a higher level object oriented API with Ruby bindings (generated using SWIG). Although yast2-storage-ng is still there offering convenience classes and methods, now other YaST components directly use the classes provided by libstorage-ng to inspect the system and so on. So, contrary to the current implementation, yast2-storage-ng does not wrap libstorage-ng, but complements it by offering additional classes and refinements on top of the classes provided by libstorage-ng.

Now that libstorage-ng and yast2-storage-ng are quite feature-complete (although still far from the current versions) and used in several other YaST components, the direct use of libstorage-ng is starting to show some annoyances.

  • Sometimes, the strict type-checking imposed by SWIG forces the Ruby code using the library to look clumsy (explicit type casting, a lot of calls to #to_a in almost every collection coming from libstorage-ng, etc.).
  • The structure of libstorage-ng is very flexible and, by design, it never hides that to the user of the API. Offering a method like a_filesystem.disk would go against the philosophy of the library. The user of the library is expected to do something like a_filesystem.blk_devices[0].partition_table.partionable. That adds clarity about the real libstorage-ng structure, but does not ease the common case.
  • The C++ take on object orientation sometimes differs from the Ruby one. We have discussed for very long time and in many threads about several aspects of the libstorage-ng API without reaching a clear consensus between the two "sides" of the team - the developers with a solid background in C++ vs the Ruby purists.

Fixing those problems by adding many refinements feels wrong (refinements are still second-class citizens in the Ruby world). On the other hand, YaST does not need access to every single class provided by libstorage-ng, at least not in a regular basis.

So let's see go back to the wrapping approach and see what happens. I already tried in the past and SWIG was too much in the way. But now I have new ideas.

Join this project

Looking for hackers with the skills:

yast ruby c++

This project is part of:

Hack Week 15

Activity

  • about 7 years ago: dwaas liked this project.
  • about 7 years ago: ancorgs added keyword "yast" to this project.
  • about 7 years ago: ancorgs added keyword "ruby" to this project.
  • about 7 years ago: ancorgs added keyword "c++" to this project.
  • about 7 years ago: ancorgs started this project.
  • about 7 years ago: ancorgs originated this project.


    • Comments

    • ancorgs
      about 7 years ago by ancorgs | Reply

      This pull request shows some working code and explains how the new layer works (or would work when finished). Used as base for discussing the concept with the whole YaST team. Despite the length of the thread in the yast-devel mailing list, the proposal was well accepted. 7 out of the 8 YaST developers who expressed their opinion (in the mailing list or the PR) like the new layer and think it's the way to go.

      I spent the last day of Hack Week analyzing how the current query interface is used from other YaST modules and how to adapt that query interface to the new layer. The conclusion is that we just need to add some methods to the new layer and then we can even drop the current query interface.

      So we just need to allocate some time to finish this.

    Similar Projects

    openSUSE on ZoL from OpenZFS project by jkohoutek

    Idea is to have SUSE system with OpenZFS as roo...

    Catalog/Online Store for a bakery in Rails 7 by gfilippetti

    [comment]: # (Please use the project descriptio...

    Modernize SCC Customer Management and/or Patchfinder by digitaltomm

    [comment]: # (Please use the project descriptio...

    Dawnscanner: parsing a simple sinatra application by pperego

    [comment]: # (Please use the project descriptio...

    Reduce the amount of TODOs for RuboCop in OBS by enavarro_suse

    Project Description

    The OBS project has a...

    Avahi Integration and Network Connection by vojha

    Avahi Integration and Network Connection

    ...

    Port some classic game to Linux by MDoucha

    Let's pick some old classic game, reverse engin...

    Tungsten: A low-level LLVM programming language by mfriedrich

    Project Description

    > Tungsten is suppose...

    Extend GObject based introspectable API to libzypp by zbenjamin

    [comment]: # (Please use the project descriptio...

    HelenOS: <filesystem> of a down by jjindrak

    During the previous Hackweek [0], I have succes...