Wednesday, August 31, 2016

EVOSS: simulating FOSS distribution upgrades

Associate editor: Stefano Zacchiroli (@zacchiro)


Upgrading software is a critical and error prone task that might have dramatic consequences. This is the case of the Japanese flagship astronomical satellite Hitomi that was successfully launched on 17 February 2016 but that, most probably because of a software upgrade, was declared lost on March 26th, 2016. The cost of the satellite was $286 million.

In this article we focus on how to manage the upgrade of Free and Open Source Software (FOSS) distributions. Distributions are complex systems, composed of thousand components (software packages) evolving rapidly and independently from each other. A FOSS distribution can be seen as a consistent and functional collection of software packages comprising a complete operating system. The management of FOSS distributions evolution is very challenging due to its community-centric nature and to the frequent releases of components [1].

Typically, distributions offer automated tools, called package managers, for managing the components they are made of, and for managing system upgrades. State of the art package managers are able to successfully manage a limited set of upgrade types and, specifically, they are only aware of static dependencies among packages that can influence upgrades. The most important information available to package managers concern the specification of inter-package relationships such as dependencies (i.e., what a package needs in order to be correctly installed and to function correctly), and conflicts (i.e., which other packages should not be present on the system in order to avoid malfunctioning). Package managers completely ignore relevant dynamic aspects, such as potential faults of configuration scripts that are executed during upgrade deployment. Thus, it is not surprising that an apparently innocuous package upgrade can end up with a broken system state [2].

EVOSS


EVOSS (EVolution of free and Open Source Software), proposed within the context of the Mancoosi EU project, is an approach to support the upgrade of FOSS systems (see Figure 1). The approach is based on Model-driven Engineering (MDE) [3] which refers to the systematic use of models as first class entities throughout the software engineering life cycle. In MDE, Domain-Specific Modeling Languages (DSMLs) are used to describe the system. DSMLs use metamodels to define the main language concepts such as the relations among domain concepts and their semantics. More precisely, a metamodel is an abstraction that highlights the properties of the models, which are said to conform to its metamodel like a program conforms to the grammar of the programming language. DSMLs are used to build a system model according to its metamodel semantics and constraints. In MDE it is common to have a set of transformation engines and generators that produce various types of artefacts. There are many model-to-model transformation approaches, as surveyed in [4]. It is important to note that model transformations are defined once for all at the metamodeling level; therefore, practitioners act as users of model transformations, which are defined by MDE and domain experts.

Figure 1: Overview of the EVOSS approach working in a real system
In order to make upgrade prediction more accurate, EVOSS considers both static and dynamic aspects of packages and their upgrades. The main dynamic aspects considered are those related to the behaviour of package configuration scripts (AKA maintainer scripts) which are executed during upgrade deployment.

Maintainer scripts are executed during upgrades and they are full-fledged programs usually written in the POSIX shell language. Moreover, they are run with the system administrator rights and may therefore perform arbitrary changes to the whole system. They are expected to complete without errors: their failures, usually signalled by returning non-0 exit codes, automatically trigger upgrade failures and may easily lead the system to a non-coherent state.

EVOSS defines a DSL to specify the behaviour of maintainer scripts: this is a way to make the effect of the scripts predictable. This also limits the expressive power of the language used in maintainer scripts, without however reducing important functionality of the scripts themselves. The DSL includes a set of high level clauses with a well-defined transformational semantics expressed in terms of system state modifications: each system state is given as a model and the script behaviour is represented by corresponding model transformations.

The idea of EVOSS is to exploit the DSL semantics to better understand how the system evolves in a new configuration. This is obtained by simulating system upgrades via an upgrade simulator (see Figure 1) that allows system users to discover upgrade failures due to fallacious maintainer scripts before performing the upgrade on the real system. The simulator takes into account both fine-grained static aspects (e.g., configuration incoherencies) and dynamic aspects (e.g., the execution of maintainer scripts). The simulator is based on model-driven techniques and makes use of a model-based description of the system to be upgraded. More specifically, the configuration model represents a model of the system configuration and package models represent a model of packages to be installed, removed, or updated. The simulator is able to simulate also pre- and post-installation scripts that come with distribution packages. In order to apply the proposed simulation approach system configuration and package models have to be extracted automatically from existing artefacts.

In order to build the system's configuration and package models, EVOSS makes use of model injectors that are apt to extract models from existing artefacts. The outcome of the system injection is a model that represents, in a homogeneous form, different aspects of a running system, such as installed packages, users and groups, MIME type handlers, file alternatives, implicit dependencies, etc. The outcome of package injection contains modelling elements encoding both the considered package and its scripts (as DSL statements).

The fault detector is then used to check system configurations for incoherencies. The coherence of a configuration model is evaluated by means of queries which are embodied in the fault detector. In particular, for each detectable fault, a corresponding Object Constraint Language (OCL) expression is defined and used to query models and search for model elements denoting faults. OCL is a declarative language that provides constraint and object query expressions on models and meta-models. Obviously it is not possible to define once forever a complete catalogue of faults because they are based on experience and acquired know-how. Therefore, the fault detector has been designed to be open and extensible so that new queries can be added whenever new classes of faults are identified.
Implications

EVOSS represents an advancement, with respect to the state of the art of package managers, in the following aspects: (i) it provides a homogeneous representation of the whole system’s configuration in terms of models, including relevant system elements that are currently not explicitly represented, (ii) it supports the upgrade simulation with the aim of discovering failures before they can affect the real system, (iii) it proposes a fault detector module able to discover problems on the configuration reached by the simulation.

The EVOSS approach has been investigated and exploited by the Caixa Magica GNU/Linux distribution to support selective roll-back. More details might be found here on YouTube.

More information about EVOSS as well as its source code can be found on the EVOSS website.

If you like this article, you might also enjoy reading:


Overall description of the EVOSS approach:
  • Roberto Di Cosmo, Davide Di Ruscio, Patrizio Pelliccione, Alfonso Pierantonio, Stefano Zacchiroli (2011) Supporting software evolution in component-based FOSS systems, Science of Computer Programming 76: 12. 1144-1160. http://dx.doi.org/10.1016/j.scico.2010.11.001
Details about the simulator component:
  • Davide Di Ruscio, Patrizio Pelliccione (2014) Simulating upgrades of complex systems: The case of Free and Open Source Software, Information and Software Technology 56: 4. 438-462 April. http://dx.doi.org/10.1016/j.infsof.2014.01.006
Details about the fault detector component:
  • Davide Di Ruscio, Patrizio Pelliccione (2015) A model-driven approach to detect faults in FOSS systems, Journal of Software: Evolution and Process 27: 4. 294-318 April. http://dx.doi.org/10.1002/smr.1716
Details about the tool:
  • Davide Di Ruscio, Patrizio Pelliccione, Alfonso Pierantonio. EVOSS: a tool for managing the Evolution of Free and Open Source Software systems. 34th International Conference on Software Engineering (ICSE), Zurich, Demo paper, 2012, pp. 1415-1418. http://dx.doi.org/10.1109/ICSE.2012.6227234

References


[1] Eric S. Raymond. The cathedral and the bazaar. O'Reilly, 2001.
[2] Olivier Crameri, Nikola Knezevic, Dejan Kostic, Ricardo Bianchini, and Willy Zwaenepoel. Staged deployment in mirage, an integrated software upgrade testing and distribution system. SIGOPS Oper. Syst. Rev., 41(6):221-236, 2007.
[3] D. C. Schmidt. Guest Editor's Introduction: Model-Driven Engineering. Computer, 39(2):25-31, 2006.
[4] K. Czarnecki and S. Helsen. Feature-based survey of model transformation approaches. IBM Syst. J., 45:621-645, July 2006.

No comments:

Post a Comment