Given the issues discovered today, I am canceling the voting for RC1. I will prepare RC2 when I get a bit of time to work on it, hopefully within the next day or two, and start another vote thread.
Here's a list of issues that will be addressed by RC2: https://issues.apache.org/jira/browse/NIFI-4345 https://issues.apache.org/jira/browse/NIFI-4416 https://issues.apache.org/jira/browse/NIFI-4418 On Mon, Sep 25, 2017 at 1:12 PM Joe Witt <joe.w...@gmail.com> wrote: > Ok good this makes a lot more sense now. One JIRA will fix the > erroneous duplicates. And this JIRA, which can be done later, will > correct that we should have actually not even have noticed the > duplicates and Rick's flow should have worked correctly automatically > [1]. > > > [1] https://issues.apache.org/jira/browse/NIFI-4420 > > Thanks > Joe > > On Mon, Sep 25, 2017 at 12:49 PM, Bryan Bende <bbe...@gmail.com> wrote: > > I think the reason for the upgrade issue was the following... > > > > Normally there is an automatic upgrade of component versions, with the > > following logic: > > > > - If the flow says you are using version X of a component, and during > > startup version X is not found, but version Y is found, and version Y > > is the only version of that component, then version Y is selected. > > > > - If the flow says you are using version X of a component, and during > > startup more than one version of the component is found, then we can't > > automatically select one, so a ghost component would be created as > > place-holder. > > > > This is how all the components would normally go from 1.3.0 to 1.4.0 > > on an upgrade. > > > > In Richard's flow, he was using the 1.3.0 XMLFileLookupService, and > > when he upgraded it found a 1.4.0 version from the lookup services > > NAR, and also a 1.4.0 version from the Mongo services NAR, and > > therefore fell into the second case described above. > > > > Deleting the service and re-creating it is one way to resolve the > > issue, I also believe you could go into the controller services table > > and select to "Change Version" on the service and select the version > > from the lookup services NAR. > > > > > > On Mon, Sep 25, 2017 at 12:28 PM, Matt Burgess <mattyb...@apache.org> > wrote: > >> All, > >> > >> I verified that Joey is correct and that dependency causes the > >> duplicates. I reopened NIFI-4345 and submitted a PR. > >> > >> Regards, > >> Matt > >> > >> [1] https://issues.apache.org/jira/browse/NIFI-4345 > >> [2] https://github.com/apache/nifi/pull/2174 > >> > >> On Mon, Sep 25, 2017 at 11:45 AM, Richard St. John <rstjoh...@gmail.com> > wrote: > >>> Joey, > >>> > >>> That sounds like that is the issue. > >>> > >>> Rick. > >>> > >>> -- > >>> Richard St. John, PhD > >>> Asymmetrik > >>> 141 National Business Pkwy, Suite 110 > >>> Annapolis Junction, MD 20701 > >>> > >>> On Sep 25, 2017, 11:44 AM -0400, Joey Frazee <joey.fra...@icloud.com>, > wrote: > >>>> I think there could be an issue with the deps in the > nifi-mongodb-services-nar. It includes nifi-lookup-services which should > either be unnecessary or should just be provided scope (just need the > services API dependency). So it’s possible that all the impls in > nifi-lookup-services are indeed included twice. > >>>> > >>>> Does that jive with what you’re seeing? I.e., for LookupService > properties do you see double of everything? > >>>> > >>>> -joey > >>>> > >>>> On Sep 25, 2017, 10:30 AM -0500, Richard St. John < > rstjoh...@gmail.com>, wrote: > >>>> > Joe, > >>>> > > >>>> > The issue I encountered was related to, I believe, the packaging of > the mongodb lookup service. I am using the XMLlookup service and have a > processor with a reference to the XML lookup service. When I upgraded from > 1.3 to 1.4, the processor became invalid due to “incompatible type” of > service. The lookup attribute processor appeared to be attempting to use > the mongodb lookup service. I re-added the xml lookup service, being > careful to use the one in the nifi-lookup-services-nar and not the one > packaged in the nifi-mongodb-services-nar. After do that, the lookup > attribute processor was valid and able to link to the > <https://maps.google.com/?q=t,+the+lookup+attribute+processor+was+valid+and+able+to+link+to+the&entry=gmail&source=g> > xml lookup service. > >>>> > > >>>> > Rick. > >>>> > > >>>> > -- > >>>> > Richard St. John, PhD > >>>> > Asymmetrik > >>>> > 141 National Business Pkwy, Suite 110 > >>>> > Annapolis Junction, MD 20701 > >>>> > > >>>> > On Sep 25, 2017, 10:55 AM -0400, Joe Witt <joe.w...@gmail.com>, > wrote: > >>>> > > -1 (binding) based on what Rick ran into. > >>>> > > > >>>> > > Otherwise though the release is looking good. I'm running through > a > >>>> > > series of tests now and things going well. > >>>> > > > >>>> > > Rick, > >>>> > > I agree there are duplicate controller services and sourced to the > >>>> > > mongo system. And we must fix/remove those. > >>>> > > > >>>> > > However, the issue for upgrading is one I'd like to better > understand. > >>>> > > What is the problem you're seeing? It is not required that > controller > >>>> > > services have unique class names. The requirement is that the > >>>> > > artifact/coordinate is unique across the class name/extension > >>>> > > bundle/version. So lets figure out why this is actually breaking > you. > >>>> > > > >>>> > > Thanks > >>>> > > Joe > >>>> > > > >>>> > > On Mon, Sep 25, 2017 at 10:47 AM, Richard St. John < > rstjoh...@gmail.com> wrote: > >>>> > > > -1 non-binding. > >>>> > > > > >>>> > > > There are duplicate lookup services registered and it’s causing > issues > >>>> > > > upgrading from 1.3.0 to 1.4.0. It seems to be related to the > mongo lookup > >>>> > > > service. > >>>> > > > > >>>> > > > Rick. > >>>> > > > > >>>> > > > -- > >>>> > > > Richard St. John, PhD > >>>> > > > Asymmetrik > >>>> > > > 141 National Business Pkwy, Suite 110 > >>>> > > > Annapolis Junction, MD 20701 > >>>> > > > > >>>> > > > On Sep 24, 2017, 9:15 PM -0400, Jeff <jtsw...@gmail.com>, > wrote: > >>>> > > > > >>>> > > > There is an error in my previous email. 192 issues were closed > and > >>>> > > > resolved for this release. > >>>> > > > > >>>> > > > On Sun, Sep 24, 2017 at 9:11 PM Jeff <jsto...@apache.org> > wrote: > >>>> > > > > >>>> > > > Hello, > >>>> > > > > >>>> > > > I am pleased to be calling this vote for the source release of > Apache NiFi > >>>> > > > nifi-1.4.0. > >>>> > > > > >>>> > > > The source zip, including signatures, digests, etc. can be > found at: > >>>> > > > > https://repository.apache.org/content/repositories/orgapachenifi-1110 > >>>> > > > > >>>> > > > The Git tag is nifi-1.4.0-RC1 > >>>> > > > The Git commit ID is 466931665caab96df1c2c6b62d4b3c6cffeb3539 > >>>> > > > > >>>> > > > > https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=466931665caab96df1c2c6b62d4b3c6cffeb3539 > >>>> > > > > >>>> > > > Checksums of nifi-1.4.0-source-release.zip: > >>>> > > > MD5: 9862f59ad1bfa12f2ce041e4c69b1c93 > >>>> > > > SHA1: 3e2d0dcf0a83df5336a2962fbf6f10c3ae61c588 > >>>> > > > > >>>> > > > Release artifacts are signed with the following key: > >>>> > > > https://people.apache.org/keys/committer/jstorck.asc > >>>> > > > > >>>> > > > KEYS file available here: > >>>> > > > https://dist.apache.org/repos/dist/release/nifi/KEYS > >>>> > > > > >>>> > > > 8 issues were closed/resolved for this release: > >>>> > > > > >>>> > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020&version=12340589 > >>>> > > > > >>>> > > > Release note highlights can be found here: > >>>> > > > > >>>> > > > > https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version-1.4.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. The please vote: > >>>> > > > > >>>> > > > [ ] +1 Release this package as nifi-1.4.0 > >>>> > > > [ ] +0 no opinion > >>>> > > > [ ] -1 Do not release this package because... > >>>> > > > > >>>> > > > >
