Hello. Thanks for the point of view.
Nice for parameters, did not see this new features. It looks pretty cool. And should solve my purpose. Unfortunately, I did not expected to make an upgrade for my clients, but this is an another "problem". For NiFi registry, this is what I do when possible. In the current case, this is not possible because the development cycle is the following : * Develop on my laptop. * Validate the process on my instance. * Then go to the client, and give him the process. The client do the installation and I do not have right to install by myself. * Moreover, all three instances and separated. Dev instance can not communicate with Integration and Production. We could not have a registry accessible by those three, and neither frmo my laptop. For versioning, I understand. For the 1.9.3, it was just "a hope", but I understand this is just bug fixing release, if there is one. I am OK with that. And finally yo give the "answer". You do not anticipate such a feature. So no need to spend time on such things, because you are not favorable for that. It's OK and if I really need, I can always do my own service, that's the power of open source ;) Thanks for all. Etienne Le sam. 4 janv. 2020 à 00:05, Andy LoPresto <[email protected]> a écrit : > 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 > [2] https://nifi.apache.org/docs/nifi-registry-docs/index.html > [3] https://semver.org > [4] https://issues.apache.org/jira/browse/NIFIREG-288 > > Andy LoPresto > [email protected] > *[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 > > >
