A Configuration Management Framework for the Evolution of Multi-component Software Systems

现代软件系统是由多个组件(也称为多组件系统)组成的，如微服务和分布式系统。这些系统往往具有大量的设置，这些设置可以分为三种主要类型。(1)运行时设置允许操作员在不改变其源代码的情况下改变软件系统的行为，(2)依赖项设置允许规范组件使用哪些库和版本(例如，NPM依赖项)，(3)基础设施设置允许配置在其上部署组件的基础设施(例如，使用IAC工具、Docker和Kubernetes)。在部署新版本时，运营商需要根据该版本中更改的代码配置某些设置。例如，可以通过配置“MEMORY_LIMIT”设置来增加组件可以使用的内存量。这样的配置具有挑战性、容易出错且耗时。每个组件往往有数百个运行时设置，依赖项的配置很复杂，并且基础结构配置文件频繁更改。一位专家在我们之前的工作中报告说，这“令人沮丧。在发布当天弄清楚[……]具体的配置”。不正确的配置会导致常见且具有严重影响(例如，安全和财务)的错误。虽然大量的研究工作集中在为给定的错误报告确定要更改的适当源代码位置，但没有研究工作集中于确定在部署或发布代码更改时要配置的适当设置。因此，这项提议的目标是通过一套最佳做法和两个推荐系统，协助运营商配置多组件系统。运营商将使用第一个推荐系统来确定要在数千个可用设置中更改哪些设置。然后，操作员将根据我们的最佳实践手动更改它们。最后，我们最后的推荐系统将检查运营商更改的正确性。特别是，我们解决了以下目标：1.调查配置的实践状态。2.识别改变的源代码和三个设置类型中的每一个之间的映射。3.确定设置应遵守的约束。4.开发一种混合方法，利用白盒和黑盒方法来建议适当的配置。配置是一个热门的行业话题，特别是随着DevOps和GitOps原则以及NPM、Docker和Kubernetes等技术的快速采用。因此，这一提议的结果将对国内和国际高科技公司(如亚马逊、黑莓)产生直接影响。除了研究工业热点话题外，HQP还将广泛探索最先进的技术，如机器学习和源代码分析技术。

Modern software systems are constituted of multiple components (aka., multi-component systems), such as micro-services and distributed systems. These systems tend to have a large amount of settings, which can be categorized into three main types. (1) Runtime settings allow operators to change the behavior of a software system without changing its source code, (2) Dependencies' settings allow the specification of which libraries and versions to use for a component (e.g., NPM dependencies), (3) Infrastructure settings allow the configuration of the infrastructure on top of which a component is deployed (e.g., using IaC tools, Docker, and Kubernetes). When deploying a new version, operators need to configure certain settings according to the changed code in that version. For example, one can increase the amount of memory that a component can use by configuring the "memory_limit" setting. Such configuration is challenging, error-prone, and time-consuming. Each component tends to have hundreds of runtime settings, the configuration of dependencies is complex, and the infrastructure configuration files change frequently. An expert reported in our prior work that it "is . frustrating . to figure out [... a] specific configuration on release day". An incorrect configuration leads to errors that are common and have a severe impact (e.g., security and financial). While a large body of research efforts focused on identifying the appropriate source code locations to change for a given bug report, no research efforts focused on identifying the appropriate settings to configure when deploying or releasing a code change. Therefore, the goal of this proposal is to assist operators on the configuration of multi-component systems through a set of best practices and two recommendation systems. Operators will use a first recommendation system to identify which settings to change among the thousands of available ones. Then, operators will manually change them following our best practices. Finally, our last recommendation system will check the correctness of what the operators changed. In particular, we address the following objectives: 1. Investigating the configuration's state-of-the-practice. 2. Identifying a mapping between a changed source code and each of the three setting types. 3. Identifying the constraints that the settings should respect. 4. Developing a hybrid approach that leverages both white-box and black-box approaches for recommending the appropriate configurations. Configuration is a hot-industrial topic, especially with the fast adoption of DevOps and GitOps principles as well as technologies such as NPM, Docker, and Kubernetes. Therefore, the results of this proposal will have a direct impact on national and international high-tech companies (e.g., Amazon, BlackBerry). In addition to working on hot-industrial topics, the HQP will extensively explore state-of-the-art techniques such as machine learning, and source code analysis techniques.