Page History

Migrating from 1.x.x to 1.8.0

• MergeRecord (available since 1.4.0) behavior changes if 'Minimum Number of Records' (defaults to 1) is configured less than 'Maximum Number of Records'  (defaults to 1000). Because NIFI-5514 corrected MergeRecord to honor 'Minimum Number of Records'. Before 1.8.0, MergeRecord merged incoming FlowFiles up to configured maximum conditions (Number of Records, Bin Size and Bin Age) regardless of 'Minimum Number of Records'. Since 1.8.0, MergeRecord can finish merging once the 'Minimum Number of Records' reaches, as a result, the processor may produce more small outgoing FlowFiles compared to old versions. Please increase the minimum number of records (up to the value of Maximum Number of Records) to make the processor merge more records.

Migrating from 1.x.x to 1.7.1

• Apache NiFi 1.7.1 resolves an issue where secure clusters which relied on wildcard certificates could encounter a certificate path validation error. As documented in the Administration Guide, wildcard certificates are not officially supported and all certificates should have a unique entry in the Distinguished Name (DN) field and Subject Alternative Names (SAN) field matching the hostname of the node. This release fixes a regression in 1.7.0 but should not be confused with intentional or forward support for wildcard certificates. 

• Hostname validation has become more strict in 1.7.1. In previous versions, NiFi supported certificates which did not contain a Subject Alternative Name (SAN) field matching the node hostname. In following with RFC 6125, all certificates should include an entry in the SAN array which matches the node hostname for hostname verification. 

Migrating from 1.6.0 to 1.7.0

• Some component properties are renamed:
  • Old properties become unsupported user-defined properties (dynamic properties), and those components become invalid.
  • To make such component valid, migrate values from old properties to new ones, then remove old properties.
  • The list of changed property names:
    
    • ReportLineageToAtlas by NIFI-4980
      • kafka-kerberos-service-name-kafka => kafka-kerberos-service-name
    • GetCouchbaseKey and PutCouchbaseKey by NIFI-5257
      • Couchbase Cluster Controller Service => cluster-controller-service
      • Bucket Name => bucket-name
      • Document Type => document-type
      • Document Id => document-id
      • Persist To => persist-to
      • Replicate To => replicate-to 

• Apache NiFi 1.7.0 introduces new policies for controlling access to provenance events from a component. Previously NiFi leveraged the data policies for a component to control access to provenance events but these would also allow a user to download flowfile attributes and content through provenance events and in queues on outgoing connections. Often times granting this much access was too much for the operators of the NiFi instance. However, withholding this access made it difficult for operators to understand the dataflow and track what was happening. By introducing a new view provenance events policy for controlling access to the event itself these operators can better understand the dataflow and track what is happening while the administrators can still maintain tight control of the flowfile attributes and content. When upgrading to Apache NiFi 1.7.0 these new policies will not exist. As a result, users who could previously access provenance events through the data policies described above will no longer have access to these provenance events. An administrator will need to create new provenance policies and assign the users in question before they can resume access.

Migrating from 1.5.0 to 1.6.0

• PutMongo can fail in insert mode. Will be fixed in next release. In the mean time you can set query keys for insert even though they'll be ignored it should workaround the validation bug.

Migrating from 1.4.x to 1.5.0

• No known migration issues.

Migrating from 1.4.0 to 1.5.0

• AWS components for NiFi have been reorganized into sub-projects nifi-aws-serice-api, nifi-aws-abstract-processors, and nifi-aws-processors to separate service interfaces from concrete implementation classes.  Custom AWS components should be rebuilt to target NiFi 1.5.0.  For bundles that only implement controller service interfaces (AWSCredentialsProviderService), it is recommended that the NAR dependency be changed to nifi-aws-service-api-nar.  Custom AWS components built for earlier versions of NiFi can continue to be used if the matching version of the nifi-aws-nar.

• ExecuteStreamCommand now has a failure relationship which will need to be routed somewhere or auto-terminated, otherwise existing instances of the processor will be invalid (

  Jira
  server ASF JIRA serverId 5aa69414-a9e9-3523-82ec-879b028fb15b key NIFI-4559

  )

• A restricted implementation of the SSLContextService has been added, StandardRestrictedSSLContextService. It provides the ability to configure keystore and/or truststore properties once and reuse that configuration throughout the application, but only allows a restricted ("modern") set of TLS/SSL protocols to be chosen (as of 1.4.0, no SSL protocols are supported, only TLS v1.2). The set of protocols selectable will evolve over time as new protocols emerge and older protocols are deprecated. The generic "TLS" entry is also supported and will automatically select the best available option without user intervention (this is the recommended setting). This service is recommended over StandardSSLContextService if a component doesn't expect to communicate with legacy systems since it is unlikely that legacy systems will support these protocols. 

  • The following Listen* processors now require a StandardRestrictedSSLContextService (previously requiring StandardSSLContextService): ListenBeats, ListenHTTP, ListenLumberjack, ListenRELP, ListenSMTP, ListenSyslog, ListenTCP, ListenTCPRecord
  • ListenGRPC is a new processor for 1.4.0, and requires StandardRestrictedSSLContextService
  • Dataflow managers will need to instantiate a new instance of StandardRestrictedSSLContextService and associate it with any of the above components in an existing flow
• An update to the Authorization framework has introduced more granular configuration options in the authorizers.xml file. These options are detailed in this file and in the Administration Guide. This file defines the available Authorizers for NiFi to utilize in a secure configuration. The nifi.properties file contains a property called nifi.security.user.authorizer that defines which Authorizer to use. By default, both the authorizers.xml and the nifi.security.user.authorizer property have been updated to utilize the new authorizer configuration. However, existing authorizers.xml configurations are still valid. In this case, it's important to ensure that the value of the nifi.security.user.authorizer property is set to the identifier of the Authorizer from your existing authorizers.xml.