Re: [VOTE] Release Apache NiFi MiNiFi C++ 0.7.0 (RC1)
+1, binding Comments: * signature and hashes looked good * license and notification looked correct and comprehensive * performed build and test successfully on Ubuntu 19.04, CentOS 7, and MacOS 10.14 * ran a variety of flows and achieved expected results * we should update the helper to have folks make use of the bootstrap or enumerate the needed dependencies. the prescribed approach worked for me as all systems had the requisite tools and dependencies, but others may experience trying to follow along. Thanks for acting as RM on this release, Arpad. Lots of great work since the last release. Kudos to all the contributors. On Wed, Jan 8, 2020 at 11:56 AM Arpad Boda wrote: > Hello Apache NiFi community, > > I am pleased to call this vote for the source release of Apache NiFi MiNiFi > C++ 0.7.0 > > The source tar.gz, including signatures, digests, and convenience binaries. > can be found at: > https://dist.apache.org/repos/dist/dev/nifi/nifi-minifi-cpp/0.7.0/ > > The Git tag is minifi-cpp-0.7.0-RC1 > The Git commit ID is: aa42957a2e227df41510047cece3cd606dc1cb6a > > Checksum of nifi-minifi-cpp-0.7.0-source.tar.gz: > SHA256: 2a3743e809652b429f3780e616373977fb1884330adabc1430449551b6e247bc > SHA512: > cfa86cb3e34e1e2dc439ade2c0c389c70679a6403ebcc2befb6781995179cac3f4a8ec0e107204bcdd95f2cc6b5be67b2a7fcfe68eb87f561f209074b45fd507 > > Release artifacts are signed with the following key: > https://people.apache.org/keys/committer/aboda.asc > > KEYS file available here: > https://dist.apache.org/repos/dist/release/nifi/KEYS > > 144 issues were closed/resolved for this release: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12344866=12321520 > > Release note highlights can be found here: > > https://cwiki.apache.org/confluence/display/MINIFI/Release+Notes#ReleaseNotes-Versioncpp-0.7.0 > > The vote will be open for 72 hours. > Please download the release candidate and evaluate the necessary items > including checking hashes, signatures, build > from source, and test. Then please vote: > > [ ] +1 Release this package as nifi-minifi-cpp-0.7.0 > [ ] +0 no opinion > [ ] -1 Do not release this package because... >
Re: Dynamic property for controller service
The PR solution is slightly different from mine. It short-circuits the validation immediately if the required API is the generic "ControllerService" interface. I suppose that's better to put up front rather than run through the whole chain only to reach the "special case" at the end. This solution should work in my use case. Thanks! On Thu, Jan 9, 2020 at 5:26 PM Matt Burgess wrote: > Mark, > > Good timing; Shawn, Bryan and I were talking about that on the Apache > NiFi Slack just today. It's been captured in NIFI-6852 [1] and Shawn > has drafted a PR [2] and is working on a unit test for it. My overall > thought is that you really shouldn't be binding to the generic > ControllerService, rather an interface that extends from it, for the > purposes of filtering on a particular type of ControllerService. But > for scripted (and some custom) components, you may need to allow that > kind of flexibility, so we should probably support validation (or lack > thereof as it were) in those cases, and that's what the Jira is about. > > For ExecuteGroovyScript, the CTL "object" is apparently very helpful, > and it sounds like you're doing something similar in your custom CS. > However even after [1] is resolved, I will likely go into > ExecuteGroovyScript and add objects for common controller services > such as RecordReader/Writer. Using specific CS interfaces helps > because you can use a dropdown to select the instances, rather than > the boilerplate code of getting the ControllerServiceLookup and > looking up by name/ID. You may want to look at doing the same for your > custom CS if you know the subset of controller service interfaces you > want to support. > > Regards, > Matt > > [1] https://issues.apache.org/jira/browse/NIFI-6852 > [2] https://github.com/apache/nifi/pull/3973/files > > On Thu, Jan 9, 2020 at 5:01 PM Mark Bean wrote: > > > > I have a custom controller service with dynamic properties. The dynamic > > property value is expected to be a controller service. Therefore, the > > getSupportedDynamicPropertyDescriptor returns a PropertyDescriptor from > the > > Builder with "identifiesControllerService(ControllerService.class)". This > > is because the property could be any controller service. > > > > During validation (in AbstractComponentNode), the actual controller > service > > specified is compared with the expected API (i.e. ControllerService.) > But, > > the API coordinate is "default:system:unversioned". > > > > First, is this correct? Why wouldn't ControllerService have a coordinate > of > > 1.10.0 and whatever NAR it lives in? > > > > Second, if the above is correct, what would you recommend for validating > > the custom controller service? > > > > I thought about adding an allowance in > > AbstractComponentNode.validateControllerServiceApi such that if all other > > API checks fail AND the provided descriptor is dynamic AND the API > > coordinate is "default:system:unversioned", then the validation result is > > valid. This catchall seems a little open-ended though. > > > > Suggestions? > > > > Thanks, > > Mark >
Re: Dynamic property for controller service
Mark, Good timing; Shawn, Bryan and I were talking about that on the Apache NiFi Slack just today. It's been captured in NIFI-6852 [1] and Shawn has drafted a PR [2] and is working on a unit test for it. My overall thought is that you really shouldn't be binding to the generic ControllerService, rather an interface that extends from it, for the purposes of filtering on a particular type of ControllerService. But for scripted (and some custom) components, you may need to allow that kind of flexibility, so we should probably support validation (or lack thereof as it were) in those cases, and that's what the Jira is about. For ExecuteGroovyScript, the CTL "object" is apparently very helpful, and it sounds like you're doing something similar in your custom CS. However even after [1] is resolved, I will likely go into ExecuteGroovyScript and add objects for common controller services such as RecordReader/Writer. Using specific CS interfaces helps because you can use a dropdown to select the instances, rather than the boilerplate code of getting the ControllerServiceLookup and looking up by name/ID. You may want to look at doing the same for your custom CS if you know the subset of controller service interfaces you want to support. Regards, Matt [1] https://issues.apache.org/jira/browse/NIFI-6852 [2] https://github.com/apache/nifi/pull/3973/files On Thu, Jan 9, 2020 at 5:01 PM Mark Bean wrote: > > I have a custom controller service with dynamic properties. The dynamic > property value is expected to be a controller service. Therefore, the > getSupportedDynamicPropertyDescriptor returns a PropertyDescriptor from the > Builder with "identifiesControllerService(ControllerService.class)". This > is because the property could be any controller service. > > During validation (in AbstractComponentNode), the actual controller service > specified is compared with the expected API (i.e. ControllerService.) But, > the API coordinate is "default:system:unversioned". > > First, is this correct? Why wouldn't ControllerService have a coordinate of > 1.10.0 and whatever NAR it lives in? > > Second, if the above is correct, what would you recommend for validating > the custom controller service? > > I thought about adding an allowance in > AbstractComponentNode.validateControllerServiceApi such that if all other > API checks fail AND the provided descriptor is dynamic AND the API > coordinate is "default:system:unversioned", then the validation result is > valid. This catchall seems a little open-ended though. > > Suggestions? > > Thanks, > Mark
Dynamic property for controller service
I have a custom controller service with dynamic properties. The dynamic property value is expected to be a controller service. Therefore, the getSupportedDynamicPropertyDescriptor returns a PropertyDescriptor from the Builder with "identifiesControllerService(ControllerService.class)". This is because the property could be any controller service. During validation (in AbstractComponentNode), the actual controller service specified is compared with the expected API (i.e. ControllerService.) But, the API coordinate is "default:system:unversioned". First, is this correct? Why wouldn't ControllerService have a coordinate of 1.10.0 and whatever NAR it lives in? Second, if the above is correct, what would you recommend for validating the custom controller service? I thought about adding an allowance in AbstractComponentNode.validateControllerServiceApi such that if all other API checks fail AND the provided descriptor is dynamic AND the API coordinate is "default:system:unversioned", then the validation result is valid. This catchall seems a little open-ended though. Suggestions? Thanks, Mark
