I am not sure I follow all of the issues you are describing, but I will try to address them as I understand them.
In the 1.10.0 release, parameters [1] were introduced, which allow any component property to use a reference to externally-defined values (this does not rely on Expression Language, which must be explicitly enabled for each property, and allows for sensitive parameter values so it can be used for passwords). You should be able to define a single controller service with the proper parameters specified for the passwords, and then each environment will have a parameter context defined once which contains the appropriate passwords. Any time a new flow is loaded or updated that references the controller service, no changes will be required. We do not recommend using templates for flow deployment as NiFi Registry [2] is available and is a more robust solution. There is currently no plan for a 1.9.3 release, and even if it came to fruition, it would not include this behavior as it would be a bug fix only, not a feature-bearing release. We use semantic versioning [3], so the next release which would contain new features is 1.11.0. I do not anticipate adding a feature for a “proxy” controller service which wraps another controller service in this manner because I don’t see this addressing the problem you have. I believe there was a fix [4] in the most recent version of NiFi Registry which addresses a similar issue. [1] https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#Parameters <https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#Parameters> [2] https://nifi.apache.org/docs/nifi-registry-docs/index.html <https://nifi.apache.org/docs/nifi-registry-docs/index.html> [3] https://semver.org <https://semver.org/> [4] https://issues.apache.org/jira/browse/NIFIREG-288 <https://issues.apache.org/jira/browse/NIFIREG-288> Andy LoPresto [email protected] [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Jan 3, 2020, at 10:50 AM, Etienne Jouvin <[email protected]> wrote: > > Hello all. > > Those last days, I spent some times to deploy process to my client, using a > Template. > In the template, I have many InvokeHTTP processors, and some services related > to the SSLContextService. > > My client have 3 environments, and for two of them, I can not configure the > SSLContextService, because I do not have to know password for keystore and > trustore. > > So we decide to setup a SSLContextService at "root" level in NiFi once for > all. > Each time I deploy the Template, a new service is deployed (this was a > previous question by someone here). > I just have to delete the serice created during the template import. And then > modify all processors. > > I was thinking of something than my help me and ask here if you think I could > be nice to have it in future release (ideally in 1.9.3, if planned) > We could have a sort of "proxy" for SSLContextService. The only property > would be an instance of SSLContextService. > And each call on the proxy will be a delegation to to "wrapped" instance. > > Like this, during deploy, I will just have to update the instance set on the > "proxy". > For other usage, we will be able to switch easly between SSL Context. > > The problem could be the implementation that may produce circular reference. > But it is not our fault if user make things stupid. > > > What do you think about that ? > > > Regards > > Etienne Jouvin >
