Hey Bence and team, I'd definitely be in favor of a better approach here. When removing variables, I found myself with the need to update a lot of copies of nifi.properties as well as other configuration files across many places of the codebase. I don't know what is the best option/approach here but having a single source of truth somewhere and being able to reference this everywhere with customization definitely sounds nice.
Pierre Le mar. 26 sept. 2023 à 09:19, Simon Bence <simonbence....@gmail.com> a écrit : > Hi Team, > > I was touching some test related code in the other day and it brought to > my attention how much partly duplicated nifi.properties files we do have in > the project in various places. > > While I was searching for the value of a given property in these files, it > got me thinking that when a property is changing (for example related to > the 2.x efforts) or added, it indicates changes in multiple places, which > could lead to oversights and inconsistencies. Additionally, it seems to me > that duplicating whole configuration files might make one reluctant to > create specific properties files for specific tests like in case of the > system tests. > > I would like to propose a discussion about this, being curious if the > community sees any value in improving the configuration management. My > initial thoughts is to maintain one single “source of truth” properties > file and providing some kind of utility, which could generate instances as > needed allowing to override or extend properties when necessary. > > Looking forward to your insights and suggestions. > > Regards, > Bence
