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

现代软件系统是由多个组件组成的。（多组件系统），例如微服务和分布式系统。这些系统往往有大量的设置，可以分为三种主要类型。(1)运行时设置允许操作员在不改变源代码的情况下改变软件系统的行为；(2)依赖项设置允许对组件使用哪些库和版本进行规范（例如，NPM依赖项）；(3)基础设施设置允许对部署组件的基础设施进行配置（例如，使用IaC工具，Docker和Kubernetes）。在部署新版本时，运营商需要根据该版本中更改的代码配置某些设置。例如，可以通过配置“memory_limit”设置来增加组件可以使用的内存量。这样的配置具有挑战性，容易出错，而且耗时。每个组件往往有数百个运行时设置，依赖项的配置很复杂，基础设施配置文件经常更改。一位专家在我们之前的工作中报告说，它“是”。令人沮丧。为了弄清楚……发布日的特定配置”。不正确的配置会导致常见的错误并产生严重的影响（例如，安全性和财务）。虽然大量的研究工作集中在确定适当的源代码位置以更改给定的错误报告，但没有研究工作集中在确定部署或发布代码更改时要配置的适当设置上。因此，本提案的目标是通过一组最佳实践和两个推荐系统来帮助运营商配置多组件系统。运营商将使用第一个推荐系统来确定在数千个可用设置中需要更改哪些设置。然后，操作人员将按照我们的最佳实践手动更改它们。最后，我们的最后一个推荐系统将检查操作符更改的正确性。我们特别要实现以下目标：调查配置的实践状态。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.