markobean commented on PR #6061: URL: https://github.com/apache/nifi/pull/6061#issuecomment-1134861610
@markap14 It seems to me it is a high risk to allow NiFi to start with duplicate properties (with different values.) You've presented one use case where users simply append updated properties at the end of the file. This approach is susceptible to unnoticed configuration errors. Different values represent an ambiguous configuration. A user not in the know will not even be certain if the last property takes precedence or the first - or is it random? The documentation makes no mention of this. Therefore, we are in the gray area requiring the user to assume - never a good position to be in. That is largely the point of this ticket: to ensure a well-defined, unambiguous state of the application. I don't find that prospect overly limiting nor ill advised. The use case which brought about this ticket is a user (or maybe it was an automated script.. it's been lost to history a bit) updated nifi.properties in a similar way as you mentioned. However, operators looked at nifi.properties, and specifically looked at the area of the file that is commented and documented to hold certain properties, e.g. "# security properties #". Those values were correct, but a new property was added towards the end of the file and was unnoticed. So, we seem to be discussing the valid - or advisable - structure of the nifi.properties file, and the appropriate response of the application. Through this ticket, I would argue that it is not recommended to allow the properties file such wide latitude of property loading. There is very little downside to being more strict, yet potentially costly results for being more lax. I think it is perfectly reasonable to disallow start with the reason being logged. (In fact, failure happens so quickly that the log file is extremely short making it immediately obvious what the problem was.) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
